ZSK rollover weirdness

Lawrence K. Chen, P.Eng. lkchen at ksu.edu
Fri Sep 6 20:01:13 UTC 2013


----- Original Message -----

> On Fri, Sep 6, 2013 at 10:22 AM, Evan Hunt < each at isc.org > wrote:

> > The revoke bit has no defined meaning for a ZSK.
> 
> 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]:
> A key is considered revoked when the resolver sees the key in a
> self-signed RRSet and the key has the REVOKE bit (see Section 7
> 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.
> 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.

> Casey

> [1] http://tools.ietf.org/html/rfc5011#section-2.1
> [2] http://tools.ietf.org/html/rfc6840#section-6.2
> [3] http://tools.ietf.org/html/rfc4034#section-2.1.1

> > It's used for updating
> 
> > trust anchors via RFC 5011. The code allows you to set it (just as
> > it
> 
> > allows you to use a ZSK as a KSK), but I don't recommend it.
> 

> > Unless there are resolvers that have managed-key trust anchors
> > configured
> 
> > for ksu.edu , you shouldn't bother with the revoke bit for your KSK
> > either.
> 

> > --
> 
> > Evan Hunt -- each at isc.org
> 
> > Internet Systems Consortium, Inc.
> 

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. 

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 

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.)... 

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. 

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? 

Though why is the only a problem with Comcast....the other report named Xfinity as the ISP, which is Comcast.... 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130906/c9a3ba7b/attachment.html>


More information about the bind-users mailing list