Changing ZSK-lifetime in dnssec-policy is not applied

Tom lists at verreckte-cheib.ch
Mon Feb 14 11:57:41 UTC 2022


Hi Matthijs

Perfect, thank you for this information and clarifying this.

Best regards,
Tom


On 14.02.22 09:59, Matthijs Mekking wrote:
> Hi Tom,
> 
> The lifetime is applied to new keys, so when the ZSK is rolled the 
> lifetime of the successor key should be 60 days.
> 
> I have considered applying it to existing keys as well (and maybe we 
> will some day), but there are a bunch of corner cases that make it 
> non-trivial, especially when keys are involved that are in the middle of 
> a rollover.
> 
> Best regards,
>    Matthijs
> 
> On 11-02-2022 13:16, Tom wrote:
>> Hi
>>
>> Using BIND-9.16.22 and dnssec-policy:
>>
>> I've migrated an already existing and signing "auto-dnssec"-configured 
>> zone to dnssec-policy (same algorithms). That worked without any 
>> issues. After a while, I changed the ZSK lifetime from 30d to 60d (see 
>> below) in the dnssec-policy:
>>
>> dnssec-policy "thewaytogo" {
>>      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;
>> };
>>
>>
>> After reloading/restarting named, I can't see the new lifetime 
>> (scheduled rollover), neither in the rndc-output, nor in the keyfile 
>> itself (ZSK 63304). The new lifetime should be 12/13 Apr and not 13 Mar.
>>
>> # rndc-output
>> $ rndc dnssec -status example.com
>> dnssec-policy: thewaytogo
>> current time:  Fri Feb 11 13:02:10 2022
>>
>> key: 455 (ECDSAP256SHA256), ZSK
>>    published:      yes - since Wed May 20 14:50:09 2020
>>    zone signing:   no
>>
>>    Key is retired, will be removed on Mon Jun 29 15:55:09 2020
>>    - goal:           hidden
>>    - dnskey:         omnipresent
>>    - zone rrsig:     unretentive
>>
>> key: 63304 (ECDSAP256SHA256), ZSK
>>    published:      yes - since Fri Feb 11 08:19:18 2022
>>    zone signing:   yes - since Fri Feb 11 09:24:18 2022
>>
>>    Next rollover scheduled on Sun Mar 13 07:19:18 2022
>>    - goal:           omnipresent
>>    - dnskey:         omnipresent
>>    - zone rrsig:     rumoured
>>
>> key: 39500 (ECDSAP256SHA256), KSK
>>    published:      yes - since Wed May 20 14:50:09 2020
>>    key signing:    yes - since Wed May 20 14:50:09 2020
>>
>>    No rollover scheduled
>>    - goal:           omnipresent
>>    - dnskey:         omnipresent
>>    - ds:             omnipresent
>>    - key rrsig:      omnipresent
>>
>>
>>
>> # key-file
>> ; This is the state of key 63304, for example.com.
>> Algorithm: 13
>> Length: 256
>> Lifetime: 2592000
>> Predecessor: 455
>> KSK: no
>> ZSK: yes
>> Generated: 20220211071918 (Fri Feb 11 08:19:18 2022)
>> Published: 20220211071918 (Fri Feb 11 08:19:18 2022)
>> Active: 20220211082418 (Fri Feb 11 09:24:18 2022)
>> Retired: 20220313082418 (Sun Mar 13 09:24:18 2022)
>> Removed: 20220323092918 (Wed Mar 23 10:29:18 2022)
>> DNSKEYChange: 20220211092418 (Fri Feb 11 10:24:18 2022)
>> ZRRSIGChange: 20220211092418 (Fri Feb 11 10:24:18 2022)
>> DNSKEYState: omnipresent
>> ZRRSIGState: rumoured
>> GoalState: omnipresent
>>
>>
>>
>> Any hints for this?
>>
>> Many thanks.
>>
>> Best regards,
>> Tom


More information about the bind-users mailing list