On Mar 8 2012, I wrote: [...]
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.
The answer is (as one might expect) that it only approximately does the hoped-for thing ... :-) Refer to Figure 2 in section 6.6 of the IANA document. Assume one starts off with a managed-keys entry for KSK(n) and that there are no compromised keys. During time slots 2-6 (a 50-day period) KSK(n) and KSK(n+1) are published, signed with KSK(n). BIND starts the 30-day "add hold-down time" for KSK(n+1) the first time it sees this, and after that trusts both KSKs. [If the BIND instance has been offline for a while and its 30 days has not yet elapsed by the end of slot 6, BIND will not yet trust KSK(n+1) and SERVFAILs result thereafter. But only until the BIND instance is restarted, because of the bug(?) I described in the previous posting.] During time slot 7, KSK(n) and KSK(n+1) are published signed with KSK(n+1), and BIND is happy with that. During time slot 8, KSK(n) is published as revoked, but the keyset is signed only by KSK(n+1). BIND doesn't like that, reporting general: warning: managed-keys-zone ./IN: Active key for zone '[test-zone]' is revoked but did not self-sign; ignoring.
From time slot 9 onwards, KSK(n) is removed from the published
keyset. As BIND still has both KSK(n) and KSK(n+1) as valid trust anchors, never properly revoked, it unhappily keeps reporting that KSK(n) has unexpectedly disappeared. I cannot fault BIND's implementation of RFC 5011 here. The end result is half-satisfactory in that BIND now trusts the new KSK(n+1) and is validating successfully. But it also still trusts KSK(n), and complains about its absence, until one intervenes manually. Which, incidentally, isn't particularly easy to do except by e.g. stopping the BIND instance, editing its managed-keys.bind file to remove the noxious entry, and then restarting it. -- 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