[Opendnssec-user] About the lifetime for ZSK

Berry A.W. van Halderen berry at nlnetlabs.nl
Tue Dec 1 13:31:15 UTC 2015


On 12/01/2015 01:57 PM, gaolei wrote:
> Hi,all
> 
>     Here is a question about the ZSK lifetime in OPENDNSSEC.
> 
>     A key in 'retire' status seems to still being used to sign new RR.
> 
>     But the 'active' key was not used to generate signature of RR.
> 
>     It seems a little strange to understand the lifetime of ZSK.
> 
>     Does it mean the OPENDNSSEC was working  abnormally?

It is a correct operation that key in retire status is still used for
signing.  It is not dead yet.  Retire means that it is "on its way out",
hence still used, but being phased out and cannot be relied upon as a
sole chain of trust.
An key in publish state is the reverse equivalent of a retire key.  It
is being introduced.


>     My operations can be seen as below:
> 
>     Firstly I list the keys in  HSM for my test zone 'testzone17' 
> 
>     [gtld at index1 OpenDNSSEC-1.4.7]$ ./bin/ods-ksmutil key list -v|grep testzone17
> 
>     MySQL database host set to: 202.173.9.4
>     MySQL database port set to: 3306
>     MySQL database schema set to: KASP
>     MySQL database user set to: kaspuser
>     MySQL database password set
>     testzone17                        KSK           active    2016-11-27 14:52:29 (retire)   2048    8           6cb0c7e105a7c16c6288f9aa07fdbfba  SoftHSM                           28169
>     testzone17                        ZSK           retire    2015-12-15 18:57:41 (dead)     1024    8           65a3928d9595fd3112b6b021c990c040  SoftHSM                           25146
>     testzone17                        ZSK           active    2016-02-29 18:42:41 (retire)   1024    8           92be2b8c731a8c55ece4b49a2a02a7ed  SoftHSM                           61185
> 
> 
>     We can see testzone17 has a retire ZSK with keytag 25146  and a
> active ZSK with keytag 61185
>     
>     Then I add a name testsign.testzone17 by nsupdate to the inbind of
> my OPENDNSSEC.
> 
>     And after that I dig the outbind for the signature of the newly
> added name.
> 
>     We can see the name was signed with the ZSK of keytag 25146.
> 

Actually no, the answer from the dig gave no an authorative answer that
testsign.testzone17 was not found.  I guess the change was not
propagated though correctly (update in SOA serial needed?).  The answer
returned contained a signed SOA with the new active key 61185.  But the
chain proving the testsign.testzone17 did not exist is still signed with
the old key.  I do find this strange, but the outward bind could still
have this cached.

It is a easier to get through if you first used file based zones, rather
than IXFRs because the named causes a additional factor to be explained.
 I would expect the 25146 key to be used there.

With kind regards,
Berry van Halderen


>   [gtld at index1 OpenDNSSEC-1.4.7]$ dig @202.173.9.4 testsign.testzone17 +dnssec
> 
> ; <<>> DiG 9.9.4 <<>> @202.173.9.4 testsign.testzone17 +dnssec
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61685
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;testsign.testzone17.     IN      A
> 
> ;; AUTHORITY SECTION:
> testzone17.             300       IN      SOA     ns.testzone17. dns.knet.cn. 2015093828 3600 600 2419200 300
> testzone17.             300       IN      RRSIG   SOA 8 1 300 20151215015340 20151201112051 61185 testzone17. l/UGnPP5ZThtRmqYIAm5i5ym/E55jYZ8h6wE0dR1qZ74VJeUDNoMt0me HJGHkVVtEH4cAzydnmhYisbdALcmyCYCXAONxSebADKHdOac0vNLDjCN Ts8m7JHu/7c+xWxTmLvlMqaZ9uhH+80SUiLTBCNgVaKt66fniPenAh18 YJI=
> u71sa7b4ru372fosbkgmh8p5mbp7h1qu.testzone17. 300 IN NSEC3 1 0 5 08E3A6EDB04A2731 U71U56T3UQ1NDGFKUL2HF6I24VKU32MT NS SOA RRSIG DNSKEY NSEC3PARAM
> u71sa7b4ru372fosbkgmh8p5mbp7h1qu.testzone17. 300 IN RRSIG NSEC3 8 2 300 20151214174432 20151201002831 25146 testzone17. URbT4RFGMZ09mLNsc5QRn9B3yPXv34b/2KvA4SSHlCOQUNnVTElH+XCG ycYSaB0uW49GztkJmDU7us0R4mN/sNxuOr/xaTvs8ZgQ6Eo+2gDv7qUq +LNnfDlFXC4VutrCoRxJgy2gLAikc7IS+/EAunMwuqHOJQ41vjqEz7Ew 6w0=
> nav551fe2asnh5siv11agp6sta2mhf6r.testzone17. 300 IN NSEC3 1 0 5 08E3A6EDB04A2731 NAVCM3RLBCL3SU3F8HQ3KCOM1VG7DGR5 NS
> nav551fe2asnh5siv11agp6sta2mhf6r.testzone17. 300 IN RRSIG NSEC3 8 2 300 20151215114940 20151201002831 25146 testzone17. dWseMgX8GCsDIjlXqbjXD3qJcKr9YAsnb1dBKtSo8lMPA7GX8sRFfFcH IcFNxUERbNogkhhzZfkc3EhU0yKim1EcKHAceYC4UPQhChRTaGmt04Le N/9N8/u12I+MkxHKu4jTTRsGzmoNrUHXTAB0xv8pt0Ci41QV3rz/K5we C1s=
> vcst3kqsluj7hok10l437hba96ejn8i8.testzone17. 300 IN NSEC3 1 0 5 08E3A6EDB04A2731 VCTT5PCLG65B13OPF9O42RP2FL71NIU8 NS
> vcst3kqsluj7hok10l437hba96ejn8i8.testzone17. 300 IN RRSIG NSEC3 8 2 300 20151215064016 20151201002831 25146 testzone17. ZPVglgJZdzeq+Ye0aQ7abw8i4B4DB5kY/bC1KWx7frXNBuuF8mVywSP+ AIJvsB79oR490zaGiY6pbbbfSPcOYUaZ+l/5s/C2axDSYa9MfjjW0Or+ DcDrXluas3cbUjT6Xv8YWZPUOpqRJJZOBPFKH5Dsc5YfQh1e9WCCOGv1 VMM=
> 
> ;; Query time: 3290 msec
> ;; SERVER: 202.173.9.4#53(202.173.9.4)
> ;; WHEN: Tue Dec 01 20:39:05 CST 2015
> ;; MSG SIZE  rcvd: 1020
> 




More information about the Opendnssec-user mailing list