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