Signature-refresh determines when the RRSIGs will be replaced by looking at the
expiration time and working backwards. New RRSIGs are generate Using
signature-interval.
--
Mark Andrews
> On 11 May 2022, at 18:15, Tom wrote:
>
> 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
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
> this list
>
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
