<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"><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><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">Hi,all<br><br> Here is a question about the ZSK lifetime in OPENDNSSEC.<br><br> A key in 'retire' status seems to still being used to sign new RR.<br><br> But the 'active' key was not used to generate signature of RR.</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);"> </span><span style="font-size: 10.5pt; line-height: 1.5; background-color: window;">It seems a little strange to understand the lifetime of ZSK.</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);"> Does it mean the OPENDNSSEC was working abnormally?</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);"> My operations can be seen as below:</span></div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br> Firstly I list the keys in HSM for my test zone 'testzone17' <br><br> [gtld@index1 OpenDNSSEC-1.4.7]$ ./bin/ods-ksmutil key list -v|grep testzone17<br></span></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">MySQL database host set to: 202.173.9.4</span></div></div><div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">MySQL database port set to: 3306</span></div></div><div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">MySQL database schema set to: KASP</span></div></div><div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">MySQL database user set to: kaspuser</span></div></div><div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">MySQL database password set</span></div></div><div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">testzone17 KSK active 2016-11-27 14:52:29 (retire) 2048 8 6cb0c7e105a7c16c6288f9aa07fdbfba SoftHSM 28169</span></div></div><div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">testzone17 ZSK retire 2015-12-15 18:57:41 (dead) 1024 8 65a3928d9595fd3112b6b021c990c040 SoftHSM 25146</span></div></div><div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">testzone17 ZSK active 2016-02-29 18:42:41 (retire) 1024 8 92be2b8c731a8c55ece4b49a2a02a7ed SoftHSM 61185</span></div></div></blockquote><div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br></span><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> We can see testzone17 has a retire ZSK with keytag </span>25146 and a active ZSK with keytag 61185<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br></span><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;"> </span><span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;">Then I add a name testsign.testzone17 by nsupdate to the inbind of my OPENDNSSEC.</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);"> And after that I dig the outbind for the signature of the newly added name.</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);"> We can see the name was signed with the ZSK of keytag </span>25146.<span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br><br> </span><span style="font-size: 10.5pt; line-height: 1.5; background-color: window;">[gtld@index1 OpenDNSSEC-1.4.7]$</span><span style="background-color: rgba(0, 0, 0, 0); font-size: 10.5pt; line-height: 1.5;"> dig @202.173.9.4 testsign.testzone17 +dnssec</span></div><div><span style="color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br>; <<>> DiG 9.9.4 <<>> @202.173.9.4 testsign.testzone17 +dnssec<br>; (1 server found)<br>;; global options: +cmd<br>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61685<br>;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, 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>;testsign.testzone17. IN A<br><br>;; AUTHORITY SECTION:<br>testzone17. 300 IN SOA ns.testzone17. dns.knet.cn. 2015093828 3600 600 2419200 300<br>testzone17. 300 IN RRSIG SOA 8 1 300 20151215015340 20151201112051 61185 testzone17. l/UGnPP5ZThtRmqYIAm5i5ym/E55jYZ8h6wE0dR1qZ74VJeUDNoMt0me HJGHkVVtEH4cAzydnmhYisbdALcmyCYCXAONxSebADKHdOac0vNLDjCN Ts8m7JHu/7c+xWxTmLvlMqaZ9uhH+80SUiLTBCNgVaKt66fniPenAh18 YJI=<br>u71sa7b4ru372fosbkgmh8p5mbp7h1qu.testzone17. 300 IN NSEC3 1 0 5 08E3A6EDB04A2731 U71U56T3UQ1NDGFKUL2HF6I24VKU32MT NS SOA RRSIG DNSKEY NSEC3PARAM<br>u71sa7b4ru372fosbkgmh8p5mbp7h1qu.testzone17. 300 IN RRSIG NSEC3 8 2 300 20151214174432 20151201002831 25146 testzone17. URbT4RFGMZ09mLNsc5QRn9B3yPXv34b/2KvA4SSHlCOQUNnVTElH+XCG ycYSaB0uW49GztkJmDU7us0R4mN/sNxuOr/xaTvs8ZgQ6Eo+2gDv7qUq +LNnfDlFXC4VutrCoRxJgy2gLAikc7IS+/EAunMwuqHOJQ41vjqEz7Ew 6w0=<br>nav551fe2asnh5siv11agp6sta2mhf6r.testzone17. 300 IN NSEC3 1 0 5 08E3A6EDB04A2731 NAVCM3RLBCL3SU3F8HQ3KCOM1VG7DGR5 NS<br>nav551fe2asnh5siv11agp6sta2mhf6r.testzone17. 300 IN RRSIG NSEC3 8 2 300 20151215114940 20151201002831 25146 testzone17. dWseMgX8GCsDIjlXqbjXD3qJcKr9YAsnb1dBKtSo8lMPA7GX8sRFfFcH IcFNxUERbNogkhhzZfkc3EhU0yKim1EcKHAceYC4UPQhChRTaGmt04Le N/9N8/u12I+MkxHKu4jTTRsGzmoNrUHXTAB0xv8pt0Ci41QV3rz/K5we C1s=<br>vcst3kqsluj7hok10l437hba96ejn8i8.testzone17. 300 IN NSEC3 1 0 5 08E3A6EDB04A2731 VCTT5PCLG65B13OPF9O42RP2FL71NIU8 NS<br>vcst3kqsluj7hok10l437hba96ejn8i8.testzone17. 300 IN RRSIG NSEC3 8 2 300 20151215064016 20151201002831 25146 testzone17. ZPVglgJZdzeq+Ye0aQ7abw8i4B4DB5kY/bC1KWx7frXNBuuF8mVywSP+ AIJvsB79oR490zaGiY6pbbbfSPcOYUaZ+l/5s/C2axDSYa9MfjjW0Or+ DcDrXluas3cbUjT6Xv8YWZPUOpqRJJZOBPFKH5Dsc5YfQh1e9WCCOGv1 VMM=<br><br>;; Query time: 3290 msec<br>;; SERVER: 202.173.9.4#53(202.173.9.4)<br>;; WHEN: Tue Dec 01 20:39:05 CST 2015<br>;; MSG SIZE rcvd: 1020<br><br><br><br> <br><br> <br> <br> <br>2015-12-01 20:41:20<br>gaolei<br> <br>From: opendnssec-user-request<br>Date: 2015-11-27 20:00<br>To: opendnssec-user<br>Subject: Opendnssec-user Digest, Vol 77, Issue 9<br>Send Opendnssec-user mailing list submissions to<br>opendnssec-user@lists.opendnssec.org<br> <br>To subscribe or unsubscribe via the World Wide Web, visit<br>https://lists.opendnssec.org/mailman/listinfo/opendnssec-user<br>or, via email, send a message with subject or body 'help' to<br>opendnssec-user-request@lists.opendnssec.org<br> <br>You can reach the person managing the list at<br>opendnssec-user-owner@lists.opendnssec.org<br> <br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Opendnssec-user digest..."<br> <br> <br>Today's Topics:<br> <br> 1. Maintenance on wiki.opendnssec.org and<span style="white-space: pre;"> </span>issues.opendnssec.org<br> (Roland van Rijswijk - Deij)<br> 2. Re: Questions about 'merging' two sqlite kaspdb<span style="white-space: pre;"> </span>files into<br> one mysql database (Si?n Lloyd)<br> <br> <br>----------------------------------------------------------------------<br> <br>Message: 1<br>Date: Thu, 26 Nov 2015 13:44:45 +0100<br>From: Roland van Rijswijk - Deij <Roland.vanRijswijk@surfnet.nl><br>Subject: [Opendnssec-user] Maintenance on wiki.opendnssec.org and<br>issues.opendnssec.org<br>To: "opendnssec-user@lists.opendnssec.org"<br><opendnssec-user@lists.opendnssec.org><br>Message-ID: <5656FEBD.9050008@surfnet.nl><br>Content-Type: text/plain; charset="iso-8859-1"<br> <br>Dear OpenDNSSEC users,<br> <br>We will be performing extensive maintenance on issues.opendnssec.org and<br>wiki.opendnssec.org. The maintenance will take place between Tuesday<br>December 1st, 9:00h CET and Wednesday December 2nd, 17:00h CET.<br> <br>During the maintenance window both systems may be unavailable at any<br>time. Should you find the system unavailable, we kindly ask that you<br>retry your request at a later time.<br> <br>We apologise for any inconvenience caused.<br> <br>On behalf of the OpenDNSSEC team, best regards,<br> <br>Roland<br> <br>--<br>-- Roland M. van Rijswijk - Deij<br>-- SURFnet bv<br>-- w: http://www.surf.nl/en/about-surf/subsidiaries/surfnet<br>-- e: roland.vanrijswijk@surfnet.nl<br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: smime.p7s<br>Type: application/x-pkcs7-signature<br>Size: 4412 bytes<br>Desc: S/MIME Cryptographic Signature<br>Url : http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20151126/07739cd9/smime-0001.bin<br> <br>------------------------------<br> <br>Message: 2<br>Date: Thu, 26 Nov 2015 13:16:20 +0000<br>From: Si?n Lloyd <sion.lloyd@nominet.uk><br>Subject: Re: [Opendnssec-user] Questions about 'merging' two sqlite<br>kaspdb<span style="white-space: pre;"> </span>files into one mysql database<br>To: <opendnssec-user@lists.opendnssec.org><br>Message-ID: <56570624.7040200@nominet.uk><br>Content-Type: text/plain; charset="windows-1252"<br> <br>On 26/11/15 08:30, Anne van Bemmelen wrote:<br>> Dear listmembers,<br>><br>> I am investigating the following scenario, in which I try to ‘merge’ two<br>> kaspdb files.<br>><br>> <br>><br>> Current situation:<br>><br>> In the current situation there are two signing systems: signera and signerb.<br>><br>> RedHat5, ODS 1.3.x, SQLite backend.<br>><br>> signera signs zone1 and zone2.<br>><br>> signerb signs zone3 and zone4.<br>><br>> Both signers use the policy ‘default’, but they differ in some details.<br>><br>> <br>><br>> New situation:<br>><br>> One signer system: signerc.<br>><br>> Ubuntu 14.04, ODS 1.4.7, MySQL backend.<br>><br>> Signerc needs to sign all zones: zone[1234].<br>><br>> Two defined policies: ‘default’ and ‘mypolicy’.<br>><br>> On a new HSM all involved keys are restored, with known CKA_id’s.<br>><br>> <br>><br>> The usual migrate scripts (ODS 1.3 to 1.4, sqlite to mysql) won’t work<br>> in this case, because two kaspdb’s are involved.<br>><br>> <br>><br>> I did the following:<br>><br>> Configure conf.xml, kasp.xml and zonelist.xml in the appropriate way,<br>> with one repository, two policies, four zones, each with the desired policy.<br>><br>> Ods-ksmutil setup.<br>><br>> For each zone import all keys with: ods-ksmutil key import [all options]<br>><br>> Most options are obvious from ods-ksmutil key list –v –zone <zoneN>.<br>><br>> I checked the values for –time and –retire in the existing sqlite tables<br>> keypairs (field ‘generate’) and ‘dnsseckeys’ (field ‘retire’).<br>><br>> <br>><br>> This results in:<br>><br>> ods-ksmutil key list –v shows the same output on old and new signer.<br>><br>> After ‘ods-control start’ all zones are signed as expected, everything<br>> seems to work (besides key rollovers that I didn’t test yet).<br>><br>> <br>><br>> *These are the differences between the contents of sqlite and mysql<br>> databases:<br>><br>> In the mysql database I find the following :<br>><br>> table policies: initially the field salt has value NULL, after ODS has<br>> started, it gets a new value.<br>><br>> table policies: the field salt_stamp contains date/time of import<br>> (sqlite contains the real salt generation time, equal to dnskeys active<br>> time).<br>><br>> <br>><br>> table keypairs: I expected the field ‘generate’ to contain the –time<br>> value, specified during the key import, but this value is NULL.<br>><br>> Instead this date is filled in the table dnsseckeys, field ‘active’. Is<br>> this normal behaviour?<br>><br>> <br>><br>> table dnsseckeys: the fields ‘publish’ and ‘ready’ have the NULL value<br>> (in sqlite the real timestamp).<br>><br>> table keypairs: the field ‘fixedDate’ has value 1 (in sqlite value 0).<br>> Freshly created keys appear to have have fixedDate value 0.<br>><br>> <br> <br>Interesting problem, it is not one I'd thought about before.<br> <br>note that import keys was intended as a way of moving keys into ODS from<br>some other signing solution. It imports only what is required to get the<br>key into the correct state and not the history of that key or any other<br>parameters that were in use against the zone.<br> <br>><br>> In my opinion the following additional actions are necessary:<br>><br>> - Manually update salt with the value in sqlite<br>><br>> - Manually update salt_stamp with the value in sqlite<br>><br>> - salt_stamp and active date have to be the same, during import<br>> use the active date with the –time option<br> <br>Salt will not be imported with keys - it is the salt for the NSEC3<br>chain. Like you say, if you want the salt to remain (and not be changed<br>until it would have been under the old system) then you will need to<br>import these parameters. Is there a specific reason that you do not want<br>the salt to change?<br> <br>><br>> <br>><br>> I think there’s no need to fill in the dnssec fields ‘generate’,<br>> ‘publish’ and ‘ready’.<br> <br>No, these are part of the keys history and the assumption was that this<br>data would not be available for keys being imported.<br> <br> <br>><br>> Is my interpretation correct? Is there anything else I have overlooked?<br>><br>> Also, I don’t understand the meaning of the fixedDate field, should I<br>> change it back to 0?<br>><br> <br>This flag means that even if you change the policy to allow keys to be<br>used for longer, the retire time of _this_ key will not change to<br>reflect that. This flag is set when you import a key with a retire time<br>as you are telling the system when you want this key to retire.<br> <br> <br>Sion<br> <br>> <br>><br>> All comments and suggestions are welcome.<br>><br>> Thanks in advance,<br>><br>> <br>><br>> Anne van Bemmelen<br>><br>> SIDN | Meander 501| 6825 MD | Postbus 5022 | 6802 AE | ARNHEM T +31<br>> (0)26 352 55 00 | M +31 (0)6 15 06 33 96 | F +31 (0)26 352 55 05<br>> anne.vanbemmelen@sidn.nl| <mailto:anne.vanbemmelen@sidn.nl|><br>> www.sidn.nl| <http://www.sidn.nl|> Key-ID: 0xB8A5F0B2<br>><br>> <br>><br>> <br>><br>> <br>><br>> <br>><br>> <br>><br>> <br>><br>> <br>><br>> <br>><br>> <br>><br>><br>><br>> _______________________________________________<br>> Opendnssec-user mailing list<br>> Opendnssec-user@lists.opendnssec.org<br>> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user<br>><br> <br> <br> <br>------------------------------<br> <br>_______________________________________________<br>Opendnssec-user mailing list<br>Opendnssec-user@lists.opendnssec.org<br>https://lists.opendnssec.org/mailman/listinfo/opendnssec-user<br> <br> <br>End of Opendnssec-user Digest, Vol 77, Issue 9<br>**********************************************</span></div></div><blockquote style="margin-top: 0px; margin-bottom: 0px; margin-left: 2em;"><div>
</div></blockquote>
</body></html>