DNSKEY RRset signed by ZSK during key rollover despite "dnssec-dnskey-kskonly yes;" and "update-check-ksk yes;"
This only happens with the KSK private key offline. This key shouldn't be needed for this operation because the DNSKEY RRset does not change, and the RRset already has a covering RRSIG with a long validity.
If the private KSK is available when the key metadata changes so that that the 'new' ZSK becomes active and the old ZSK is inactive, then the DNSKEY RRset doesn't get signed by the new ZSK, so it's clearly a problem in the decision-making on whether or not to sign the DNSKEY RRset not taking into account the existing signatures and policy when the KSK is unavailable, whereas the decision is correctly made when it is - despite BIND not needing the private key or to generate any new signatures from it.
BIND version used
Steps to reproduce
On ZSK rollover use rndc loadkeys with KSK online on a keyset with:
One old key that gets timing delete now one new key that gets timing publish now one current key that gets timing inactivate in + 3 hours one unused key (previous new) in the zone that gets timing activate in +3 hours.
3 hours later ( KSK is offline at this point) BIND does the ZSK roll from the unused to current and from current to old. It is at this time a second RRSIG appears on the DNSKEY signed by the new ZSK key that gets activated.
What is the current bug behavior?
Unnecessary (and contrary to named.conf configuration options) the newly activated ZSK signs the DNSKEY RRset despite:
- no changes to the DNSKEY RRset
- configuration that says 'only sign the DNSKEY RRset with the KSK'
- Existing and valid/covering KSK RRSIG with long lifetime (doesn't need to be refreshed).
What is the expected correct behavior?
The new ZSK doesn't sign the DNSKEY RRset
This issue was reported in Support ticket #13757