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 RRSIGs 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 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

The resulting 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 -S should 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-settime warning shown above should be removed. The dnssec-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.