<html><head><meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"><style>body { line-height: 1.5; }blockquote { margin-top: 0px; margin-bottom: 0px; margin-left: 0.5em; }body { font-size: 10.5pt; font-family: ??; color: rgb(0, 0, 0); line-height: 1.5; }body { font-size: 10.5pt; color: rgb(0, 0, 0); line-height: 1.5; font-family: ??; }</style></head><body>
<div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">Hi,all</span></div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br></span></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>Here's new example for zone .testzone about the ZSK functioning abnormally.</div><div><br></div><div>The ZSK with keytag '10611' is retired and the ZSK with keytag '3894' is active.</div><div><br></div><div>But the newly added names are signed by the retired ZSK but not the active one.</div><div><br></div><div>It seems not to comply with the key rollover logic of OPENDNSSEC defined in </div><div><span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;">https://wiki.opendnssec.org/display/DOCS/Key+Rollovers</span></div><div>The rollover rules defined in above page are almost the same with RFC 7853,Section <span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;">3.2.1.</span></div><div><br></div><div>And the most strange thing is , the active key could not be seen in the zone , only the old ZSK can be returned when digging the dnskey list.</div><div><br></div><div>We tried ods-signer 'update testzone' and 'update all' but it did not work.</div><div><br></div><div>Can anyone give some comments on this case?</div></blockquote><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br></span></div><div>
<span style="font-size: 10.5pt; line-height: 1.5; background-color: window;">[gtld@SST03 ~]$</span><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">./bin/ods-ksmutil key list -v|grep testzone<br>MySQL database host set to: 100.73.8.241<br>MySQL database port set to: 3306<br>MySQL database schema set to: KASP<br>MySQL database user set to: kaspreadonly<br>MySQL database password set<br>testzone KSK ready waiting for ds-seen (active) 2048 8 6f5837039e487db96b380faad019bfaa SoftHSM 21986<br></span>testzone<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> ZSK active 2016-02-27 21:04:01 (retire) 1024 8 eff2c8625016a45b9be4344f3085f615 SoftHSM 3894<br></span>testzone<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> ZSK </span><span style="background-color: rgba(0, 0, 0, 0);"><font color="#ff0000">retire </font></span><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">2015-12-14 10:04:01 (dead) 1024 8 62728e03e303ecfa703c19452a0f71aa SoftHSM </span><span style="background-color: rgba(0, 0, 0, 0);"><font color="#ff0000">10611</font><br></span><div> </div>
<div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">[gtld@SST03 ~]$ dig @</span>202.173.9.4<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> -p1053 leqidg.testzone +dnssec<br><br>; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @</span>202.173.9.4<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> -p1053 leqidg.</span>testzone <span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> +dnssec<br>; (1 server found)<br>;; global options: +cmd<br>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43122<br>;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1<br>;; WARNING: recursion requested but not available<br><br>;; OPT PSEUDOSECTION:<br>; EDNS: version: 0, flags: do; udp: 4096<br>;; QUESTION SECTION:<br>;leqidg.</span>testzone<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">. IN A<br><br>;; AUTHORITY SECTION:<br>leqidg.testzone. 3600 IN NS ns4.example.net.<br>leqidg.testzone. 3600 IN NS ns3.example.net.<br>biggqj6qp6lrnvhk4iguqmi16pn454sj.testzone. 3600 IN NSEC3 1 0 5 852EA552F14CCC6E BIGH0C86JF1IFJ0L0SC9L6PQA0ITINIJ NS<br>biggqj6qp6lrnvhk4iguqmi16pn454sj.testzone. 3600 IN RRSIG NSEC3 8 2 3600 20151217041247 20151203093030 </span><span style="background-color: rgba(0, 0, 0, 0);"><font color="#ff0000">10611 </font></span>testzone<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">. ikl6kAY4p6d4qWgo1t5rWOxmetLASSBrUxJTUB+J+Wso00aKJNKPP33Y JhrfKn/Nw14Y3dvZ6ff1dEypf+/EMUbzYh3hDp1EhMspnBRz2tlEMjxE ZAjNGTLrtJdVvXNn7y8Ib1jEn5kKLpSl6zWwM7IEToQC1SBpYh2eG8fL 8qk=<br><br>;; Query time: 5 msec<br>;; SERVER: </span>202.173.9.4<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">#1053(</span>202.173.9.4<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">)<br>;; WHEN: Thu Dec 3 19:21:30 2015<br>;; MSG SIZE rcvd: 335<br></span> </div></div>
<div><span></span> <span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;">[gtld@SST03 ~]$ dig @</span>202.173.9.4<span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;"> -p1053 testzone dnskey +dnssec</span></div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br>; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @</span>202.173.9.4<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> -p1053 </span>testzone <span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">dnskey +dnssec<br>; (1 server found)<br>;; global options: +cmd<br>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19023<br>;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1<br>;; WARNING: recursion requested but not available<br><br>;; OPT PSEUDOSECTION:<br>; EDNS: version: 0, flags: do; udp: 4096<br>;; QUESTION SECTION:<br>;</span>testzone<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">. IN DNSKEY<br><br>;; ANSWER SECTION:<br></span>testzone<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">. 3600 IN DNSKEY 257 3 8 AwEAAaxnzYRHBsjsbCr5kCLBE5UVGu35Y10TDwmQUr/zccEOFwVIrIVK +/uE2XAZVCNtrzk3em3f0cbpHCZgBTUj6o3kRzawwJPGRWo++EijYlsb I3hD+JIUyPrS6ujRI77tjkNZ7oT+zcxQJcGBx0qXhRbTfAgX0WdaRNAE xf4yivvk73wbHtLHe+8uo5GJ1knnPB/1uxWSVCIRUocESZiAR/MKzMtg ER1sUwjZSDOOjO8SkwuMdaX0fU5sOV0cusXD5whT22AplwSUnXONiDM+ aCHs43SdkbIrX4cxoKjlXou+xQd443yAsFE9BRIZBvFxPxFY89uGXpUp REkyMN0LvXU=<br></span>testzone<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">. 3600 IN DNSKEY 256 3 8 AwEAAafl9Q7tTD1w+w51dLa38lQNLfAUbVnn0TrHTtoPJGbjlH2dJ+rH x9wjBVUnMo4S49gl+F+WQmHzwmEs3DrQuofwereQkc5CBOlTx/Qoo8r5 jXaZMzagabDIzHObiVz6W+uIc/9wO92lACyvcWDNSmrDusJxPMJ6b1/D o7WJcCVx<br></span>testzone<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">. 3600 IN RRSIG DNSKEY 8 1 3600 20151214201633 20151201032253 21986 </span>testzone<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">. CA9810UOs3vsvltgTjjYkjUIUE8uJ9kUDhK21s2EHXfUaB1nlql5jooS dDvnz7aAzLwXGcGS3/IXX/aZvch0rzSTm5G970/Of9kjnG3/Cvkqbgts v47gE+6l7ylHucWQmvY5QtXrvVbrYHpO3HTSCTklXeSZDM2vJzuA7aLa LV/XwTVuJCZIRU7vFA8IVh5PUeD/yQKp2bGI7YtEdLZwsMmV5XQI3uKI WM/x31SOoFaTTALbeGQmfGhzWZKAnd68u/TbIAWAG/Dk4OzeXgdSVcl4 mpL4iEJd25TLZs0Rktl2TzdGWH6U/Sz+ZWbGcuZKCttkBGSpMdk6qf/D oSNyiQ==<br><br>;; Query time: 0 msec<br>;; SERVER: </span>202.173.9.4<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">#1053(</span>202.173.9.4<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">)<br>;; WHEN: Thu Dec 3 19:33:06 2015<br>;; MSG SIZE rcvd: 747<br></span>
<div> </div>
<hr style="WIDTH: 210px; HEIGHT: 1px" align="left" color="#b5c4df" size="1">
<div>2015-12-03 19:24:27</div>
<div>gaolei</div><blockquote style="margin-top: 0px; margin-bottom: 0px; margin-left: 2em;"><div> </div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"><div style="PADDING-RIGHT: 8px; PADDING-LEFT: 8px; FONT-SIZE: 12px;FONT-FAMILY:tahoma;COLOR:#000000; BACKGROUND: #efefef; PADDING-BOTTOM: 8px; PADDING-TOP: 8px"><div><b>From:</b> <a href="mailto:opendnssec-user-request@lists.opendnssec.org">opendnssec-user-request</a></div><div><b>Date:</b> 2015-12-02 20:00</div><div><b>To:</b> <a href="mailto:opendnssec-user@lists.opendnssec.org">opendnssec-user</a></div><div><b>Subject:</b> Opendnssec-user Digest, Vol 78, Issue 2</div></div></div><div><div>Send Opendnssec-user mailing list submissions to</div>
<div> opendnssec-user@lists.opendnssec.org</div>
<div> </div>
<div>To subscribe or unsubscribe via the World Wide Web, visit</div>
<div> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user</div>
<div>or, via email, send a message with subject or body 'help' to</div>
<div> opendnssec-user-request@lists.opendnssec.org</div>
<div> </div>
<div>You can reach the person managing the list at</div>
<div> opendnssec-user-owner@lists.opendnssec.org</div>
<div> </div>
<div>When replying, please edit your Subject line so it is more specific</div>
<div>than "Re: Contents of Opendnssec-user digest..."</div>
<div> </div>
<div> </div>
<div>Today's Topics:</div>
<div> </div>
<div> 1. Re: About the lifetime for ZSK (Berry A.W. van Halderen)</div>
<div> 2. Re: About the lifetime for ZSK (Yuri Schaeffer)</div>
<div> </div>
<div> </div>
<div>----------------------------------------------------------------------</div>
<div> </div>
<div>Message: 1</div>
<div>Date: Tue, 1 Dec 2015 14:31:15 +0100</div>
<div>From: "Berry A.W. van Halderen" <berry@nlnetlabs.nl></div>
<div>Subject: Re: [Opendnssec-user] About the lifetime for ZSK</div>
<div>To: opendnssec-user@lists.opendnssec.org</div>
<div>Message-ID: <565DA123.1060700@nlnetlabs.nl></div>
<div>Content-Type: text/plain; charset=windows-1252</div>
<div> </div>
<div>On 12/01/2015 01:57 PM, gaolei wrote:</div>
<div>> Hi,all</div>
<div>> </div>
<div>> Here is a question about the ZSK lifetime in OPENDNSSEC.</div>
<div>> </div>
<div>> A key in 'retire' status seems to still being used to sign new RR.</div>
<div>> </div>
<div>> But the 'active' key was not used to generate signature of RR.</div>
<div>> </div>
<div>> It seems a little strange to understand the lifetime of ZSK.</div>
<div>> </div>
<div>> Does it mean the OPENDNSSEC was working abnormally?</div>
<div> </div>
<div>It is a correct operation that key in retire status is still used for</div>
<div>signing. It is not dead yet. Retire means that it is "on its way out",</div>
<div>hence still used, but being phased out and cannot be relied upon as a</div>
<div>sole chain of trust.</div>
<div>An key in publish state is the reverse equivalent of a retire key. It</div>
<div>is being introduced.</div>
<div> </div>
<div> </div>
<div>> My operations can be seen as below:</div>
<div>> </div>
<div>> Firstly I list the keys in HSM for my test zone 'testzone17' </div>
<div>> </div>
<div>> [gtld@index1 OpenDNSSEC-1.4.7]$ ./bin/ods-ksmutil key list -v|grep testzone17</div>
<div>> </div>
<div>> MySQL database host set to: 202.173.9.4</div>
<div>> MySQL database port set to: 3306</div>
<div>> MySQL database schema set to: KASP</div>
<div>> MySQL database user set to: kaspuser</div>
<div>> MySQL database password set</div>
<div>> testzone17 KSK active 2016-11-27 14:52:29 (retire) 2048 8 6cb0c7e105a7c16c6288f9aa07fdbfba SoftHSM 28169</div>
<div>> testzone17 ZSK retire 2015-12-15 18:57:41 (dead) 1024 8 65a3928d9595fd3112b6b021c990c040 SoftHSM 25146</div>
<div>> testzone17 ZSK active 2016-02-29 18:42:41 (retire) 1024 8 92be2b8c731a8c55ece4b49a2a02a7ed SoftHSM 61185</div>
<div>> </div>
<div>> </div>
<div>> We can see testzone17 has a retire ZSK with keytag 25146 and a</div>
<div>> active ZSK with keytag 61185</div>
<div>> </div>
<div>> Then I add a name testsign.testzone17 by nsupdate to the inbind of</div>
<div>> my OPENDNSSEC.</div>
<div>> </div>
<div>> And after that I dig the outbind for the signature of the newly</div>
<div>> added name.</div>
<div>> </div>
<div>> We can see the name was signed with the ZSK of keytag 25146.</div>
<div>> </div>
<div> </div>
<div>Actually no, the answer from the dig gave no an authorative answer that</div>
<div>testsign.testzone17 was not found. I guess the change was not</div>
<div>propagated though correctly (update in SOA serial needed?). The answer</div>
<div>returned contained a signed SOA with the new active key 61185. But the</div>
<div>chain proving the testsign.testzone17 did not exist is still signed with</div>
<div>the old key. I do find this strange, but the outward bind could still</div>
<div>have this cached.</div>
<div> </div>
<div>It is a easier to get through if you first used file based zones, rather</div>
<div>than IXFRs because the named causes a additional factor to be explained.</div>
<div> I would expect the 25146 key to be used there.</div>
<div> </div>
<div>With kind regards,</div>
<div>Berry van Halderen</div>
<div> </div>
<div> </div>
<div>> [gtld@index1 OpenDNSSEC-1.4.7]$ dig @202.173.9.4 testsign.testzone17 +dnssec</div>
<div>> </div>
<div>> ; <<>> DiG 9.9.4 <<>> @202.173.9.4 testsign.testzone17 +dnssec</div>
<div>> ; (1 server found)</div>
<div>> ;; global options: +cmd</div>
<div>> ;; Got answer:</div>
<div>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61685</div>
<div>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1</div>
<div>> ;; WARNING: recursion requested but not available</div>
<div>> </div>
<div>> ;; OPT PSEUDOSECTION:</div>
<div>> ; EDNS: version: 0, flags: do; udp: 4096</div>
<div>> ;; QUESTION SECTION:</div>
<div>> ;testsign.testzone17. IN A</div>
<div>> </div>
<div>> ;; AUTHORITY SECTION:</div>
<div>> testzone17. 300 IN SOA ns.testzone17. dns.knet.cn. 2015093828 3600 600 2419200 300</div>
<div>> testzone17. 300 IN RRSIG SOA 8 1 300 20151215015340 20151201112051 61185 testzone17. l/UGnPP5ZThtRmqYIAm5i5ym/E55jYZ8h6wE0dR1qZ74VJeUDNoMt0me HJGHkVVtEH4cAzydnmhYisbdALcmyCYCXAONxSebADKHdOac0vNLDjCN Ts8m7JHu/7c+xWxTmLvlMqaZ9uhH+80SUiLTBCNgVaKt66fniPenAh18 YJI=</div>
<div>> u71sa7b4ru372fosbkgmh8p5mbp7h1qu.testzone17. 300 IN NSEC3 1 0 5 08E3A6EDB04A2731 U71U56T3UQ1NDGFKUL2HF6I24VKU32MT NS SOA RRSIG DNSKEY NSEC3PARAM</div>
<div>> u71sa7b4ru372fosbkgmh8p5mbp7h1qu.testzone17. 300 IN RRSIG NSEC3 8 2 300 20151214174432 20151201002831 25146 testzone17. URbT4RFGMZ09mLNsc5QRn9B3yPXv34b/2KvA4SSHlCOQUNnVTElH+XCG ycYSaB0uW49GztkJmDU7us0R4mN/sNxuOr/xaTvs8ZgQ6Eo+2gDv7qUq +LNnfDlFXC4VutrCoRxJgy2gLAikc7IS+/EAunMwuqHOJQ41vjqEz7Ew 6w0=</div>
<div>> nav551fe2asnh5siv11agp6sta2mhf6r.testzone17. 300 IN NSEC3 1 0 5 08E3A6EDB04A2731 NAVCM3RLBCL3SU3F8HQ3KCOM1VG7DGR5 NS</div>
<div>> nav551fe2asnh5siv11agp6sta2mhf6r.testzone17. 300 IN RRSIG NSEC3 8 2 300 20151215114940 20151201002831 25146 testzone17. dWseMgX8GCsDIjlXqbjXD3qJcKr9YAsnb1dBKtSo8lMPA7GX8sRFfFcH IcFNxUERbNogkhhzZfkc3EhU0yKim1EcKHAceYC4UPQhChRTaGmt04Le N/9N8/u12I+MkxHKu4jTTRsGzmoNrUHXTAB0xv8pt0Ci41QV3rz/K5we C1s=</div>
<div>> vcst3kqsluj7hok10l437hba96ejn8i8.testzone17. 300 IN NSEC3 1 0 5 08E3A6EDB04A2731 VCTT5PCLG65B13OPF9O42RP2FL71NIU8 NS</div>
<div>> vcst3kqsluj7hok10l437hba96ejn8i8.testzone17. 300 IN RRSIG NSEC3 8 2 300 20151215064016 20151201002831 25146 testzone17. ZPVglgJZdzeq+Ye0aQ7abw8i4B4DB5kY/bC1KWx7frXNBuuF8mVywSP+ AIJvsB79oR490zaGiY6pbbbfSPcOYUaZ+l/5s/C2axDSYa9MfjjW0Or+ DcDrXluas3cbUjT6Xv8YWZPUOpqRJJZOBPFKH5Dsc5YfQh1e9WCCOGv1 VMM=</div>
<div>> </div>
<div>> ;; Query time: 3290 msec</div>
<div>> ;; SERVER: 202.173.9.4#53(202.173.9.4)</div>
<div>> ;; WHEN: Tue Dec 01 20:39:05 CST 2015</div>
<div>> ;; MSG SIZE rcvd: 1020</div>
<div>> </div>
<div> </div>
<div> </div>
<div> </div>
<div>------------------------------</div>
<div> </div>
<div>Message: 2</div>
<div>Date: Tue, 1 Dec 2015 14:33:07 +0100</div>
<div>From: Yuri Schaeffer <yuri@nlnetlabs.nl></div>
<div>Subject: Re: [Opendnssec-user] About the lifetime for ZSK</div>
<div>To: opendnssec-user@lists.opendnssec.org</div>
<div>Message-ID: <565DA193.2010508@nlnetlabs.nl></div>
<div>Content-Type: text/plain; charset=windows-1252</div>
<div> </div>
<div>-----BEGIN PGP SIGNED MESSAGE-----</div>
<div>Hash: SHA1</div>
<div> </div>
<div>Hi gaolei,</div>
<div> </div>
<div>> A key in 'retire' status seems to still being used to sign new RR. </div>
<div>> But the 'active' key was not used to generate signature of RR. Does</div>
<div>> it mean the OPENDNSSEC was working abnormally?</div>
<div> </div>
<div>That indeed seems abnormal. My guess is that -for whatever reason- the</div>
<div>signer did not pick up the changes signer configuration output by the</div>
<div>enforcer.</div>
<div> </div>
<div>Does "ods-signer update testzone17" help?</div>
<div>Then add a new record and check with which key it was signed.</div>
<div> </div>
<div>//Yuri</div>
<div>-----BEGIN PGP SIGNATURE-----</div>
<div>Version: GnuPG v2</div>
<div> </div>
<div>iEYEARECAAYFAlZdoZIACgkQI3PTR4mhavgQUgCeN6RXgSirL91KaP4Uy/5cETkg</div>
<div>imkAn1P6vRIIeAsiEuB6WWw/jty2igW+</div>
<div>=1rTn</div>
<div>-----END PGP SIGNATURE-----</div>
<div> </div>
<div> </div>
<div>------------------------------</div>
<div> </div>
<div>_______________________________________________</div>
<div>Opendnssec-user mailing list</div>
<div>Opendnssec-user@lists.opendnssec.org</div>
<div>https://lists.opendnssec.org/mailman/listinfo/opendnssec-user</div>
<div> </div>
<div> </div>
<div>End of Opendnssec-user Digest, Vol 78, Issue 2</div>
<div>**********************************************</div>
</div></blockquote>
</body></html>