ZSK rollover weirdness

Casey Deccio casey at deccio.net
Mon Sep 9 17:26:59 UTC 2013


On Fri, Sep 6, 2013 at 1:32 PM, Lawrence K. Chen, P.Eng. <lkchen at ksu.edu>wrote:

>
>
> ------------------------------
>
>
>
> So, can I just remove the Revoke line (is there an option in
> dnssec-settime to do this?) and have things fixed...
>
>
> guess dnssec-settime -A none -R none will remove it....but guessing
> there's more to fixing my current mess?
>

Adding the revoke bit was not useful, but wasn't in and of itself harmful.
The harmful part, and what likely was the cause of validation errors, was
that you began exclusively signing your zone contents before it had been
pre-published long enough for versions of the DNSKEY RRset without the key
to expire in cache.  Here's what I see:

2013-09-04 19:15 UTC
only ZSK with id 14565 exists and is signing zone
http://dnsviz.net/d/ksu.edu/UieG7w/dnssec/

2013-09-05 01:38 UTC
new ZSK with id 44538 is signing, as is now revoked key 14565 (now with id
14693)
http://dnsviz.net/d/ksu.edu/UifggA/dnssec/

Somewhere between that roughly six-hour period, the new ZSK was introduced
and the RRSIGs made by the new ZSK became the only useful ones since the
old key had been marked as revoked.  Now consider a validating resolver
that retrieved the DNSKEY RRset at 2013-09-04 19:15 UTC.  The TTL suggests
it can be cached for 24 hours--that is, 18 hours after DNSViz first notes
the presence of the new ZSK and RRSIGs that can only be validated by that
new ZSK.  This example validating resolver will now have issues validating
names in ksu.edu until the cache expires 24 hours after new ZSK was
introduced.  Such is the window for failure.

Regards,
Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130909/783d3e7c/attachment.html>


More information about the bind-users mailing list