Exercising RFC 5011 rollovers

Chris Thompson cet1 at cam.ac.uk
Thu Mar 8 16:04:48 UTC 2012


Continuing a thread from November & January (these experiments do
take a long time, absent a fake clock)...

One experiment I have been doing is to see whether a rollover done
as described in https://www.iana.org/dnssec/icann-dps.txt (which is
only approximately RFC 5011-like) would cause BIND's managed-keys to
do the hoped-for thing or not. That isn't complete yet - I will report
on the results in due course.

However, I have found one oddity/bug/whatever. I had one testing BIND
instance offline for a while so that it had not yet seen new-KSK for
30 days when the test zone transitioned

  from  (old-KSK,new-KSK,ZSK)-signed-with-old-KSK
    to  (old-KSK,new-KSK,ZSK)-signed-with-new-KSK

At that point it correctly started giving SERVFAILs for the test zone.
However, the entry in managed-keys.bind for new-KSK kept the same
(time-first-seen)+30days value for when it was going to start trusting
it. Even when this time arrived, it didn't start trusting new-KSK, as
I think BIND was acting on this from the RFC

   Once the timer expires, the new key will be added as a trust anchor
   the next time the validated RRSet with the new key is seen at the
   resolver.

(Emphasis on "next time" and "validated"!)

But now I restarted the BIND instance. It sees in managed-keys.bind that
the time it was going to start trusting new-KSK has passed, so it thinks
it must be OK now. It adds it to the trust anchors (e.g. as seen by
"rndc secroots") and the SERVFAILs no longer occur.

I think this may indicate that the data structure in managed-keys.bind
cannot quite capture all the complexities of RFC 5011.

The BIND version used in the later part of this experiment was (early-access)
9.8.2rc2 but I doubt that is particularly significant.

-- 
Chris Thompson
Email: cet1 at cam.ac.uk



More information about the bind-users mailing list