Customer feature request - dnssec-signzone to handle zone signing key pre-publish RRSIGs rollover gradually [ISC-support #15374]
Further to the 'generating big IXFRs is undesirable' set of bug reports and feature requests, this is another wish to add to the list.
From Support ticket #15374 and friends (whose general theme is around manually managing zone DNSSEC keys, DNSSEC signing and zone validation ahead of propagation to client-facing authoritative edge slaves).
The use case stems from the desire to be able to have in-propagation-path zone validation to make sure that the zone is never DNSSEC-broken as a result of a botched DNSSEC-related update (user/software/process error). There is also the need to move away from single-point-of-failure in the set-up and to have a disaster recovery plan in place for all eventualities. With the current tools available, it seems that there is a move amongst TLD operators away from automatic and inline DNSSEC maintenance and in the direction of more manual processes. Another driver for this is tooling that generates zone content, with the DNSSEC maintenance being a later 'add-on' to the process.
The bottom line is, that dnssec-signzone is being used increasingly for DNSSEC signature and NSEC/NSEC3 maintenance in production environments. This is working (mostly) just fine, including it parsing the input (a previously-signed zone, either as is, or with some pre-processing to re-inject the existing RRSIGs into a modified unsigned zone) and generating only the RRSIGs that are actually needed (didn't exist before, or older RRSIG needs refreshing etc..).
All good - except when we approach ZSK key rollover. In most instances, the favoured method is pre-publication of the new ZSK, followed by a gradual replacement of RRSIGs as they reach expiry, until all have been replaced, following which the old ZSK can be removed from the zone. Inline signing and 'auto-dnssec maintain' handle this exactly as needed (except that it's then not impossible, but harder to introduce a signed-zone validation step between zone update and zone propagation to client-facing slaves - and don't forget also, the other requirement for high-availability and disaster recovery).
The lack of support for pre-publication ZSK rollover by dnssec-signzone has been tackled once before - see:
3686. [func] "dnssec-signzone -Q" drops signatures from keys
that are still published but no longer active.
[RT #34990]
9.10.0, 9.9.5This, at least, allows the RRSIGs to be 'swapped' between the old and the new keys. But alas, it then generates a massive diff between the old and new version of the zone, instead of the desired gradual roll of RRSIGs. We already know that large IXFRs are undesirable (ref #1515 (closed), #1516, #1518 (closed), #1519 (closed)), so the lack of support by dnssec-signzone for gradual RRSIG replacement is disappointing.
Please could we have a new option - one that runs hand in hand with -Q and controls whether or not unexpired RRSIGs from the old key are replaced with new ones from the new key, or not, on this specific run of dnssec-sigzone. (It is assumed that the operator will run dnssec-signzone many times during rollover period - this is under their control and not something that dnssec-signzone itself would need to manage).