After switching to "dnssec-policy", existing RRs are still signed with the "old" ZSK
Tom
lists at verreckte-cheib.ch
Wed May 11 08:15:34 UTC 2022
Hi list
After switching from "semi-automatic"-signing to dnssec-policy
(everything identical, except new ZSK rollover) I have the following
rndc output:
$ rndc dnssec -status example.ch
dnssec-policy: 60d_zsk_rollover
current time: Wed May 11 09:54:55 2022
key: 45819 (ECDSAP256SHA256), KSK
published: yes - since Mon Apr 27 08:00:01 2020
key signing: yes - since Mon Apr 27 08:00:01 2020
No rollover scheduled
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
key: 17242 (ECDSAP256SHA256), ZSK
published: yes - since Mon May 9 16:25:59 2022
zone signing: yes - since Mon May 9 17:30:59 2022
Next rollover scheduled on Fri Jul 8 15:25:59 2022
- goal: omnipresent
- dnskey: omnipresent
- zone rrsig: rumoured
key: 52021 (ECDSAP256SHA256), ZSK
published: yes - since Mon Apr 27 08:00:01 2020
zone signing: no
Key is retired, will be removed on Mon Jul 6 09:05:01 2020
- goal: hidden
- dnskey: omnipresent
- zone rrsig: unretentive
The ZSK 52021 is the old one (from semi-automatic), the ZSK 17242 is the
new one, which was created after reloading named while applying the new
dnssec-policy.
The current behavior I see is, that already existing RR are still signed
with the "old" key (52021) and newly created RR are signed with the new
ZSK (17242). Is this normal behavior and yes, after which time will the
existing RR also be signed with the new ZSK (17242)?
The dnssec-policy configuration looks like this:
dnssec-policy "60d_zsk_rollover" {
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;
dnskey-ttl 3600s;
publish-safety 1h;
retire-safety 1h;
purge-keys 10d;
keys {
ksk lifetime unlimited algorithm ecdsap256sha256;
zsk lifetime 60d algorithm ecdsap256sha256;
};
zone-propagation-delay 300s;
max-zone-ttl 86400s;
parent-propagation-delay 1h;
parent-ds-ttl 3600;
nsec3param iterations 0 optout no salt-length 0;
};
Many thanks for hints/explanations.
Best regards,
Tom
More information about the bind-users
mailing list