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