Explicit support for conservative DNSSEC algorithm rollover (RFC 6781 4.1.4)
I couldn't find an explicitly documented way to use
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-signzone (from bind 9.16.15-debian) can, in fact, be coerced into rolling out the
RRSIGs before the
$ 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
example.signed file will contain
RRSIGs 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
example.signed is missing both
RRSIGs and the
DNSKEY for algorithm 8. In order to be RFC 6781-compliant, we need to remove the
DNSKEY before the
RRSIGs 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 -Sshould output
RRSIGs (but not the
DNSKEY) if the key deletion date is in the past but the key inactivation date is in the future. The
dnssec-settimewarning shown above should be removed. The
dnssec-settimemanpage 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.