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@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@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 > _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
