Explicit support for conservative DNSSEC algorithm rollover (RFC 6781 4.1.4)
I couldn't find an explicitly documented way to use dnssec-settime
and dnssec-signzone -S
(smart signing) to perform a "conservative" DNSSEC algorithm rollover as described in RFC 6781 section 4.1.4.
That RFC describes a procedure that involves publishing additional RRSIGs with the algorithm first, wait until old RRSIG RRsets have expired, and only then add the new DNSKEY. The reason why algorithm rollovers have to be done in this precise order is because an RRSIG RRset must contain at least one key for each algorithm that is used in the DNSKEY RRset. (See RFC 4035 2.2 and RFC 6840 5.11.) If that order is not followed, a cache could end up with a new DNSKEY using the new algorithm, alongside RRSIGs that are missing the new algorithm, which is not standard-conformant.
The same applies in reverse when removing an algorithm: the DNSKEY should be removed first, and RRSIGs should only be removed after the DNSKEY removal has propagated.
The Algorithm rollover section of the bind DNSSEC guide seems to describe a procedure where the DNSKEY and RRSIG records are added/removed at the same time, which violates RFC 6781 section 4.1.4.
Digging a little deeper, I noticed that dnssec-settime
and dnssec-signzone
(from bind 9.16.15-debian) can, in fact, be coerced into rolling out the RRSIG
s before the DNSKEY
:
$ echo '@ 300 IN SOA example. example. (123 5m 5m 5m 5m)' > example
$ dnssec-keygen -f KSK -a 8 example.
$ dnssec-keygen -f KSK -a 13 example.
$ dnssec-settime -A -1w -P +1w Kexample.+013+*.key
$ dnssec-signzone -z -S example
The resulting example.signed
file will contain RRSIG
s for algorithms 8 and 13, but only the DNSKEY
for algorithm 8. This is great and can be used for RFC 6781-compliant algorithm rollover, but let's note that this behaviour seems somewhat unintended and is completely undocumented - in fact, it directly contradicts dnssec-settime(8)
, which states that after the activation date the "key is included in the zone".
A more serious problem is that it doesn't seem possible to do this in reverse for algorithm removal:
$ dnssec-settime -D -1w -I +1w Kexample.+008+*.key
dnssec-settime: warning: Key is scheduled to be deleted before it is
scheduled to be inactive.
$ dnssec-signzone -z -S example
The resulting example.signed
is missing both RRSIG
s and the DNSKEY
for algorithm 8. In order to be RFC 6781-compliant, we need to remove the DNSKEY
before the RRSIG
s but it doesn't look like that's possible with the current implementation of smart signing.
It looks like the following changes are required for bind9 smart signing to support conservative algorithm rollover as described in RFC 6781 4.1.4:
-
dnssec-signzone -S
should outputRRSIG
s (but not theDNSKEY
) if the key deletion date is in the past but the key inactivation date is in the future. Thednssec-settime
warning shown above should be removed. Thednssec-settime
manpage should be updated accordingly. - The "Algorithm rollovers" section of the DNSSEC guide should be updated to explain how to do a RFC 6781 conservative rollover using
dnssec-settime
, i.e. using reversed activation/publication and deletion/inactivation dates.