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: c...@cam.ac.uk _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
