BIND 9.16 introduced a new dnssec-policy feature as a further more automated DNSSEC key management and signing facility over the long established auto-dnssec maintain functionality.
The documentation does not appear to cover migrating from the old to the new, but the related wiki page seems to indicate that already existing keys would be picked up by dnssec-policy.
That said, setting up a new zone with dnssec-policy is straightforward enough, but migrating an existing zone from auto-dnssec maintain to dnssec-policy does not seem to work as one might expect.
What I would have expected was that a policy compatible with the existing keys would keep using these keys.
What seems to happen is that all existing keys are immediately deleted from the zone because they have "expired" and are replaced with new keys, even though the new policy mandates a compatible set of keys (same algorithm and size) and the existing keys have no end of life properties defined (only Created, Publish and Activate timings in the .key files).
The policy I've used when testing looks like this (named to reflect what is what during testing):
dnssec-policy alg13-ksk-unlimited-zsk-60day {
keys {
ksk key-directory lifetime unlimited algorithm ECDSAP256SHA256;
zsk key-directory lifetime P60D algorithm ECDSAP256SHA256;
};
};
This is the log output when the configuration changed from auto-dnssec maintain; to dnssec-policy alg13-ksk-unlimited-zsk-60day;:
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 the existing keys were immediately deleted (not even following the normal rollover procedure!) and replaced with new keys of the same type.
Considering that just instantly replacing the keys instead of following the intended rollover procedure breaks everything, it's apparent that simply switching the configuration to dnssec-policy is a no-go.
Looking at the key files, I note that an additional .state file is added side by side with both the old and the new keys.
I don't know if this file is a requirement for proper dnssec-policy operation somehow? Would having these files created beforehand somehow avoid this behavior?
The question at its core is: is there a way to migrate to using dnssec-policy in a non-disruptive manner? If so, how?
The behavior described in the question was a bug, which should be resolved as of BIND version 9.16.2.
From the BIND 9.16.2 Release Notes: