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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
