Exercising RFC 5011 rollovers
cet1 at cam.ac.uk
Sat Apr 21 20:29:48 UTC 2012
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
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.
Email: cet1 at cam.ac.uk
More information about the bind-users