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?
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.
[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
2015-12-01 20:41:20
gaolei
From: opendnssec-user-request
Date: 2015-11-27 20:00
To: opendnssec-user
Subject: Opendnssec-user Digest, Vol 77, Issue 9
Send Opendnssec-user mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Opendnssec-user digest..."
Today's Topics:
1. Maintenance on wiki.opendnssec.org and issues.opendnssec.org
(Roland van Rijswijk - Deij)
2. Re: Questions about 'merging' two sqlite kaspdb files into
one mysql database (Si?n Lloyd)
----------------------------------------------------------------------
Message: 1
Date: Thu, 26 Nov 2015 13:44:45 +0100
From: Roland van Rijswijk - Deij <[email protected]>
Subject: [Opendnssec-user] Maintenance on wiki.opendnssec.org and
issues.opendnssec.org
To: "[email protected]"
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Dear OpenDNSSEC users,
We will be performing extensive maintenance on issues.opendnssec.org and
wiki.opendnssec.org. The maintenance will take place between Tuesday
December 1st, 9:00h CET and Wednesday December 2nd, 17:00h CET.
During the maintenance window both systems may be unavailable at any
time. Should you find the system unavailable, we kindly ask that you
retry your request at a later time.
We apologise for any inconvenience caused.
On behalf of the OpenDNSSEC team, best regards,
Roland
--
-- Roland M. van Rijswijk - Deij
-- SURFnet bv
-- w: http://www.surf.nl/en/about-surf/subsidiaries/surfnet
-- e: [email protected]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4412 bytes
Desc: S/MIME Cryptographic Signature
Url :
http://lists.opendnssec.org/pipermail/opendnssec-user/attachments/20151126/07739cd9/smime-0001.bin
------------------------------
Message: 2
Date: Thu, 26 Nov 2015 13:16:20 +0000
From: Si?n Lloyd <[email protected]>
Subject: Re: [Opendnssec-user] Questions about 'merging' two sqlite
kaspdb files into one mysql database
To: <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
On 26/11/15 08:30, Anne van Bemmelen wrote:
> Dear listmembers,
>
> I am investigating the following scenario, in which I try to ‘merge’ two
> kaspdb files.
>
>
>
> Current situation:
>
> In the current situation there are two signing systems: signera and signerb.
>
> RedHat5, ODS 1.3.x, SQLite backend.
>
> signera signs zone1 and zone2.
>
> signerb signs zone3 and zone4.
>
> Both signers use the policy ‘default’, but they differ in some details.
>
>
>
> New situation:
>
> One signer system: signerc.
>
> Ubuntu 14.04, ODS 1.4.7, MySQL backend.
>
> Signerc needs to sign all zones: zone[1234].
>
> Two defined policies: ‘default’ and ‘mypolicy’.
>
> On a new HSM all involved keys are restored, with known CKA_id’s.
>
>
>
> The usual migrate scripts (ODS 1.3 to 1.4, sqlite to mysql) won’t work
> in this case, because two kaspdb’s are involved.
>
>
>
> I did the following:
>
> Configure conf.xml, kasp.xml and zonelist.xml in the appropriate way,
> with one repository, two policies, four zones, each with the desired policy.
>
> Ods-ksmutil setup.
>
> For each zone import all keys with: ods-ksmutil key import [all options]
>
> Most options are obvious from ods-ksmutil key list –v –zone <zoneN>.
>
> I checked the values for –time and –retire in the existing sqlite tables
> keypairs (field ‘generate’) and ‘dnsseckeys’ (field ‘retire’).
>
>
>
> This results in:
>
> ods-ksmutil key list –v shows the same output on old and new signer.
>
> After ‘ods-control start’ all zones are signed as expected, everything
> seems to work (besides key rollovers that I didn’t test yet).
>
>
>
> *These are the differences between the contents of sqlite and mysql
> databases:
>
> In the mysql database I find the following :
>
> table policies: initially the field salt has value NULL, after ODS has
> started, it gets a new value.
>
> table policies: the field salt_stamp contains date/time of import
> (sqlite contains the real salt generation time, equal to dnskeys active
> time).
>
>
>
> table keypairs: I expected the field ‘generate’ to contain the –time
> value, specified during the key import, but this value is NULL.
>
> Instead this date is filled in the table dnsseckeys, field ‘active’. Is
> this normal behaviour?
>
>
>
> table dnsseckeys: the fields ‘publish’ and ‘ready’ have the NULL value
> (in sqlite the real timestamp).
>
> table keypairs: the field ‘fixedDate’ has value 1 (in sqlite value 0).
> Freshly created keys appear to have have fixedDate value 0.
>
>
Interesting problem, it is not one I'd thought about before.
note that import keys was intended as a way of moving keys into ODS from
some other signing solution. It imports only what is required to get the
key into the correct state and not the history of that key or any other
parameters that were in use against the zone.
>
> In my opinion the following additional actions are necessary:
>
> - Manually update salt with the value in sqlite
>
> - Manually update salt_stamp with the value in sqlite
>
> - salt_stamp and active date have to be the same, during import
> use the active date with the –time option
Salt will not be imported with keys - it is the salt for the NSEC3
chain. Like you say, if you want the salt to remain (and not be changed
until it would have been under the old system) then you will need to
import these parameters. Is there a specific reason that you do not want
the salt to change?
>
>
>
> I think there’s no need to fill in the dnssec fields ‘generate’,
> ‘publish’ and ‘ready’.
No, these are part of the keys history and the assumption was that this
data would not be available for keys being imported.
>
> Is my interpretation correct? Is there anything else I have overlooked?
>
> Also, I don’t understand the meaning of the fixedDate field, should I
> change it back to 0?
>
This flag means that even if you change the policy to allow keys to be
used for longer, the retire time of _this_ key will not change to
reflect that. This flag is set when you import a key with a retire time
as you are telling the system when you want this key to retire.
Sion
>
>
> All comments and suggestions are welcome.
>
> Thanks in advance,
>
>
>
> Anne van Bemmelen
>
> SIDN | Meander 501| 6825 MD | Postbus 5022 | 6802 AE | ARNHEM T +31
> (0)26 352 55 00 | M +31 (0)6 15 06 33 96 | F +31 (0)26 352 55 05
> [email protected]| <mailto:[email protected]|>
> www.sidn.nl| <http://www.sidn.nl|> Key-ID: 0xB8A5F0B2
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Opendnssec-user mailing list
> [email protected]
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
>
------------------------------
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
End of Opendnssec-user Digest, Vol 77, Issue 9
**********************************************
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
