<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 12pt; color: #000000'><br><br><hr id="zwchr" style="font-family: arial, helvetica, sans-serif;"><blockquote style="font-family: Helvetica, Arial, sans-serif; border-left-width: 2px; border-left-style: solid; border-left-color: rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-size: 12pt;"><div dir="ltr">On Fri, Sep 6, 2013 at 10:22 AM, Evan Hunt <span dir="ltr"><<a href="mailto:each@isc.org" target="_blank">each@isc.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The revoke bit has no defined meaning for a ZSK.</blockquote><div><br>While it's true the revoke bit really has no use for a true ZSK (i.e., a key where there's another key, a KSK, that is used to authenticate it), RFC 5011 doesn't distinguish based on either signing roles (ZSK/KSK) or presence of the SEP bit [1]:<br>
<pre class=""> A key is considered revoked when the resolver sees the key in a
self-signed RRSet and the key has the REVOKE bit (see <a href="http://tools.ietf.org/html/rfc5011#section-7" target="_blank">Section 7</a>
below) set to '1'. Once the resolver sees the REVOKE bit, it MUST
NOT use this key as a trust anchor or for any other purpose except to
validate the RRSIG it signed over the DNSKEY RRSet specifically for
the purpose of validating the revocation.<br></pre>In other words, if the revoke bit is set, that key is no good for signing anything other than itself, which is why DNSViz complains about it. And just to clarify, the use of the SEP bit is purely an administrative/user convention or "hint", but is not considered during validation [2,3]. Thus whether a key is action as a "ZSK" or a "KSK" really depends on how they are used.<br>
<br></div><div>Casey<br><br>[1] <a href="http://tools.ietf.org/html/rfc5011#section-2.1" target="_blank">http://tools.ietf.org/html/rfc5011#section-2.1</a><br>[2] <a href="http://tools.ietf.org/html/rfc6840#section-6.2" target="_blank">http://tools.ietf.org/html/rfc6840#section-6.2</a><br>
[3] <a href="http://tools.ietf.org/html/rfc4034#section-2.1.1" target="_blank">http://tools.ietf.org/html/rfc4034#section-2.1.1</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It's used for updating<br>
trust anchors via RFC 5011. The code allows you to set it (just as it<br>
allows you to use a ZSK as a KSK), but I don't recommend it.<br>
<br>
Unless there are resolvers that have managed-key trust anchors configured<br>
for <a href="http://ksu.edu" target="_blank">ksu.edu</a>, you shouldn't bother with the revoke bit for your KSK either.<br>
<br>
--<br>
Evan Hunt -- <a href="mailto:each@isc.org" target="_blank">each@isc.org</a><br>
Internet Systems Consortium, Inc.<br>
<div class=""><div class="h5" id="DWT10264"><br></div><div class="h5" id="DWT10264"><br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"></div></div></blockquote></div></div></div></blockquote><div style="font-family: arial, helvetica, sans-serif;">So, is the problem that everything is still being signed by the revoked key, along with the current key. Or that due to the 7 second delay in the publish/activate and there being 31 days in july and august...and the old key was revoked 7 seconds before the new key became active? Which didn't happen because I did the alg 7 to 8 transition, so June/July/August ZSK started later, so ended a bit into September.</div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;"></div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;"><div id="a06dad34-2af0-4f37-a98e-f45710da10c1"><br class="Apple-interchange-newline">Hmmm, this is interesting....Revoke doesn't exist in my older keys... Revoke only appears with old key and current keys. Wonder what caused it to appear</div><div><br></div></div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;">Looks like when I suggested we change from annual KSK rollover to every 3 years (which was good, because the sysadmin in another department that interacts with our registrar...left and now those interactions are done through our business office because registrars also need to get paid every year....and that former sysadmin was the last to have direct spending ability, left over from when she used to be a manager. Hopefully in 2015 when we do our KSK rollover, they understand all the aspects of interacting with a registrar....beyond buying and renewing domains. And, perhaps someday fix the missing NS for some domains, or the incorrect glue for others.)...</div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;"><br></div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;">The dnssec-keygen calls acquired -A and -R switches. And, the intent was for -A to be +7d, but the d got missed....so that's why its 7 seconds after creation.</div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;"></div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;"><br></div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;">So, can I just remove the Revoke line (is there an option in dnssec-settime to do this?) and have things fixed...or do I need to do some kind of emergency ZSK rollover to get things sane again?</div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;"><br></div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;">Though why is the only a problem with Comcast....the other report named Xfinity as the ISP, which is Comcast....</div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;"><br></div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;"><br></div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;"><br></div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;"><br></div><div id="a06dad34-2af0-4f37-a98e-f45710da10c1" style="font-family: arial, helvetica, sans-serif;"><br></div></div></body></html>