[Opendnssec-user] Re: Re: About the lifetime for ZSK

Siôn Lloyd sion.lloyd at nominet.uk
Fri Dec 4 08:50:42 UTC 2015


Following on from Yuri's question, can you see the signconf created by
the enforcer? which keys does it have? Is the signer reading the correct
file? (The signer and enforcer should run from the same config file - so
I don't see how this could happen unless you override the defaults
somewhere.)

Cheers,

Sion

On 03/12/15 11:47, gaolei wrote:
> Hi,all
> 
>     Here's new example for zone .testzone about the ZSK functioning
>     abnormally.
> 
>     The ZSK with keytag '10611' is retired and the ZSK with keytag
>     '3894' is active.
> 
>     But the newly added names are signed by the retired ZSK but not the
>     active one.
> 
>     It seems not to comply with the key rollover logic of OPENDNSSEC
>     defined in 
>     https://wiki.opendnssec.org/display/DOCS/Key+Rollovers
>     The rollover rules defined in above page are almost the same with
>     RFC 7853,Section 3.2.1.
> 
>     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.
> 
>     We tried ods-signer 'update testzone' and 'update all' but it did
>     not work.
> 
>     Can anyone give some comments on this case?
> 
> 
> [gtld at SST03 ~]$./bin/ods-ksmutil key list -v|grep testzone
> MySQL database host set to: 100.73.8.241
> MySQL database port set to: 3306
> MySQL database schema set to: KASP
> MySQL database user set to: kaspreadonly
> MySQL database password set
> testzone                            
> KSK           ready     waiting for ds-seen (active)   2048    8           6f5837039e487db96b380faad019bfaa  SoftHSM                           21986
> testzone                           
>  ZSK           active    2016-02-27 21:04:01 (retire)   1024    8           eff2c8625016a45b9be4344f3085f615  SoftHSM                           3894
> testzone                           
>  ZSK           retire    2015-12-14 10:04:01 (dead)     1024    8           62728e03e303ecfa703c19452a0f71aa  SoftHSM                           10611
>  
> [gtld at SST03 ~]$ dig @202.173.9.4 -p1053 leqidg.testzone +dnssec
> 
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @202.173.9.4 -p1053 leqidg.testzone  +dnssec
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43122
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;leqidg.testzone.                    IN      A
> 
> ;; AUTHORITY SECTION:
> leqidg.testzone.             3600    IN      NS      ns4.example.net.
> leqidg.testzone.             3600    IN      NS      ns3.example.net.
> biggqj6qp6lrnvhk4iguqmi16pn454sj.testzone. 3600 IN NSEC3 1 0 5 852EA552F14CCC6E BIGH0C86JF1IFJ0L0SC9L6PQA0ITINIJ NS
> biggqj6qp6lrnvhk4iguqmi16pn454sj.testzone. 3600 IN RRSIG NSEC3 8 2 3600 20151217041247 20151203093030 10611 testzone. ikl6kAY4p6d4qWgo1t5rWOxmetLASSBrUxJTUB+J+Wso00aKJNKPP33Y JhrfKn/Nw14Y3dvZ6ff1dEypf+/EMUbzYh3hDp1EhMspnBRz2tlEMjxE ZAjNGTLrtJdVvXNn7y8Ib1jEn5kKLpSl6zWwM7IEToQC1SBpYh2eG8fL 8qk=
> 
> ;; Query time: 5 msec
> ;; SERVER: 202.173.9.4#1053(202.173.9.4)
> ;; WHEN: Thu Dec  3 19:21:30 2015
> ;; MSG SIZE  rcvd: 335
>  
>  [gtld at SST03 ~]$ dig @202.173.9.4 -p1053 testzone dnskey +dnssec
> 
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @202.173.9.4 -p1053 testzone dnskey +dnssec
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19023
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;testzone.                           IN      DNSKEY
> 
> ;; ANSWER SECTION:
> testzone.                    3600    IN      DNSKEY  257 3 8 AwEAAaxnzYRHBsjsbCr5kCLBE5UVGu35Y10TDwmQUr/zccEOFwVIrIVK +/uE2XAZVCNtrzk3em3f0cbpHCZgBTUj6o3kRzawwJPGRWo++EijYlsb I3hD+JIUyPrS6ujRI77tjkNZ7oT+zcxQJcGBx0qXhRbTfAgX0WdaRNAE xf4yivvk73wbHtLHe+8uo5GJ1knnPB/1uxWSVCIRUocESZiAR/MKzMtg ER1sUwjZSDOOjO8SkwuMdaX0fU5sOV0cusXD5whT22AplwSUnXONiDM+ aCHs43SdkbIrX4cxoKjlXou+xQd443yAsFE9BRIZBvFxPxFY89uGXpUp REkyMN0LvXU=
> testzone.                    3600    IN      DNSKEY  256 3 8 AwEAAafl9Q7tTD1w+w51dLa38lQNLfAUbVnn0TrHTtoPJGbjlH2dJ+rH x9wjBVUnMo4S49gl+F+WQmHzwmEs3DrQuofwereQkc5CBOlTx/Qoo8r5 jXaZMzagabDIzHObiVz6W+uIc/9wO92lACyvcWDNSmrDusJxPMJ6b1/D o7WJcCVx
> 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==
> 
> ;; Query time: 0 msec
> ;; SERVER: 202.173.9.4#1053(202.173.9.4)
> ;; WHEN: Thu Dec  3 19:33:06 2015
> ;; MSG SIZE  rcvd: 747
>  
> ------------------------------------------------------------------------
> 2015-12-03 19:24:27
> gaolei
> 
>      
>     *From:* opendnssec-user-request
>     <mailto:opendnssec-user-request at lists.opendnssec.org>
>     *Date:* 2015-12-02 20:00
>     *To:* opendnssec-user <mailto:opendnssec-user at lists.opendnssec.org>
>     *Subject:* Opendnssec-user Digest, Vol 78, Issue 2
>     Send Opendnssec-user mailing list submissions to
>     opendnssec-user at lists.opendnssec.org
>      
>     To subscribe or unsubscribe via the World Wide Web, visit
>     https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
>     or, via email, send a message with subject or body 'help' to
>     opendnssec-user-request at lists.opendnssec.org
>      
>     You can reach the person managing the list at
>     opendnssec-user-owner at lists.opendnssec.org
>      
>     When replying, please edit your Subject line so it is more specific
>     than "Re: Contents of Opendnssec-user digest..."
>      
>      
>     Today's Topics:
>      
>        1. Re: About the lifetime for ZSK (Berry A.W. van Halderen)
>        2. Re: About the lifetime for ZSK (Yuri Schaeffer)
>      
>      
>     ----------------------------------------------------------------------
>      
>     Message: 1
>     Date: Tue, 1 Dec 2015 14:31:15 +0100
>     From: "Berry A.W. van Halderen" <berry at nlnetlabs.nl>
>     Subject: Re: [Opendnssec-user] About the lifetime for ZSK
>     To: opendnssec-user at lists.opendnssec.org
>     Message-ID: <565DA123.1060700 at nlnetlabs.nl>
>     Content-Type: text/plain; charset=windows-1252
>      
>     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
>     >
>      
>      
>      
>     ------------------------------
>      
>     Message: 2
>     Date: Tue, 1 Dec 2015 14:33:07 +0100
>     From: Yuri Schaeffer <yuri at nlnetlabs.nl>
>     Subject: Re: [Opendnssec-user] About the lifetime for ZSK
>     To: opendnssec-user at lists.opendnssec.org
>     Message-ID: <565DA193.2010508 at nlnetlabs.nl>
>     Content-Type: text/plain; charset=windows-1252
>      
> Hi gaolei,
>  
>> 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. Does
>> it mean the OPENDNSSEC was working  abnormally?
>  
> That indeed seems abnormal. My guess is that -for whatever reason- the
> signer did not pick up the changes signer configuration output by the
> enforcer.
>  
> Does "ods-signer update testzone17" help?
> Then add a new record and check with which key it was signed.
>  
> //Yuri
>      
>      
>     ------------------------------
>      
>     _______________________________________________
>     Opendnssec-user mailing list
>     Opendnssec-user at lists.opendnssec.org
>     https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
>      
>      
>     End of Opendnssec-user Digest, Vol 78, Issue 2
>     **********************************************
> 
> 
> 
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
> 



More information about the Opendnssec-user mailing list