<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>
<div> Hi sion,</div></div><div><br></div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">    The signconf file of testzone is correct , it refers to 2 ZSK , one retire and one active.</span></div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br></span></div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">    Detailed information is as follows:</span></div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">    </span></div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">    </span><span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;">[gtld@SST03 OpenDNSSEC-1.4.0-patch]$ cat var/opendnssec/signconf/testzone.xml</span></div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><SignerConfiguration><br>        <Zone name="</span>testzone<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">"><br>                <Signatures><br>                        <Resign>PT7200S</Resign><br>                        <Refresh>PT259200S</Refresh><br>                        <Validity><br>                                <Default>PT1209600S</Default><br>                                <Denial>PT1209600S</Denial><br>                        </Validity><br>                        <Jitter>PT43200S</Jitter><br>                        <InceptionOffset>PT3600S</InceptionOffset><br>                </Signatures><br><br>                <Denial><br>                        <NSEC3><br>                                <Hash><br>                                        <Algorithm>1</Algorithm><br>                                        <Iterations>5</Iterations><br>                                        <Salt>852ea552f14ccc6e</Salt><br>                                </Hash><br>                        </NSEC3><br>                </Denial><br><br>                <Keys><br>                        <TTL>PT3600S</TTL><br>                        <Key><br>                                <Flags>257</Flags><br>                                <Algorithm>8</Algorithm><br>                                <Locator>6f5837039e487db96b380faad019bfaa</Locator><br>                                <KSK /><br>                                <Publish /><br>                        </Key><br><br>                        <Key><br>                                <Flags>256</Flags><br>                                <Algorithm>8</Algorithm><br>                                <Locator>62728e03e303ecfa703c19452a0f71aa</Locator><br>                                <Publish /><br>                        </Key><br><br>                        <Key><br>                                <Flags>256</Flags><br>                                <Algorithm>8</Algorithm><br>                                <Locator>eff2c8625016a45b9be4344f3085f615</Locator><br>                                <ZSK /><br>                                <Publish /><br>                        </Key><br><br>                </Keys><br><br>                <SOA><br>                        <TTL>PT3600S</TTL><br>                        <Minimum>PT3600S</Minimum><br>                        <Serial>unixtime</Serial><br>                </SOA><br>        </Zone><br></span><div><span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;"></SignerConfiguration></span><span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;">    </span></div><blockquote style="margin-top: 0px; margin-bottom: 0px; margin-left: 2em;"><div>
<div> </div>
<div>------------------------------</div>
<div> </div>
<div>Message: 3</div>
<div>Date: Fri, 4 Dec 2015 08:50:42 +0000</div>
<div>From: Si?n Lloyd <sion.lloyd@nominet.uk></div>
<div>Subject: Re: [Opendnssec-user] Re: Re: About the lifetime for ZSK</div>
<div>To: <opendnssec-user@lists.opendnssec.org></div>
<div>Message-ID: <566153E2.9020607@nominet.uk></div>
<div>Content-Type: text/plain; charset="windows-1252"</div>
<div> </div>
<div>Following on from Yuri's question, can you see the signconf created by</div>
<div>the enforcer? which keys does it have? Is the signer reading the correct</div>
<div>file? (The signer and enforcer should run from the same config file - so</div>
<div>I don't see how this could happen unless you override the defaults</div>
<div>somewhere.)</div>
<div> </div>
<div>Cheers,</div>
<div> </div>
<div>Sion</div>
<div> </div>
<div>On 03/12/15 11:47, gaolei wrote:</div>
<div>> Hi,all</div>
<div>> </div>
<div>>     Here's new example for zone .testzone about the ZSK functioning</div>
<div>>     abnormally.</div>
<div>> </div>
<div>>     The ZSK with keytag '10611' is retired and the ZSK with keytag</div>
<div>>     '3894' is active.</div>
<div>> </div>
<div>>     But the newly added names are signed by the retired ZSK but not the</div>
<div>>     active one.</div>
<div>> </div>
<div>>     It seems not to comply with the key rollover logic of OPENDNSSEC</div>
<div>>     defined in </div>
<div>>     https://wiki.opendnssec.org/display/DOCS/Key+Rollovers</div>
<div>>     The rollover rules defined in above page are almost the same with</div>
<div>>     RFC 7853,Section 3.2.1.</div>
<div>> </div>
<div>>     And the most strange thing is , the active key could not be seen in</div>
<div>>     the zone , only the old ZSK can be returned when digging the dnskey</div>
<div>>     list.</div>
<div>> </div>
<div>>     We tried ods-signer 'update testzone' and 'update all' but it did</div>
<div>>     not work.</div>
<div>> </div>
<div>>     Can anyone give some comments on this case?</div>
<div>> </div>
<div>> </div>
<div>> [gtld@SST03 ~]$./bin/ods-ksmutil key list -v|grep testzone</div>
<div>> MySQL database host set to: 100.73.8.241</div>
<div>> MySQL database port set to: 3306</div>
<div>> MySQL database schema set to: KASP</div>
<div>> MySQL database user set to: kaspreadonly</div>
<div>> MySQL database password set</div>
<div>> testzone                            </div>
<div>> KSK           ready     waiting for ds-seen (active)   2048    8           6f5837039e487db96b380faad019bfaa  SoftHSM                           21986</div>
<div>> testzone                           </div>
<div>>  ZSK           active    2016-02-27 21:04:01 (retire)   1024    8           eff2c8625016a45b9be4344f3085f615  SoftHSM                           3894</div>
<div>> testzone                           </div>
<div>>  ZSK           retire    2015-12-14 10:04:01 (dead)     1024    8           62728e03e303ecfa703c19452a0f71aa  SoftHSM                           10611</div>
<div>>  </div>
<div>> [gtld@SST03 ~]$ dig @202.173.9.4 -p1053 leqidg.testzone +dnssec</div>
<div>> </div>
<div>> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @202.173.9.4 -p1053 leqidg.testzone  +dnssec</div>
<div>> ; (1 server found)</div>
<div>> ;; global options: +cmd</div>
<div>> ;; Got answer:</div>
<div>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43122</div>
<div>> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, 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>> ;leqidg.testzone.                    IN      A</div>
<div>> </div>
<div>> ;; AUTHORITY SECTION:</div>
<div>> leqidg.testzone.             3600    IN      NS      ns4.example.net.</div>
<div>> leqidg.testzone.             3600    IN      NS      ns3.example.net.</div>
<div>> biggqj6qp6lrnvhk4iguqmi16pn454sj.testzone. 3600 IN NSEC3 1 0 5 852EA552F14CCC6E BIGH0C86JF1IFJ0L0SC9L6PQA0ITINIJ NS</div>
<div>> biggqj6qp6lrnvhk4iguqmi16pn454sj.testzone. 3600 IN RRSIG NSEC3 8 2 3600 20151217041247 20151203093030 10611 testzone. ikl6kAY4p6d4qWgo1t5rWOxmetLASSBrUxJTUB+J+Wso00aKJNKPP33Y JhrfKn/Nw14Y3dvZ6ff1dEypf+/EMUbzYh3hDp1EhMspnBRz2tlEMjxE ZAjNGTLrtJdVvXNn7y8Ib1jEn5kKLpSl6zWwM7IEToQC1SBpYh2eG8fL 8qk=</div>
<div>> </div>
<div>> ;; Query time: 5 msec</div>
<div>> ;; SERVER: 202.173.9.4#1053(202.173.9.4)</div>
<div>> ;; WHEN: Thu Dec  3 19:21:30 2015</div>
<div>> ;; MSG SIZE  rcvd: 335</div>
<div>>  </div>
<div>>  [gtld@SST03 ~]$ dig @202.173.9.4 -p1053 testzone dnskey +dnssec</div>
<div>> </div>
<div>> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @202.173.9.4 -p1053 testzone dnskey +dnssec</div>
<div>> ; (1 server found)</div>
<div>> ;; global options: +cmd</div>
<div>> ;; Got answer:</div>
<div>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19023</div>
<div>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, 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>> ;testzone.                           IN      DNSKEY</div>
<div>> </div>
<div>> ;; ANSWER SECTION:</div>
<div>> testzone.                    3600    IN      DNSKEY  257 3 8 AwEAAaxnzYRHBsjsbCr5kCLBE5UVGu35Y10TDwmQUr/zccEOFwVIrIVK +/uE2XAZVCNtrzk3em3f0cbpHCZgBTUj6o3kRzawwJPGRWo++EijYlsb I3hD+JIUyPrS6ujRI77tjkNZ7oT+zcxQJcGBx0qXhRbTfAgX0WdaRNAE xf4yivvk73wbHtLHe+8uo5GJ1knnPB/1uxWSVCIRUocESZiAR/MKzMtg ER1sUwjZSDOOjO8SkwuMdaX0fU5sOV0cusXD5whT22AplwSUnXONiDM+ aCHs43SdkbIrX4cxoKjlXou+xQd443yAsFE9BRIZBvFxPxFY89uGXpUp REkyMN0LvXU=</div>
<div>> testzone.                    3600    IN      DNSKEY  256 3 8 AwEAAafl9Q7tTD1w+w51dLa38lQNLfAUbVnn0TrHTtoPJGbjlH2dJ+rH x9wjBVUnMo4S49gl+F+WQmHzwmEs3DrQuofwereQkc5CBOlTx/Qoo8r5 jXaZMzagabDIzHObiVz6W+uIc/9wO92lACyvcWDNSmrDusJxPMJ6b1/D o7WJcCVx</div>
<div>> testzone.                    3600    IN      RRSIG   DNSKEY 8 1 3600 20151214201633 20151201032253 21986 testzone. CA9810UOs3vsvltgTjjYkjUIUE8uJ9kUDhK21s2EHXfUaB1nlql5jooS dDvnz7aAzLwXGcGS3/IXX/aZvch0rzSTm5G970/Of9kjnG3/Cvkqbgts v47gE+6l7ylHucWQmvY5QtXrvVbrYHpO3HTSCTklXeSZDM2vJzuA7aLa LV/XwTVuJCZIRU7vFA8IVh5PUeD/yQKp2bGI7YtEdLZwsMmV5XQI3uKI WM/x31SOoFaTTALbeGQmfGhzWZKAnd68u/TbIAWAG/Dk4OzeXgdSVcl4 mpL4iEJd25TLZs0Rktl2TzdGWH6U/Sz+ZWbGcuZKCttkBGSpMdk6qf/D oSNyiQ==</div>
<div>> </div>
<div>> ;; Query time: 0 msec</div>
<div>> ;; SERVER: 202.173.9.4#1053(202.173.9.4)</div>
<div>> ;; WHEN: Thu Dec  3 19:33:06 2015</div>
<div>> ;; MSG SIZE  rcvd: 747</div>
<div>>  </div>
<div>> ------------------------------------------------------------------------</div>
<div>> 2015-12-03 19:24:27</div>
<div>> gaolei</div>
<div>> </div>
<div>>      </div>
<div>>     *From:* opendnssec-user-request</div>
<div>>     <mailto:opendnssec-user-request@lists.opendnssec.org></div>
<div>>     *Date:* 2015-12-02 20:00</div>
<div>>     *To:* opendnssec-user <mailto:opendnssec-user@lists.opendnssec.org></div>
<div>>     *Subject:* Opendnssec-user Digest, Vol 78, Issue 2</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</div>
<div>>     -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   </div>
<div>>     2016-11-27 14:52:29 (retire)   2048    8          </div>
<div>>     6cb0c7e105a7c16c6288f9aa07fdbfba  SoftHSM                          </div>
<div>>     28169</div>
<div>>     >     testzone17                        ZSK           retire   </div>
<div>>     2015-12-15 18:57:41 (dead)     1024    8          </div>
<div>>     65a3928d9595fd3112b6b021c990c040  SoftHSM                          </div>
<div>>     25146</div>
<div>>     >     testzone17                        ZSK           active   </div>
<div>>     2016-02-29 18:42:41 (retire)   1024    8          </div>
<div>>     92be2b8c731a8c55ece4b49a2a02a7ed  SoftHSM                          </div>
<div>>     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</div>
<div>>     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.</div>
<div>>     dns.knet.cn. 2015093828 3600 600 2419200 300</div>
<div>>     > testzone17.             300       IN      RRSIG   SOA 8 1 300</div>
<div>>     20151215015340 20151201112051 61185 testzone17.</div>
<div>>     l/UGnPP5ZThtRmqYIAm5i5ym/E55jYZ8h6wE0dR1qZ74VJeUDNoMt0me</div>
<div>>     HJGHkVVtEH4cAzydnmhYisbdALcmyCYCXAONxSebADKHdOac0vNLDjCN</div>
<div>>     Ts8m7JHu/7c+xWxTmLvlMqaZ9uhH+80SUiLTBCNgVaKt66fniPenAh18 YJI=</div>
<div>>     > u71sa7b4ru372fosbkgmh8p5mbp7h1qu.testzone17. 300 IN NSEC3 1 0 5</div>
<div>>     08E3A6EDB04A2731 U71U56T3UQ1NDGFKUL2HF6I24VKU32MT NS SOA RRSIG</div>
<div>>     DNSKEY NSEC3PARAM</div>
<div>>     > u71sa7b4ru372fosbkgmh8p5mbp7h1qu.testzone17. 300 IN RRSIG NSEC3 8</div>
<div>>     2 300 20151214174432 20151201002831 25146 testzone17.</div>
<div>>     URbT4RFGMZ09mLNsc5QRn9B3yPXv34b/2KvA4SSHlCOQUNnVTElH+XCG</div>
<div>>     ycYSaB0uW49GztkJmDU7us0R4mN/sNxuOr/xaTvs8ZgQ6Eo+2gDv7qUq</div>
<div>>     +LNnfDlFXC4VutrCoRxJgy2gLAikc7IS+/EAunMwuqHOJQ41vjqEz7Ew 6w0=</div>
<div>>     > nav551fe2asnh5siv11agp6sta2mhf6r.testzone17. 300 IN NSEC3 1 0 5</div>
<div>>     08E3A6EDB04A2731 NAVCM3RLBCL3SU3F8HQ3KCOM1VG7DGR5 NS</div>
<div>>     > nav551fe2asnh5siv11agp6sta2mhf6r.testzone17. 300 IN RRSIG NSEC3 8</div>
<div>>     2 300 20151215114940 20151201002831 25146 testzone17.</div>
<div>>     dWseMgX8GCsDIjlXqbjXD3qJcKr9YAsnb1dBKtSo8lMPA7GX8sRFfFcH</div>
<div>>     IcFNxUERbNogkhhzZfkc3EhU0yKim1EcKHAceYC4UPQhChRTaGmt04Le</div>
<div>>     N/9N8/u12I+MkxHKu4jTTRsGzmoNrUHXTAB0xv8pt0Ci41QV3rz/K5we C1s=</div>
<div>>     > vcst3kqsluj7hok10l437hba96ejn8i8.testzone17. 300 IN NSEC3 1 0 5</div>
<div>>     08E3A6EDB04A2731 VCTT5PCLG65B13OPF9O42RP2FL71NIU8 NS</div>
<div>>     > vcst3kqsluj7hok10l437hba96ejn8i8.testzone17. 300 IN RRSIG NSEC3 8</div>
<div>>     2 300 20151215064016 20151201002831 25146 testzone17.</div>
<div>>     ZPVglgJZdzeq+Ye0aQ7abw8i4B4DB5kY/bC1KWx7frXNBuuF8mVywSP+</div>
<div>>     AIJvsB79oR490zaGiY6pbbbfSPcOYUaZ+l/5s/C2axDSYa9MfjjW0Or+</div>
<div>>     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>> 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>>      </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>> </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> </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 4</div>
<div>**********************************************</div>
</div></blockquote>
</body></html>