Julian Brost
2018-01-07 20:07:21 UTC
Hi,
I have some troubling understanding what happened regarding two KSK
rollovers I did for testing purposes on one zone.
In these rollovers, the following three KSKs were involved (identified
by their key tag as well as a letter to make reading easier later):
55883 (A) -> 55828 (B) -> 23035 (C).
The first rollover (A -> B) happened without issues, including updating
the DS records in the parent zone, so I issued a ds-seen command for B
and a ds-gone command for A.
Now, next day, next rollover (B -> C), so far I only issued the rollover
command, no ds-seen/ds-gone so far, which can also be seen in the key
list output. OpenDNSSEC now outputs a signed zone file which only
contains DNSKEY records for the keys A and C, but not for B, which is
the only key that is currently referenced via a DS record in the parent
zone. This resulted in the zone becoming unresolvable.
Now I'm wondering why this happens and if this might be a bug in
OpenDNSSEC. At least it isn't consistent with my current understanding
on how key rollovers work with OpenDNSSEC. I always trigger a rollover
(or wait for the automatic rollover), wait until the key becomes ready,
add/remove all DS records in the parent zone according to 'waiting for
ds-seen/ds-gone' output in the key list and issue the ds-seen/ds-gone
commands as soon as the changes appear on the nameservers of the parent
zone. So from my understanding, the zone should be resolvable with both
only the old and only the new DS record present in the parent zone. Is
there any problem with this approach? Unfortunately I didn't find any
documentation that clearly states how to properly do a KSK rollover
(like issue this command, wait for that, etc.).
See the attached file `log.txt` for the syslog snippets showing the
involved keys and the output of `ods-enforcer key list` as of now.
OpenDNSSEC version is 2.1.3, running on Debian sid. Let me know if you
need any additional information.
Regards,
Julian
I have some troubling understanding what happened regarding two KSK
rollovers I did for testing purposes on one zone.
In these rollovers, the following three KSKs were involved (identified
by their key tag as well as a letter to make reading easier later):
55883 (A) -> 55828 (B) -> 23035 (C).
The first rollover (A -> B) happened without issues, including updating
the DS records in the parent zone, so I issued a ds-seen command for B
and a ds-gone command for A.
Now, next day, next rollover (B -> C), so far I only issued the rollover
command, no ds-seen/ds-gone so far, which can also be seen in the key
list output. OpenDNSSEC now outputs a signed zone file which only
contains DNSKEY records for the keys A and C, but not for B, which is
the only key that is currently referenced via a DS record in the parent
zone. This resulted in the zone becoming unresolvable.
Now I'm wondering why this happens and if this might be a bug in
OpenDNSSEC. At least it isn't consistent with my current understanding
on how key rollovers work with OpenDNSSEC. I always trigger a rollover
(or wait for the automatic rollover), wait until the key becomes ready,
add/remove all DS records in the parent zone according to 'waiting for
ds-seen/ds-gone' output in the key list and issue the ds-seen/ds-gone
commands as soon as the changes appear on the nameservers of the parent
zone. So from my understanding, the zone should be resolvable with both
only the old and only the new DS record present in the parent zone. Is
there any problem with this approach? Unfortunately I didn't find any
documentation that clearly states how to properly do a KSK rollover
(like issue this command, wait for that, etc.).
See the attached file `log.txt` for the syslog snippets showing the
involved keys and the output of `ods-enforcer key list` as of now.
OpenDNSSEC version is 2.1.3, running on Debian sid. Let me know if you
need any additional information.
Regards,
Julian