Non-disruptive migration to dnssec-policy possible?

[Håkan Lindqvist]

Hello,

I have seen essentially this same question/problem posed by others in 
other forums but never seen any proper answers to it.
I have now tried this myself with BIND 9.16.1 and faced the exact same 
issue that I had previously read about.

How does one migrate an already signed zone from "auto-dnssec maintain" 
to "dnssec-policy x" in a non-disruptive manner?

The manual 
(https://ftp.isc.org/isc/bind9/cur/9.16/doc/arm/Bv9ARM.ch05.html#dnssec_policy_grammar) 
does not appear to cover this this scenario and the DNSSEC Guide 
(https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html) does not 
mention dnssec-policy at all.

However, the wiki 
(https://gitlab.isc.org/isc-projects/bind9/-/wikis/DNSSEC-Key-and-Signing-Policy-(KASP)#key-generation) 
appears to suggest that existing keys would be picked up.

With that in mind, one might naively think that switching to a 
keytype-compatible dnssec-policy should be safe, but in practice it 
appears to be anything but.

Eg existing KSK+ZSK algo 13 keys seem like they could (and arguably 
should) be carried over to a policy mandating KSK+ZSK and algo 13 
(particularly if the policy has unlimited lifetime for the key, but even 
with limited lifetime one would hope that the regular rollover timers 
would be applied).

In practice when you change the zone configuration to use dnssec-policy, 
all existing keys are immediately yanked and replaced with new keys. No 
timers or anything seem to matter.


This is what my own test looked like:

Existing  KSK+ZSK keys with only these timings present in the .key files:

Created:
Publish:
Activate:

And a policy like this (named to reflect what is what while testing):

dnssec-policy alg13-ksk-unlimited-zsk-60day {
     keys {
         ksk key-directory lifetime unlimited algorithm ECDSAP256SHA256;
         zsk key-directory lifetime P60D algorithm ECDSAP256SHA256;
     };
};

And this is the log output when first loading BIND after changing the 
configuration to use that dnssec-policy:

zone zone.example/IN (signed): reconfiguring zone keys
keymgr: DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) created for 
policy alg13-ksk-unlimited-zsk-60day
keymgr: DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) created for 
policy alg13-ksk-unlimited-zsk-60day
Removing expired key 20481/ECDSAP256SHA256 from DNSKEY RRset.
DNSKEY zone.example/ECDSAP256SHA256/20481 (ZSK) is now deleted
Removing expired key 12506/ECDSAP256SHA256 from DNSKEY RRset.
DNSKEY zone.example/ECDSAP256SHA256/12506 (KSK) is now deleted
Fetching zone.example/ECDSAP256SHA256/49004 (KSK) from key repository.
DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) is now published
DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) is now active
Fetching zone.example/ECDSAP256SHA256/54646 (ZSK) from key repository.
DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) is now published
DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) is now active
zone zone.example/IN (signed): next key event: 22-Mar-2020 15:08:19.805

As can be seen, it immediately deleted the existing keys, claiming that 
they were "expired".

One could argue that the ZSK certainly was old enough to be expired 
(even though I would still maintain that it must do a proper rollover 
starting from now rather than just yanking the key), but the KSK policy 
was "lifetime unlimited" and nothing about end of life in the existing 
.key file. How can such a key even be "expired"?

I did notice that the key files (both old and new) also got a 
corresponding .state file created as part of this process. Is that 
relevant to the problem?
Ie, do existing keys need this file to be used properly, if so is there 
tooling to generate these?

Any suggestions?


Regards,
Håkan Lindqvist