From rickard.bellgrim at iis.se Mon May 3 08:08:35 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 3 May 2010 10:08:35 +0200 Subject: [Opendnssec-develop] SHA-2 keys mixed up In-Reply-To: References: Message-ID: <91280627-A124-4A15-9D91-6090C281FC19@iis.se> > > For each signed domain chosen for verification, the KA should check that: > ? There is an RRSIG record for each algorithm for which there is a DNSKEY RR (unless the domain is glue, an unsigned delegation or out of zone) [E] > ? > > In this case, there isn?t an RRSIG for algorithm 8 ? only one for algorithm 10. So the auditor is simply pointing that out. Yeah RFC4035 - Section 2.2 "There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset." So you cannot use one algorithm for the KSK and another for the ZSK in OpenDNSSEC. // Rickard From rickard.bellgrim at iis.se Mon May 3 08:09:25 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 3 May 2010 10:09:25 +0200 Subject: [Opendnssec-develop] Release of 1.1.0rc2? Message-ID: <30B3E07E-A09E-4049-B468-D54DB7C67DE6@iis.se> Hi How is it going with rc2? // Rickard From jakob at kirei.se Mon May 3 09:03:29 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 3 May 2010 11:03:29 +0200 Subject: [Opendnssec-develop] Release of 1.1.0rc2? In-Reply-To: <30B3E07E-A09E-4049-B468-D54DB7C67DE6@iis.se> References: <30B3E07E-A09E-4049-B468-D54DB7C67DE6@iis.se> Message-ID: <994B46B2-F42C-4001-8DB1-30307E847FF7@kirei.se> On 3 maj 2010, at 10.09, Rickard Bellgrim wrote: > How is it going with rc2? I'm waiting for the SHA-2 auditor thing to be fixed, dismissed or ignored. jakob From rick at openfortress.nl Mon May 3 13:24:03 2010 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 3 May 2010 13:24:03 +0000 Subject: [Opendnssec-develop] Meeting notes 2010-04-29 Message-ID: <20100503132403.GA9314@phantom.vanrein.org> Hello, I just posted the meeting notes of last week onto Trac. Any remarks are welcomed. English lads, please note that we made an inconsistent appointment for the next meeting, which I corrected to what I believe we meant: We said we'd meet at 14:00-15:00 CEST or 13:00-14:00 GMT. There are 2 hours time difference between GMT and CEST, so I suppose we meant to say 13:00-14:00 BST. I'm almost certain that's what you wrote down anyway... Cheers, -Rick From AlexD at nominet.org.uk Tue May 4 07:29:13 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Tue, 4 May 2010 07:29:13 +0000 Subject: [Opendnssec-develop] SHA-2 keys mixed up In-Reply-To: <91280627-A124-4A15-9D91-6090C281FC19@iis.se> Message-ID: >> For each signed domain chosen for verification, the KA should check that: >> ? There is an RRSIG record for each algorithm for which there is a DNSKEY RR >> (unless the domain is glue, an unsigned delegation or out of zone) [E] >> ? >> >> In this case, there isn?t an RRSIG for algorithm 8 ? only one for algorithm >> 10. So the auditor is simply pointing that out. > > Yeah > > RFC4035 - Section 2.2 > "There MUST be an RRSIG for each RRset using at least one DNSKEY of each > algorithm in the zone apex DNSKEY RRset." > > So you cannot use one algorithm for the KSK and another for the ZSK in > OpenDNSSEC. Sorry - slow start after a chicken-pox filled weekend... Why can't you use two algorithms? Surely the rrsets should all be signed by both algorithms, and everyone would be happy? Is it not an error in the signing system to produce only one signature for these records? Thanks, Alex. From rickard.bellgrim at iis.se Tue May 4 07:54:48 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 4 May 2010 09:54:48 +0200 Subject: [Opendnssec-develop] SHA-2 keys mixed up In-Reply-To: References: Message-ID: On 4 maj 2010, at 09.29, Alex Dalitz wrote: >>> For each signed domain chosen for verification, the KA should check that: >>> ? There is an RRSIG record for each algorithm for which there is a DNSKEY RR >>> (unless the domain is glue, an unsigned delegation or out of zone) [E] >>> ? >>> >>> In this case, there isn?t an RRSIG for algorithm 8 only one for algorithm >>> 10. So the auditor is simply pointing that out. >> >> Yeah >> >> RFC4035 - Section 2.2 >> "There MUST be an RRSIG for each RRset using at least one DNSKEY of each >> algorithm in the zone apex DNSKEY RRset." >> >> So you cannot use one algorithm for the KSK and another for the ZSK in >> OpenDNSSEC. > > Sorry - slow start after a chicken-pox filled weekend... > > Why can't you use two algorithms? Surely the rrsets should all be signed by > both algorithms, and everyone would be happy? Is it not an error in the > signing system to produce only one signature for these records? You can, but not in OpenDNSSEC 1.1.0. OpenDNSSEC does not handle multiple algorithms correctly. From roy at nominet.org.uk Tue May 4 09:35:45 2010 From: roy at nominet.org.uk (Roy Arends) Date: Tue, 4 May 2010 09:35:45 +0000 Subject: [Opendnssec-develop] SHA-2 keys mixed up In-Reply-To: References: Message-ID: <9922AAD9-676F-40B6-88EE-0CE956DEBF7D@nominet.org.uk> On May 4, 2010, at 8:29 AM, Alex Dalitz wrote: >>> For each signed domain chosen for verification, the KA should check that: >>> ? There is an RRSIG record for each algorithm for which there is a DNSKEY RR >>> (unless the domain is glue, an unsigned delegation or out of zone) [E] >>> ? >>> >>> In this case, there isn?t an RRSIG for algorithm 8 only one for algorithm >>> 10. So the auditor is simply pointing that out. >> >> Yeah >> >> RFC4035 - Section 2.2 >> "There MUST be an RRSIG for each RRset using at least one DNSKEY of each >> algorithm in the zone apex DNSKEY RRset." >> >> So you cannot use one algorithm for the KSK and another for the ZSK in >> OpenDNSSEC. > > Sorry - slow start after a chicken-pox filled weekend... > > Why can't you use two algorithms? Surely the rrsets should all be signed by > both algorithms, and everyone would be happy? Yep > Is it not an error in the > signing system to produce only one signature for these records? It is. Roy From owner-dnssec-trac at kirei.se Tue May 4 21:47:43 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 04 May 2010 21:47:43 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #131: test suite fails in 1.1.0rc2 Message-ID: <055.6ca5d6cd6e45e2a6f75eeb05d703e218@kirei.se> #131: test suite fails in 1.1.0rc2 ------------------------------+--------------------------------------------- Reporter: tom@? | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ------------------------------+--------------------------------------------- Test suite as packaged with 1.1.0rc2 fails with the following error on both x86 and x86_64: {{{ x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../common -I./../ksm/include -I./../ksm/include -I/usr/local/include -I/usr/local/include -g -O2 -pedantic -Wall -Wextra -MT test_ksm_key.o -MD -MP -MF .deps/test_ksm_key.Tpo -c -o test_ksm_key.o test_ksm_key.c test_ksm_key.c: In function ?TestKsmKeyPredict?: test_ksm_key.c:268: error: too few arguments to function ?KsmKeyPredict? test_ksm_key.c:274: error: too few arguments to function ?KsmKeyPredict? test_ksm_key.c: In function ?TestKsmKeyCountUnallocated?: test_ksm_key.c:318: warning: unused variable ?algorithm? test_ksm_key.c:317: warning: unused variable ?bits? test_ksm_key.c:316: warning: unused variable ?sm? test_ksm_key.c:315: warning: unused variable ?policy_id? test_ksm_key.c: In function ?TestKsmKeyGetUnallocated?: test_ksm_key.c:357: warning: passing argument 4 of ?KsmDnssecKeyCreate? from incompatible pointer type test_ksm_key.c: In function ?TestKsmDnssecKeyCreateOnPolicy?: test_ksm_key.c:382: warning: unused variable ?zone_id? test_ksm_key.c:377: warning: unused variable ?dnsseckey_id? make[3]: *** [test_ksm_key.o] Error 1 make[3]: Leaving directory `/home/tomhendr/work/opendnssec-1.1.0rc2/enforcer/test' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/tomhendr/work/opendnssec-1.1.0rc2/enforcer/test' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/tomhendr/work/opendnssec-1.1.0rc2/enforcer' make: *** [check-recursive] Error 1 }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From sion at nominet.org.uk Wed May 5 08:46:56 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Wed, 5 May 2010 08:46:56 +0000 Subject: [Opendnssec-develop] ZSK rollovers Message-ID: We had a discussion on the phone conference about ZSK rollovers and why the signatures are all recreated... Rickard has just pointed out to me that the timing draft includes a term Dsgn in the ZSK retire time. What this does is add in the time that a signature can be expected to hang around in a zone for. I think that this is: (validity - refresh) + resign (I.e. assume the signature is created just before a key expires, then add up the length of time that the signature will be left alone plus the resign interval which is just the granularity of the system.) So if I add this to the length of time that the key is published in the zone after it retires we can have the gradual switch between keys which will look like: Sign with the old key until it retires, then use the _new_ key to replace signatures as they reach the end of their lives. The old key will be published for longer, until all signatures generated with it have been replaced. This way we do not need to communicate any more information to the signer. Does this work? Sion -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Wed May 5 09:22:40 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Wed, 5 May 2010 09:22:40 +0000 Subject: [Opendnssec-develop] Re: #131: test suite fails in 1.1.0rc2 Message-ID: Looks like I forgot to patch the 1.1 branch with these fixes. Shall I patch the branch now? We are due to release today so maybe I should just add it to the KNOWN_ISSUES? Sion ________________________________________ From: opendnssec-develop-bounces at lists.opendnssec.org [opendnssec-develop-bounces at lists.opendnssec.org] on behalf of OpenDNSSEC [owner-dnssec-trac at kirei.se] Sent: 04 May 2010 22:47 Cc: opendnssec-develop at lists.opendnssec.org Subject: [Opendnssec-develop] [OpenDNSSEC] #131: test suite fails in 1.1.0rc2 #131: test suite fails in 1.1.0rc2 ------------------------------+--------------------------------------------- Reporter: tom@? | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: ------------------------------+--------------------------------------------- Test suite as packaged with 1.1.0rc2 fails with the following error on both x86 and x86_64: {{{ x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../common -I./../ksm/include -I./../ksm/include -I/usr/local/include -I/usr/local/include -g -O2 -pedantic -Wall -Wextra -MT test_ksm_key.o -MD -MP -MF .deps/test_ksm_key.Tpo -c -o test_ksm_key.o test_ksm_key.c test_ksm_key.c: In function ?TestKsmKeyPredict?: test_ksm_key.c:268: error: too few arguments to function ?KsmKeyPredict? test_ksm_key.c:274: error: too few arguments to function ?KsmKeyPredict? test_ksm_key.c: In function ?TestKsmKeyCountUnallocated?: test_ksm_key.c:318: warning: unused variable ?algorithm? test_ksm_key.c:317: warning: unused variable ?bits? test_ksm_key.c:316: warning: unused variable ?sm? test_ksm_key.c:315: warning: unused variable ?policy_id? test_ksm_key.c: In function ?TestKsmKeyGetUnallocated?: test_ksm_key.c:357: warning: passing argument 4 of ?KsmDnssecKeyCreate? from incompatible pointer type test_ksm_key.c: In function ?TestKsmDnssecKeyCreateOnPolicy?: test_ksm_key.c:382: warning: unused variable ?zone_id? test_ksm_key.c:377: warning: unused variable ?dnsseckey_id? make[3]: *** [test_ksm_key.o] Error 1 make[3]: Leaving directory `/home/tomhendr/work/opendnssec-1.1.0rc2/enforcer/test' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/tomhendr/work/opendnssec-1.1.0rc2/enforcer/test' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/tomhendr/work/opendnssec-1.1.0rc2/enforcer' make: *** [check-recursive] Error 1 }}} -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Wed May 5 09:54:55 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 05 May 2010 11:54:55 +0200 Subject: [Opendnssec-develop] Re: #131: test suite fails in 1.1.0rc2 In-Reply-To: References: Message-ID: <4BE1406F.5050806@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Imo, patch 1.1 branch. I received another issue in rc2 (quicksorter related), so I think we need a rc3 anyway... Matthijs Sion Lloyd wrote: > Looks like I forgot to patch the 1.1 branch with these fixes. > > Shall I patch the branch now? We are due to release today so maybe I should just add it to the KNOWN_ISSUES? > > Sion > > ________________________________________ > From: opendnssec-develop-bounces at lists.opendnssec.org [opendnssec-develop-bounces at lists.opendnssec.org] on behalf of OpenDNSSEC [owner-dnssec-trac at kirei.se] > Sent: 04 May 2010 22:47 > Cc: opendnssec-develop at lists.opendnssec.org > Subject: [Opendnssec-develop] [OpenDNSSEC] #131: test suite fails in 1.1.0rc2 > > #131: test suite fails in 1.1.0rc2 > ------------------------------+--------------------------------------------- > Reporter: tom@? | Owner: rb > Type: defect | Status: new > Priority: major | Component: Unknown > Version: trunk | Keywords: > ------------------------------+--------------------------------------------- > Test suite as packaged with 1.1.0rc2 fails with the following error on > both x86 and x86_64: > > {{{ > x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../common > -I./../ksm/include -I./../ksm/include -I/usr/local/include > -I/usr/local/include -g -O2 -pedantic -Wall -Wextra -MT test_ksm_key.o > -MD -MP -MF .deps/test_ksm_key.Tpo -c -o test_ksm_key.o test_ksm_key.c > test_ksm_key.c: In function ?TestKsmKeyPredict?: > test_ksm_key.c:268: error: too few arguments to function ?KsmKeyPredict? > test_ksm_key.c:274: error: too few arguments to function ?KsmKeyPredict? > test_ksm_key.c: In function ?TestKsmKeyCountUnallocated?: > test_ksm_key.c:318: warning: unused variable ?algorithm? > test_ksm_key.c:317: warning: unused variable ?bits? > test_ksm_key.c:316: warning: unused variable ?sm? > test_ksm_key.c:315: warning: unused variable ?policy_id? > test_ksm_key.c: In function ?TestKsmKeyGetUnallocated?: > test_ksm_key.c:357: warning: passing argument 4 of ?KsmDnssecKeyCreate? > from incompatible pointer type > test_ksm_key.c: In function ?TestKsmDnssecKeyCreateOnPolicy?: > test_ksm_key.c:382: warning: unused variable ?zone_id? > test_ksm_key.c:377: warning: unused variable ?dnsseckey_id? > make[3]: *** [test_ksm_key.o] Error 1 > make[3]: Leaving directory > `/home/tomhendr/work/opendnssec-1.1.0rc2/enforcer/test' > make[2]: *** [check-am] Error 2 > make[2]: Leaving directory > `/home/tomhendr/work/opendnssec-1.1.0rc2/enforcer/test' > make[1]: *** [check-recursive] Error 1 > make[1]: Leaving directory > `/home/tomhendr/work/opendnssec-1.1.0rc2/enforcer' > make: *** [check-recursive] Error 1 > > }}} > > -- > Ticket URL: > OpenDNSSEC > OpenDNSSEC > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJL4UBkAAoJEA8yVCPsQCW5ZR8IAJgTxou5s9oqQEdSEwGQmXtk u5FSpg9krJrLdZPhkku4IBFmgPrttn6KqWl7zpl9Vxr4K7cdOaEVXFF1IfWHwYj8 +MrG+uDC55osNW21aI9vhiKZUtG1SjlwpsDLf9hNxKgoYCaOj+08/ztpyusCRaQ9 bavAaNdiBAAfvl2H82DitVwRAlDGa0qBLyySnKLXY14Qs/kqkPePwTqObpIeRHUw iB0MQAfimbKmi0NadgVL4lUL89XM8r3Xo9uk4gGu0v2qKycDmauEc7mUheOgxYfi DvOb/HAw9e8GiGxGXdEzuqggYuSOqIvvCWjhnVv49ZOd0ldCjIsdehoSTfa3RP4= =MYRA -----END PGP SIGNATURE----- From sa.morris7 at googlemail.com Wed May 5 12:24:00 2010 From: sa.morris7 at googlemail.com (Stephen Morris) Date: Wed, 05 May 2010 13:24:00 +0100 Subject: [Opendnssec-develop] ZSK rollovers In-Reply-To: References: Message-ID: <4BE16360.7050401@googlemail.com> On 05/05/2010 09:46, Sion Lloyd wrote: > We had a discussion on the phone conference about ZSK rollovers and why > the signatures are all recreated... > > Rickard has just pointed out to me that the timing draft includes a term > Dsgn in the ZSK retire time. > > What this does is add in the time that a signature can be expected to > hang around in a zone for. I think that this is: > > (validity - refresh) + resign > > (I.e. assume the signature is created just before a key expires, then > add up the length of time that the signature will be left alone plus the > resign interval which is just the granularity of the system.) > > So if I add this to the length of time that the key is published in the > zone after it retires we can have the gradual switch between keys which > will look like: > > Sign with the old key until it retires, then use the _new_ key to > replace signatures as they reach the end of their lives. The old key > will be published for longer, until all signatures generated with it > have been replaced. > > This way we do not need to communicate any more information to the signer. > > Does this work? > > Sion That's the way I envisage it working. AIUI, at the moment the signer is told what keys to publish in the zone and, of those keys, what key is the active one. No change is needed to that for this scheme to work. Stephen From matthijs at NLnetLabs.nl Wed May 5 13:20:53 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 05 May 2010 15:20:53 +0200 Subject: [Opendnssec-develop] ZSK rollovers In-Reply-To: <4BE16360.7050401@googlemail.com> References: <4BE16360.7050401@googlemail.com> Message-ID: <4BE170B5.7050906@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It may work. It does need changes in the signer though. And at the cost of rollover knowledge in the signer engine: The signer currently replaces signatures only if the keytag matches. For example, in the current signer engine, Key 12345 will not replace old signatures that were created with Key 67890. If we want to solve it this way, I need to make this change in the signer engine. I need to make it replace signatures per algorithm, not on a key level. I think there are a couple of disadvantages here. - - It works only for pre-published key rollover. For a double signature (or double key rollover?), the new key must immediately be used for signing (If I read the key-timing draft correctly). With the new proposal, if there is a different signature present (created with a different key) that is still fresh, we don't create a signature for the new key. This means, we break the requirement that the new key is immediately used for signing. - - Thus, we need to make an exception for KSK. - - Now we have introduced assumptions about what rollover scheme is used into the signer engine. While it was explicitly designed *not* to know about. Best regards, Matthijs Stephen Morris wrote: > On 05/05/2010 09:46, Sion Lloyd wrote: > >> We had a discussion on the phone conference about ZSK rollovers and why >> the signatures are all recreated... >> >> Rickard has just pointed out to me that the timing draft includes a term >> Dsgn in the ZSK retire time. >> >> What this does is add in the time that a signature can be expected to >> hang around in a zone for. I think that this is: >> >> (validity - refresh) + resign >> >> (I.e. assume the signature is created just before a key expires, then >> add up the length of time that the signature will be left alone plus the >> resign interval which is just the granularity of the system.) >> >> So if I add this to the length of time that the key is published in the >> zone after it retires we can have the gradual switch between keys which >> will look like: >> >> Sign with the old key until it retires, then use the _new_ key to >> replace signatures as they reach the end of their lives. The old key >> will be published for longer, until all signatures generated with it >> have been replaced. >> >> This way we do not need to communicate any more information to the >> signer. >> >> Does this work? >> >> Sion > > That's the way I envisage it working. > > AIUI, at the moment the signer is told what keys to publish in the zone > and, of those keys, what key is the active one. No change is needed to > that for this scheme to work. > > Stephen > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJL4XCwAAoJEA8yVCPsQCW5yScH/RQ9H2MKlSCbYkHsFEyIDSV+ g1rnyI62hZH1A/XeQxyKnpI9JuOXn9m2ehQt7AvqU4czgR42twsCy0iKEeh9c2ho iiHOn+iFilwOmkZJSMHVdykD/GmkV9ZHuePijBRgi0f8fGbB7JEDgq7st+kTXJP2 6DyOVNQstpJpQ/7UJIu6At/RbSOL496vx3O/Tn0UamelxDqhYMmBitNTt7xMc/nU 2MyRY1uWMA/n+Wwa9HRqG4g0M0oMwcQX7HOswrGYVqjsnE2J5UUxfS1Ig7aUJPQd UJ/DCvmyEOJ5DergWxmNXbPInwFrLtbL3HqfJ5/JkZ//cFjaVLSJZdzj30W0v1g= =Vdob -----END PGP SIGNATURE----- From jakob at kirei.se Wed May 5 13:30:33 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 5 May 2010 15:30:33 +0200 Subject: [Opendnssec-develop] ZSK rollovers In-Reply-To: <4BE170B5.7050906@nlnetlabs.nl> References: <4BE16360.7050401@googlemail.com> <4BE170B5.7050906@nlnetlabs.nl> Message-ID: <4F9F2D72-1BBB-4186-8FBF-6E024DA80635@kirei.se> This is my current thinking when it comes to what keys are included, signatures are recycled and keys used for signing: ## DNSKEYs included in the resulting zone file Keys marked as Published should be extracted from the HSM and included in the signed zonefile. ## Recycling RRSIGs Signatures for which all the following conditions hold may be recycled: - Inception time has passed - Expiration minus Refresh has not yet passed - The signer key is marked as Publish (i.e., exists in the zone) - The signer key is not marked as revoked To let new key signing keys sign the DNSKEY RRset without delay, e.g. for double signed DNSKEYs, one of the following algoritms can be used: - If the RRSIG covers a DNSKEY and the set RRSIGs (using the same algorithm) does not include signatures by all keys marked as KSK, RRSIGs for that DNSKEY may not be recycled. - Always drop (i.e. not recycle) signatures covering DNSKEYs. ## Generated RRSIG If there are no valid signatures by a key using the same algorithm as the key eligible for signing, a new signature must be created. Multiple signatures for a single RRset may be created if multiple keys has KSK and/or ZSK set. - Keys marked as KSK are used to sign all DNSKEY resource records. - Keys marked as ZSK are used to sign all non-DNSKEY resource records. (N.B. a single key can be marked as both KSK and ZSK) From owner-dnssec-trac at kirei.se Wed May 5 14:16:50 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 05 May 2010 14:16:50 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #131: test suite fails in 1.1.0rc2 In-Reply-To: <055.6ca5d6cd6e45e2a6f75eeb05d703e218@kirei.se> References: <055.6ca5d6cd6e45e2a6f75eeb05d703e218@kirei.se> Message-ID: <064.ac379c6568fe7603615b376a6e51efe0@kirei.se> #131: test suite fails in 1.1.0rc2 ------------------------------+--------------------------------------------- Reporter: tom@? | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Changes (by sion): * status: new => closed * resolution: => fixed Comment: Thank you. This is patched in the branch now. Note that for the sqlite version you need the environment variable DB_NAME set (to a file to act as a temporary database) at configure time. The mysql version requires more variables, see the KNOWN_ISSUES file in the branch. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Wed May 5 14:52:15 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 05 May 2010 14:52:15 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #130: ods-ksmutil key export shows dead keys with option -e RETIRED In-Reply-To: <076.35cd537382034993128ec4179ffb73d8@kirei.se> References: <076.35cd537382034993128ec4179ffb73d8@kirei.se> Message-ID: <085.f89f1f38911a53afd055ed916d84f120@kirei.se> #130: ods-ksmutil key export shows dead keys with option -e RETIRED ---------------------------------------------------+------------------------ Reporter: Anirban Mukherjee | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: 1.0.0 | Resolution: fixed Keywords: | ---------------------------------------------------+------------------------ Changes (by sion): * status: new => closed * resolution: => fixed Old description: > ods-ksmutil key export -z -t ZSK -e RETIRED > > shows DEAD keys instead of RETIRED keys. > > The attached modified source file enforcer/utils/ksmutil.c appears to > show the keys correctly > (modifications were made on the version of the source file present in the > 1.0.0 release tarball) New description: ods-ksmutil key export -z -t ZSK -e RETIRED shows DEAD keys instead of RETIRED keys. The attached modified source file enforcer/utils/ksmutil.c appears to show the keys correctly (modifications were made on the version of the source file present in the 1.0.0 release tarball) -- Comment: Thank you. This is now fixed in trunk. -- Ticket URL: OpenDNSSEC OpenDNSSEC From matthijs at NLnetLabs.nl Wed May 5 15:20:23 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 05 May 2010 17:20:23 +0200 Subject: [Opendnssec-develop] SHA-2 keys mixed up In-Reply-To: <9922AAD9-676F-40B6-88EE-0CE956DEBF7D@nominet.org.uk> References: <9922AAD9-676F-40B6-88EE-0CE956DEBF7D@nominet.org.uk> Message-ID: <4BE18CB7.5070806@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Catching up on this thread... I agree this is a bug. I assume the signer engine is just following orders: The signer configuration is presumably not marking the key with algorithm 8 as a KSK (and the key with algorithm 10 as ZSK). The question is, who should take care of this? Should the signer discover this and not follow the signer configuration? Should the enforcer discover this and mark both ZSK/KSK? Or should we forbid this policy? Or should we extend the KNOWN ISSUES about algorithm rollover with 'using multiple algorithms is broken'? Best regards, Matthijs Roy Arends wrote: > On May 4, 2010, at 8:29 AM, Alex Dalitz wrote: > >>>> For each signed domain chosen for verification, the KA should check that: >>>> ? There is an RRSIG record for each algorithm for which there is a DNSKEY RR >>>> (unless the domain is glue, an unsigned delegation or out of zone) [E] >>>> ? >>>> >>>> In this case, there isn?t an RRSIG for algorithm 8 only one for algorithm >>>> 10. So the auditor is simply pointing that out. >>> Yeah >>> >>> RFC4035 - Section 2.2 >>> "There MUST be an RRSIG for each RRset using at least one DNSKEY of each >>> algorithm in the zone apex DNSKEY RRset." >>> >>> So you cannot use one algorithm for the KSK and another for the ZSK in >>> OpenDNSSEC. >> Sorry - slow start after a chicken-pox filled weekend... >> >> Why can't you use two algorithms? Surely the rrsets should all be signed by >> both algorithms, and everyone would be happy? > > Yep > >> Is it not an error in the >> signing system to produce only one signature for these records? > > It is. > > Roy_______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJL4Yy0AAoJEA8yVCPsQCW58ncH/3IpJxiLC2bpgNFmtyRziBxC BngEVsN/irr8RvRxcSFmSdhKpwutR61BUtCTbVcVsX6zz4tC7Q4usEELXKH/29os k5Iw4allGqIrYiXbT5h5J+k2y2dbO75oyKwKDISINVXj4FkIlk+2A9kulfm8jnqo v4gyIiyV/g5vT+s1Njo7ph4h82o0D0fAL7cA9wwc86DXp2+Vj2qNAQqC4okfdmvO dYOFDe2lckk0hcDWfPUHK3KQAj7cWCDQlVW7Nc56lKIkAHetvfWZAErnypBn/HxB 8OmTs9Lv7tbYg78bzBLbzDsjQnZugkiE/X3cwiBiesdr/LL5x1qoLj32e6dtzuo= =yVCG -----END PGP SIGNATURE----- From sion at nominet.org.uk Thu May 6 08:06:19 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Thu, 6 May 2010 08:06:19 +0000 Subject: [Opendnssec-develop] ZSK rollovers In-Reply-To: <4BE170B5.7050906@nlnetlabs.nl> References: <4BE16360.7050401@googlemail.com>,<4BE170B5.7050906@nlnetlabs.nl> Message-ID: > The signer currently replaces signatures only if the keytag matches. For > example, in the current signer engine, Key 12345 will not replace old > signatures that were created with Key 67890. So in the unlikely event that you roll to a key with the same keytag we would see a gradual replacement of signatures? - - Now we have introduced assumptions about what rollover scheme is used into the signer engine. While it was explicitly designed *not* to know about. I think that we can cope with this. The enforcer should mark any key that should be used to sign as "active", then the signer doesn't need to know _why_ the key should be used, just that it should be. From matthijs at NLnetLabs.nl Thu May 6 10:16:32 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 06 May 2010 12:16:32 +0200 Subject: [Opendnssec-develop] ZSK rollovers In-Reply-To: References: <4BE16360.7050401@googlemail.com>, <4BE170B5.7050906@nlnetlabs.nl> Message-ID: <4BE29700.20306@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sion Lloyd wrote: >> The signer currently replaces signatures only if the keytag matches. For >> example, in the current signer engine, Key 12345 will not replace old >> signatures that were created with Key 67890. > > So in the unlikely event that you roll to a key with the same keytag we would see a gradual replacement of signatures? Yes. This was already a known issue by the way. > > > - - Now we have introduced assumptions about what rollover scheme is used > into the signer engine. While it was explicitly designed *not* to know > about. > > I think that we can cope with this. The enforcer should mark any key that should be used to sign as "active", then the signer doesn't need to know _why_ the key should be used, just that it should be. That's ok. But the problem is the way the signer needs to replace signatures: - - In a pre-published rollover mechanism, you *don't* create a new signature for the introduced key if there is a fresh signatures created with a different key. - - In a double signature rollover mechanism, you *do* create a new signature for the introduced key if there is a fresh signatures created with a different key. Best regards, Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJL4pbzAAoJEA8yVCPsQCW5PXIIANbkmmUXgobuTHzVJ3ONtO/W /8gfJcrzRatTl5z07aUaazAhNfNsDy56zfhLwUmGO9my3oWo/mBe3uI/PtB8kkqs IRp1AvXMLDyV4IyiWslvvLxJbs9yp6EI1vuljseNjDtnmXock81ndonL0pbBsD5U COdINJY9k1h2Bhr5gH3p5IA0giPvwcJwMxX1QzZyeBpBeBix4SuEWBsxojHh/lbB taSYyUoBPKKC5sr8EGeQZeFwDJUSrli6zuxNB5RQd18f5XQ3et0ijLLjiRElJQZp mXutE5GMliJ2Ngm5Zee6Msv5KHXzYUd72A1PUz2sllzoCx8ZMcesZzhC9HUj23Q= =qfd9 -----END PGP SIGNATURE----- From jakob at kirei.se Thu May 6 10:45:41 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 6 May 2010 12:45:41 +0200 Subject: [Opendnssec-develop] ZSK rollovers In-Reply-To: <4BE29700.20306@nlnetlabs.nl> References: <4BE16360.7050401@googlemail.com>, <4BE170B5.7050906@nlnetlabs.nl> <4BE29700.20306@nlnetlabs.nl> Message-ID: <756F1441-8EA8-46F8-8C02-0E4FC6A85334@kirei.se> On 6 maj 2010, at 12.16, Matthijs Mekking wrote: > That's ok. But the problem is the way the signer needs to replace > signatures: > > - - In a pre-published rollover mechanism, you *don't* create a new > signature for the introduced key if there is a fresh signatures created > with a different key. > > - - In a double signature rollover mechanism, you *do* create a new > signature for the introduced key if there is a fresh signatures created > with a different key. doesn't my rule: - If the RRSIG covers a DNSKEY and the set of RRSIGs (using the same algorithm) does not include signatures by all keys marked as KSK, RRSIGs for that DNSKEY may not be recycled. handle this automagically? this way you can recycle RRSIG DNSKEY, but you don't in case when a new KSK appears. jakob From matthijs at NLnetLabs.nl Thu May 6 12:07:26 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 06 May 2010 14:07:26 +0200 Subject: [Opendnssec-develop] ZSK rollovers In-Reply-To: <756F1441-8EA8-46F8-8C02-0E4FC6A85334@kirei.se> References: <4BE16360.7050401@googlemail.com>, <4BE170B5.7050906@nlnetlabs.nl> <4BE29700.20306@nlnetlabs.nl> <756F1441-8EA8-46F8-8C02-0E4FC6A85334@kirei.se> Message-ID: <4BE2B0FE.2020902@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 That rule implies that we always going to use double signature rollover for KSKs and always going to use pre-publish key rollover for ZSKs Best regards, Matthijs Jakob Schlyter wrote: > On 6 maj 2010, at 12.16, Matthijs Mekking wrote: > >> That's ok. But the problem is the way the signer needs to replace >> signatures: >> >> - - In a pre-published rollover mechanism, you *don't* create a new >> signature for the introduced key if there is a fresh signatures created >> with a different key. >> >> - - In a double signature rollover mechanism, you *do* create a new >> signature for the introduced key if there is a fresh signatures created >> with a different key. > > doesn't my rule: > > - If the RRSIG covers a DNSKEY and the set of RRSIGs (using the same algorithm) > does not include signatures by all keys marked as KSK, RRSIGs for that > DNSKEY may not be recycled. > > handle this automagically? this way you can recycle RRSIG DNSKEY, but you don't in case when a new KSK appears. > > > jakob > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJL4rD0AAoJEA8yVCPsQCW56M8H/2vhUR83bKQk5/00XCQ6fI8W 4oqnLUI5e5sOSw1Cl/4yfJocqstH2EauqgIm5QYpOvBcI4DDUZmnVk3Qut7lJNNm clVNZZMRMr9RZn+Q9y9oLZ+xhBSvKR4mNfFMj8ekUaLOwoVAxKvQUpIyPb+1YyNd JiCcYfqatDHxPwdTBh4OO+BwTUSy4ApIyo1oBQDNkyGpB170/ah8bEl5AZ5O6C+G 38z5/qpUIWS9eLfD9HstDHVnoxI2bfMDyow7UQiSLMllmoVE0lwPfsR7aYdItgBn +waG58OYOSkCUDrSI2oD2tPaPOvmR8B90QIm7Qzr+kR4PIRGNDCpTxBYvQ6/QPQ= =6/0n -----END PGP SIGNATURE----- From jakob at kirei.se Thu May 6 12:07:57 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 6 May 2010 14:07:57 +0200 Subject: [Opendnssec-develop] ZSK rollovers In-Reply-To: <4BE2B0FE.2020902@nlnetlabs.nl> References: <4BE16360.7050401@googlemail.com>, <4BE170B5.7050906@nlnetlabs.nl> <4BE29700.20306@nlnetlabs.nl> <756F1441-8EA8-46F8-8C02-0E4FC6A85334@kirei.se> <4BE2B0FE.2020902@nlnetlabs.nl> Message-ID: On 6 maj 2010, at 14.07, Matthijs Mekking wrote: > That rule implies that we always going to use double signature rollover > for KSKs and always going to use pre-publish key rollover for ZSKs for KSK, no - if you use a pre-publish key rollover for the KSK it works as well. for ZSK, yes - but doing anything else for ZSK rollovers is IMHO just plain stupid. also, doing double signature rollovers with just one combined KSK/ZSK works as well but that is just absurd. jakob From matthijs at NLnetLabs.nl Thu May 6 13:01:57 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 06 May 2010 15:01:57 +0200 Subject: [Opendnssec-develop] ZSK rollovers In-Reply-To: References: <4BE16360.7050401@googlemail.com>, <4BE170B5.7050906@nlnetlabs.nl> <4BE29700.20306@nlnetlabs.nl> <756F1441-8EA8-46F8-8C02-0E4FC6A85334@kirei.se> <4BE2B0FE.2020902@nlnetlabs.nl> Message-ID: <4BE2BDC5.1080306@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jakob Schlyter wrote: > On 6 maj 2010, at 14.07, Matthijs Mekking wrote: > >> That rule implies that we always going to use double signature rollover >> for KSKs and always going to use pre-publish key rollover for ZSKs > > for KSK, no - if you use a pre-publish key rollover for the KSK it works as well. Sure, because you never reuse signatures in this special rule, you can do every rollover you want. > for ZSK, yes - but doing anything else for ZSK rollovers is IMHO just plain stupid. I am not judging signing policies. I am worried about limiting possibilities for OpenDNSSEC. It might be that I want to sign my small zone with double signatures (don't care about the size). A new rollover scheme might be introduced. And thus we have key rollover assumptions in the signer engine which breaks the original design (keep repeating it...). We can do it this way, I just want to stress out the disadvantages. Best regards, Matthijs > also, doing double signature rollovers with just one combined KSK/ZSK works as well but that is just absurd. > > jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJL4r3CAAoJEA8yVCPsQCW5Z90H/igfMEWqlaOAKyL0DIfKovLM 2Ty3PFTizer1/l6POKBqoTkRpAxX+hT5K1vtph/JZg/C05duPtyV06GJ0JCvBHWp Vgh7l7fXE4MMjFFR2ZLEpmU2aPN+yGx5l0dAHSzLanIl00lRCbCewzeCF5EjAWtM 0zPEmzXYBQKAfZgVTLEX+ToW/dXpO+sBMXZoeBx0VvhAd+Ruy4/gCw5Emm3L/QoK RwuWyinRpkgut8ZcgCPQEBCP9Q/NS+163msUudpHQG8Qke3IFPDiQD7dmbjFfi27 8zC4o34OUCkEHAAM4fwemxhNaY96XApJUS5c5XtdtNjPTvSNcHYV5uSJrXwpzhQ= =MzLU -----END PGP SIGNATURE----- From jakob at kirei.se Thu May 6 13:03:04 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 6 May 2010 15:03:04 +0200 Subject: [Opendnssec-develop] ZSK rollovers In-Reply-To: <4BE2BDC5.1080306@nlnetlabs.nl> References: <4BE16360.7050401@googlemail.com>, <4BE170B5.7050906@nlnetlabs.nl> <4BE29700.20306@nlnetlabs.nl> <756F1441-8EA8-46F8-8C02-0E4FC6A85334@kirei.se> <4BE2B0FE.2020902@nlnetlabs.nl> <4BE2BDC5.1080306@nlnetlabs.nl> Message-ID: On 6 maj 2010, at 15.01, Matthijs Mekking wrote: >>> That rule implies that we always going to use double signature rollover >>> for KSKs and always going to use pre-publish key rollover for ZSKs >> >> for KSK, no - if you use a pre-publish key rollover for the KSK it works as well. > > Sure, because you never reuse signatures in this special rule, you can > do every rollover you want. the idea is to reuse signatures as long as the set of key signing keys is unchanged. jakob From matthijs at NLnetLabs.nl Thu May 6 13:14:04 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 06 May 2010 15:14:04 +0200 Subject: [Opendnssec-develop] ZSK rollovers In-Reply-To: References: <4BE16360.7050401@googlemail.com>, <4BE170B5.7050906@nlnetlabs.nl> <4BE29700.20306@nlnetlabs.nl> <756F1441-8EA8-46F8-8C02-0E4FC6A85334@kirei.se> <4BE2B0FE.2020902@nlnetlabs.nl> <4BE2BDC5.1080306@nlnetlabs.nl> Message-ID: <4BE2C09C.2070704@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jakob Schlyter wrote: > On 6 maj 2010, at 15.01, Matthijs Mekking wrote: >>>> That rule implies that we always going to use double signature rollover >>>> for KSKs and always going to use pre-publish key rollover for ZSKs >>> for KSK, no - if you use a pre-publish key rollover for the KSK it works as well. >> Sure, because you never reuse signatures in this special rule, you can >> do every rollover you want. > > the idea is to reuse signatures as long as the set of key signing keys is unchanged. So I have to keep a list of of previous key signing keys? Or check the previous signatures to the current key signing keys? Is it worth it to save creating two signatures for the DNSKEY RRset? Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJL4sCaAAoJEA8yVCPsQCW5JVkH/jJ3H7Dk2KvS6bZsAJJ9p0dW gkI8L3JoZh9lDCna93ntVZXu3sc/LypfDApUU/0QEcZ6fgLViuHGZzzv4JeqBGKh ZCJ0/xDX/3In5OFpj2aBV2qdye4J0tAYExqcxqIBKLOj3BIUztQzxcAHdV9sPScs IQfTvNc/cjMyCf7+MV/5LSUptfKruuSMHK/UldDnlBOyCOvwoBeffHKsvQEMQVV6 0z2onz2TVqaFLsDJAzKaAjcNOu6WOxaZ2CHyf3a92SEqDih8TCvrSNd9B3UG3ANs 3y/DnhTABIyQDuPOVPmd11PRsJadGtejOWh3hMENM7jaT1J2cyLjeqWxJMhhJLw= =A3Lu -----END PGP SIGNATURE----- From jakob at kirei.se Thu May 6 14:02:00 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 6 May 2010 16:02:00 +0200 Subject: [Opendnssec-develop] ZSK rollovers In-Reply-To: <4BE2C09C.2070704@nlnetlabs.nl> References: <4BE16360.7050401@googlemail.com>, <4BE170B5.7050906@nlnetlabs.nl> <4BE29700.20306@nlnetlabs.nl> <756F1441-8EA8-46F8-8C02-0E4FC6A85334@kirei.se> <4BE2B0FE.2020902@nlnetlabs.nl> <4BE2BDC5.1080306@nlnetlabs.nl> <4BE2C09C.2070704@nlnetlabs.nl> Message-ID: <621CCA20-CF66-4C0B-90D7-BB23CF4AC1C1@kirei.se> On 6 maj 2010, at 15.14, Matthijs Mekking wrote: >> the idea is to reuse signatures as long as the set of key signing keys is unchanged. > > So I have to keep a list of of previous key signing keys? > Or check the previous signatures to the current key signing keys? > Is it worth it to save creating two signatures for the DNSKEY RRset? if the set of keys used to create the DNSKEY RRSIG RRset is not the same as the set of keys marked as , you drop the signatures are recreate them. jakob From matthijs at NLnetLabs.nl Thu May 6 14:17:57 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 06 May 2010 16:17:57 +0200 Subject: [Opendnssec-develop] ZSK rollovers In-Reply-To: <621CCA20-CF66-4C0B-90D7-BB23CF4AC1C1@kirei.se> References: <4BE16360.7050401@googlemail.com>, <4BE170B5.7050906@nlnetlabs.nl> <4BE29700.20306@nlnetlabs.nl> <756F1441-8EA8-46F8-8C02-0E4FC6A85334@kirei.se> <4BE2B0FE.2020902@nlnetlabs.nl> <4BE2BDC5.1080306@nlnetlabs.nl> <4BE2C09C.2070704@nlnetlabs.nl> <621CCA20-CF66-4C0B-90D7-BB23CF4AC1C1@kirei.se> Message-ID: <4BE2CF95.7060708@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am getting confused more and more. But to be fair, the DNSKEY RRset is not that important if we talk about signature reusing. Matthijs Jakob Schlyter wrote: > On 6 maj 2010, at 15.14, Matthijs Mekking wrote: > >>> the idea is to reuse signatures as long as the set of key signing keys is unchanged. >> So I have to keep a list of of previous key signing keys? >> Or check the previous signatures to the current key signing keys? >> Is it worth it to save creating two signatures for the DNSKEY RRset? > > if the set of keys used to create the DNSKEY RRSIG RRset is not the same as the set of keys marked as , you drop the signatures are recreate them. > > jakob > > _______________________________________________ > Opendnssec-develop mailing list > Opendnssec-develop at lists.opendnssec.org > https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJL4s+TAAoJEA8yVCPsQCW5cRYIAM2hr5RQVSqq1wvxB2NrquzA fmpe0JZwxVu2VpFZsC3PxG/mcDEtmsMoA382vPvtXdIQvejQOVUlr+UUBHcKo6ce iHh0IOMHFGjP0KHCH1RFb3SzGoWZqUxcxnj7/yksYnP/QLN4r0ko+WpwjKjaF+Qa 2hzpt0BYzZ/pgdlufdwmxGcCnWEPTuqANkM1/ZYgwFynF/1iuX+wiRBBTbkgYjGZ t3Fc/t9RLfsGubkqh9dUS5+msnUrKSGyhXG/AJ0msJalCY8SgKEptgB+51JbAJVW XPFqP+leLosW9IvJc9Gnk1STQIdIPjNhKFtvW6J/a3kY7Vw1U+1EtX5YJAOyjlc= =EcUK -----END PGP SIGNATURE----- From jakob at kirei.se Thu May 6 14:20:17 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Thu, 6 May 2010 16:20:17 +0200 Subject: [Opendnssec-develop] ZSK rollovers In-Reply-To: <4BE2CF95.7060708@nlnetlabs.nl> References: <4BE16360.7050401@googlemail.com>, <4BE170B5.7050906@nlnetlabs.nl> <4BE29700.20306@nlnetlabs.nl> <756F1441-8EA8-46F8-8C02-0E4FC6A85334@kirei.se> <4BE2B0FE.2020902@nlnetlabs.nl> <4BE2BDC5.1080306@nlnetlabs.nl> <4BE2C09C.2070704@nlnetlabs.nl> <621CCA20-CF66-4C0B-90D7-BB23CF4AC1C1@kirei.se> <4BE2CF95.7060708@nlnetlabs.nl> Message-ID: <496D5FC5-18CD-4759-9EAA-745B8C8FD763@kirei.se> On 6 maj 2010, at 16.17, Matthijs Mekking wrote: > I am getting confused more and more. But to be fair, the DNSKEY RRset is > not that important if we talk about signature reusing. as I think this is very clear, what is it that is confusing? if we have example.com. DNSKEY ksk1 DNSKEY zsk1 RRSIG ksk1 then add another ksk2, giving: example.com. DNSKEY ksk1 DNSKEY ksk2 DNSKEY zsk1 RRSIG ksk1 the signer can (without any other infomration than the previously signed zone) detect that 'example.com RRSIG ksk2' is missing and drop the signature by ksk1. no? jakob From rick.zijlker at sidn.nl Thu May 6 15:04:09 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Thu, 6 May 2010 17:04:09 +0200 Subject: [Opendnssec-develop] NSEC3ing fails in RC2 Message-ID: <850A39016FA57A4887C0AA3C8085F949014D8759@KAEVS1.SIDN.local> Hey all, I can't figure out what's going wrong here. As I interpreted the logging, the auditor says there is no NSEC3 record present, but there are. Using default policy, with tighter timings (24H KSK rollover, 8H ZSK rollover, 15min resign etc.) . Can anyone help me out on this one? LOGGING: May 6 16:51:28 signer1 ods-enforcerd: opendnssec-enforcer starting... May 6 16:51:28 signer1 ods-enforcerd: opendnssec-enforcer Parent exiting... May 6 16:51:28 signer1 ods-enforcerd: opendnssec-enforcer forked OK... May 6 16:51:28 signer1 ods-enforcerd: opendnssec-enforcer started (version 1.1.0rc2), pid 24419 May 6 16:51:28 signer1 ods-enforcerd: HSM opened successfully. May 6 16:51:28 signer1 ods-enforcerd: Reading config "/etc/opendnssec/conf.xml" May 6 16:51:28 signer1 ods-enforcerd: Reading config schema "/usr/local/share/opendnssec/conf.rng" May 6 16:51:28 signer1 ods-enforcerd: Communication Interval: 3600 May 6 16:51:28 signer1 ods-enforcerd: No DS Submit command supplied May 6 16:51:28 signer1 ods-enforcerd: SQLite database set to: /var/opendnssec/kasp.db May 6 16:51:28 signer1 ods-enforcerd: Log User set to: local0 May 6 16:51:28 signer1 ods-enforcerd: Switched log facility to: local0 May 6 16:51:28 signer1 ods-enforcerd: Connecting to Database... May 6 16:51:28 signer1 ods-enforcerd: Policy default found. May 6 16:51:28 signer1 ods-enforcerd: Key sharing is Off. May 6 16:51:28 signer1 ods-enforcerd: SoftHSM: C_GenerateKeyPair: Key pair generated May 6 16:51:28 signer1 ods-enforcerd: Created KSK size: 2048, alg: 7 with id: eb57c8ad8ca6220932bdf15247351f19 in repository: SoftHSM and database. May 6 16:51:29 signer1 ods-enforcerd: SoftHSM: C_GenerateKeyPair: Key pair generated May 6 16:51:29 signer1 ods-enforcerd: Created KSK size: 2048, alg: 7 with id: 0424219554651888c2d6287eb85a8ebf in repository: SoftHSM and database. May 6 16:51:29 signer1 ods-enforcerd: SoftHSM: C_GenerateKeyPair: Key pair generated May 6 16:51:29 signer1 ods-enforcerd: Created ZSK size: 1024, alg: 7 with id: ee47a4ad43b7db7d3d155781c6a94ee2 in repository: SoftHSM and database. May 6 16:51:29 signer1 ods-enforcerd: SoftHSM: C_GenerateKeyPair: Key pair generated May 6 16:51:30 signer1 ods-enforcerd: Created ZSK size: 1024, alg: 7 with id: 357b7f1f5968385518e734dc3bc9850b in repository: SoftHSM and database. May 6 16:51:30 signer1 ods-enforcerd: zonelist filename set to /etc/opendnssec/zonelist.xml. May 6 16:51:30 signer1 ods-enforcerd: Zone ods found. May 6 16:51:30 signer1 ods-enforcerd: Policy for ods set to default. May 6 16:51:30 signer1 ods-enforcerd: Config will be output to /var/opendnssec/signconf/ods.xml. May 6 16:51:30 signer1 ods-enforcerd: INFO: Promoting ZSK from publish to active as this is the first pass for the zone May 6 16:51:30 signer1 ods-enforcerd: WARNING: Making non-backed up ZSK active, PLEASE make sure that you know the potential problems of using keys which are not recoverable May 6 16:51:30 signer1 ods-signerd: Received command: 'update ods' May 6 16:51:30 signer1 ods-signerd: Scheduling task to sign zone ods at 1273157488.15 with resign time 600 May 6 16:51:30 signer1 ods-signerd: Scheduling task to sign zone ods at 1273157488.15 with resign time 600 May 6 16:51:30 signer1 ods-signerd: Zone action to perform: 3 May 6 16:51:30 signer1 ods-enforcerd: Could not call signer engine May 6 16:51:30 signer1 ods-enforcerd: Will continue: call 'ods-signer update' to manually update zones May 6 16:51:30 signer1 ods-enforcerd: Disconnecting from Database... May 6 16:51:30 signer1 ods-enforcerd: Sleeping for 3600 seconds. May 6 16:51:30 signer1 ods-signerd: Client socket shut down May 6 16:51:30 signer1 ods-signerd: Preprocessing signed zone: ods May 6 16:51:30 signer1 ods-signerd: No signed zone yet May 6 16:51:30 signer1 ods-signerd: Sorting zone: ods May 6 16:51:30 signer1 ods-signerd: Nseccing zone: ods May 6 16:51:30 signer1 ods-signerd: No information yet for key eb57c8ad8ca6220932bdf15247351f19 May 6 16:51:30 signer1 ods-signerd: Generating DNSKEY RR for eb57c8ad8ca6220932bdf15247351f19 May 6 16:51:30 signer1 ods-signerd: Found key eb57c8ad8ca6220932bdf15247351f19 May 6 16:51:30 signer1 ods-signerd: No information yet for key ee47a4ad43b7db7d3d155781c6a94ee2 May 6 16:51:30 signer1 ods-signerd: Generating DNSKEY RR for ee47a4ad43b7db7d3d155781c6a94ee2 May 6 16:51:30 signer1 ods-signerd: Found key ee47a4ad43b7db7d3d155781c6a94ee2 May 6 16:51:30 signer1 ods-signerd: No information yet for key 357b7f1f5968385518e734dc3bc9850b May 6 16:51:30 signer1 ods-signerd: Generating DNSKEY RR for 357b7f1f5968385518e734dc3bc9850b May 6 16:51:30 signer1 ods-signerd: Found key 357b7f1f5968385518e734dc3bc9850b May 6 16:51:30 signer1 ods-signerd: signer stderr: Warning: unable to open /var/opendnssec/tmp/ods.signed: No such file or directory, performing full zone sign May 6 16:51:30 signer1 ods-signerd: signer stderr: signer: number of signatures created: 72 (within a second) May 6 16:51:30 signer1 ods-signerd: Created 72 new signatures May 6 16:51:30 signer1 ods-signerd: Running auditor on zone May 6 16:51:31 signer1 ods-auditor[24448]: Auditor started May 6 16:51:31 signer1 ods-auditor[24448]: Auditor starting on ods May 6 16:51:31 signer1 ods-auditor[24448]: SOA differs : from 1000 to 1273157490 May 6 16:51:31 signer1 ods-auditor[24448]: Auditing ods zone : NSEC3 SIGNED May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns2.label21.ods (0500q2sct81770labmqd07qg58u9nf1h.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns3.label17.ods (06ba5j2jegq44jfntoeaaej09n5jm6a8.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns4.label22.ods (0pgfld8lg2n0uh432q4q6ajd19uistqo.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns4.label14.ods (15igbgmrf4cla49bikads1tfqepnkl5u.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns5.label25.ods (16o5ithnkd0h2076590trkbd21bdf299.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns3.label8.ods (1f458tjkcpk555ms7rgrr9f06nlg5hs0.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns1.label6.ods (1qpoohlmjoveluert9s26og50crurgh5.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns6.label11.ods (1u3jah5m0tnc7kq8usqrkmtf34v3j4pc.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns6.label13.ods (2a4velsj96qmuupcv6i6i9ll1r0ksjm7.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found domain (ns4.label29.ods) whose hash (2s24haq50m31l4br2kcdl5jopp508ef8.ods) is between owner (2m05mung7vu3n9qtdh3vmu0b585pdl2b.ods) and next_hashed (3v5ieqoqrk1qnl5uft39sh4lfuqsegcj.ods)for non-optout NSEC3 May 6 16:51:31 signer1 ods-auditor[24448]: ERROR : expected at ns4.label29.ods (2m05mung7vu3n9qtdh3vmu0b585pdl2b.ods) but found A May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns4.label9.ods (2scoild81jadchp0canf7sh9bedmc49k.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns3.label18.ods (32dbcbfngc06qenimh6s1qij67kbuspt.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns1.label30.ods (34nj4k3fcbtpfnbt7l8bsm5uein0kdaf.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns2.label30.ods (3hs8tvtfbhm8bro055arpsg5ksf3l9ue.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns6.label30.ods (4040ubcevebghn5s7c1ogods8ue8aspm.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns2.label14.ods (439m51qiojp0gb4bbl19em529h6rfu5c.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns5.label4.ods (4ktt7ekohnh68vbpcll4k7di9p2ff84g.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns5.label21.ods (4smlu9arc4vvbd9f8tm2o9ihmufdrv3s.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns4.label32.ods (5985m4vgtrauoies0u5mjfl5frde4r0f.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns3.label14.ods (5kascm0vmrlojane8q7ebv5hjrqi7cgn.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns2.label22.ods (5u4gqjhklhfcr03h1gr5fai2ar9pi0m2.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns3.label4.ods (65urmqflp4r8lsfme7kfpb54b2v5qpma.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns1.label5.ods (6ct35gcbbsgh1j5sahsiisv1eit444u8.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns6.label4.ods (6e15lbkb0gujeh663tht6p8qjpv93cvn.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns3.label22.ods (6u4kt6d91rsh89na32qp0vkg9968ejsa.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns6.label33.ods (6unkss61rm9e7pfp265uliqec0m6o4ll.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for some.ns.at.label7.ods (70mbpd0n8t6s7krbca8eq50d6oiu2vto.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns2.label34.ods (7bq2ansdhctb00up3btett7lr9l2kup8.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label14.ods (7jrlt4kku7nc0bf0amhubr8hv2fkflsb.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label10.ods (7m047daqo4eiujds61s9t1qcr5sv2s1a.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label34.ods (7n8ef6dlqsck2jae9d132uvo3nu2rtjp.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label17.ods (7p0brl3i0vojkb2lm29t0m4mq5f2o90p.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label8.ods (7sbl2laio94tb9rmg367kpj0s3t6n9qo.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label10.ods (7vhhr0nrcufea2b367fti5qqo9cipi8s.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label25.ods (8pu2kvr2c513t606lc9rvv85q38gbvfg.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label9.ods (8r78m0tsfjgfk0vrtbqfpdj978gm0ri1.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label13.ods (8rmmclt46ief0csi6rhvh8miae8281a6.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label6.ods (9517n9q0ohaddftd9jgnb0hi1hoh3hml.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label33.ods (9gfku9lgt9ksp2enes7orlpb9ad581lj.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label21.ods (9l26ehlrjqfv059cipqs30to966l3ioe.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label10.ods (9p5tbff6k4iktts6eipfsfce1ili078j.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label13.ods (adabo19jemopvks1rcju794nq3npccrs.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label32.ods (besq4if7688o3rd1jb4jf7uf7t5r6dj0.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label30.ods (bje9l4b2jjes8v3og0r0r5vvo61jjskp.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label17.ods (bqd6aku51afcg5f3qpfaqu7hr6vqmb67.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label32.ods (buug5ukgu1q7d2dkqhh9iamrsr90ueb9.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label5.ods (cbc50kjttjlegij5e2qdbggcemj2a2e2.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label22.ods (cph6ad3nmj3ub8cjks30a4tj0l53grvr.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label32.ods (crff0fta791en33ajtok91ubv5li3jr5.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label11.ods (cuoilmom3rgbq42e3lnueg0hskq736rj.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label17.ods (d2pn32kv32pou650lfsoo7k4nq7eetn7.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label4.ods (dob2dgf2glfmohdagm2jfpkkgpdigd7i.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label5.ods (dpp69tnld7rc0510k5gtgikfr55m6svm.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label29.ods (e2husvlqtuot3qcltheeavcneopv4djs.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label18.ods (eqk1e45qf6ka8hs5ktkkqu17ll53tai9.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label34.ods (esgtngcslho8q44cljvlvnn0rkdh2359.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label18.ods (f3fih9dn1atrpkihbqollfv684h9r7m9.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label5.ods (fgokfk9ame3hinec6fqcqfmlr49l3jk8.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label25.ods (fldeg2bj2ie18n6mkcvacpoa9or1ta4o.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label8.ods (fq0hp42e1vutbsi72u3oifl6bmkdpvdf.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label13.ods (g406lbpft0po3dgjad4akqu34am8h1va.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found domain (ns4.label18.ods) whose hash (gliqlf2dsr3raeb5q4kp33ehmcfchk6c.ods) is between owner (gispjmo8f6ikpsgl5e3opvh400rd2e2b.ods) and next_hashed (hvggdmjnc74khi6lenmbjl69eijm9vr7.ods)for non-optout NSEC3 May 6 16:51:32 signer1 ods-auditor[24448]: ERROR : expected at ns4.label18.ods (gispjmo8f6ikpsgl5e3opvh400rd2e2b.ods) but found A May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label34.ods (hmng8eakfoo28s8gfb9mok3s719m07cs.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label9.ods (hq00uoahl4fgl473urf6s64e4i83cqt0.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label6.ods (i6jtvrh97r4ejg4a7vskt2npi30mrpe0.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label10.ods (i7q89egv792cqnh20sa7mo7m9e6b1ad1.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label33.ods (igs3bfm23c547spui06dg211ct59jjvq.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label11.ods (iheoe1ihamd13kd7joku1k0lmdv83eh5.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label11.ods (ir6r11kq3j7rlqbsar3o4fpthpdpdp8f.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label6.ods (iu689jck711kug4voj6fbo5ku66hqvv2.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label10.ods (j0ktpagkcatp1p7tak03mt9fs8ae1a42.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label18.ods (j19j0dqa8n0flaq8ofl41ft6sktct9r3.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label25.ods (j6a7n0eth8ensauo4ka3f2vi68vrj04v.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label29.ods (k1ll22l8v1ianvuffc76c83bcvhku9d3.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label9.ods (k3l51jbpc9541tfqn65cuc944quq9gdk.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label21.ods (k68eorm0emlmt5tm4sg83ah826b6sklo.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label6.ods (kioqei1vk5o52jreoubv9atvfc2p4n5d.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label11.ods (l9q0db2vocmvfs30lcibjdcqkf44b890.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label34.ods (lhlsenbs7di6uev2cblram47es6hknfh.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label18.ods (lrd8ujf9rhrphqe4kvufkkch52fos5qg.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label14.ods (lvdskfa9j3ttvfmt2mtu9g0qr0va99nc.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label17.ods (mvldnb4msovvh633nquntp7m4bmql0i4.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label30.ods (n6f0ovehd2jlfgl4ic6hhlmsomt7pgku.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label4.ods (n95hq28vmlqojnmbmrq39j0agav4km5q.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label13.ods (ngu2mf796q6dlniiu9764o8h94r2p7kg.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label4.ods (o2kifr82anr30ov65r9c509lmessse8r.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label10.ods (o2slm445gghnceep94v4f9bjlupl055m.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label29.ods (o3h9kor3tudvj6l8ml3ff7f6jdkr8ln5.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label22.ods (o52tg8p8as7r5p7094vigh8spshfsu72.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label9.ods (o8klvgip3r28v9u2h3h2huetnp2s8cto.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label21.ods (oaapfs5b5smc9t1r97jnm2c6a8tmbktm.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label14.ods (osq29se5r4sl9sfi1sfmkhmu915fmm8r.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label21.ods (ot114galqt8vteg0b49av79k99sbavf8.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label8.ods (pk89iv6jt1p120v1vrr496nu18u1k04v.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label34.ods (pneq2bqqla57r1u9t2rntha7e66bu3nj.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Too much output from auditor - suppressing for rest of run Piece from the /var/opendnssec/tmp/ods.signed: label21.ods. 3600 IN NS ns1.label21.ods. label21.ods. 3600 IN NS ns2.label21.ods. label21.ods. 3600 IN NS ns3.label21.ods. label21.ods. 3600 IN NS ns4.label21.ods. label21.ods. 3600 IN NS ns5.label21.ods. label21.ods. 3600 IN NS ns6.label21.ods. 7kctrj4d4djg7p1trhmv1isaokun2ebi.ods. 1800 IN NSEC3 1 0 5 6730d04f36602116 83us8o3j96vtapffs8ktm6gb3pu6v9t3 NS 7kctrj4d4djg7p1trhmv1isaokun2ebi.ods. 1800 IN RRSIG NSEC3 7 2 1800 20100506170422 20100506144630 59493 ods. KUbwz8kuGHlPeINluX5oW0zz1irsDCKkiufCwyk1SyqkavTpywuovyk1H9Ij92y0DjEth2hV LRB4LCmuMvoT46lb LkvWf7O4hsWWw+4jwbjQE1yeKyArW6n7tOMhy8jl3iIVF2mwPTDZFE7BMgm8FnzfYUQgSBLu iUv9QAIrIxg= ;{id = 59493} Cheers, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Fri May 7 07:14:47 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 07 May 2010 07:14:47 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #132: Cooperation enquery from Feitian, PKI products and security pioneer Message-ID: <068.9b599aaa27009c99028be3ae7c6f4522@kirei.se> #132: Cooperation enquery from Feitian, PKI products and security pioneer -------------------------------------------+-------------------------------- Reporter: Allen Yan | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: Feitian,ePass,Cooperation -------------------------------------------+-------------------------------- == Cooperation enquery from Feitian == Dear all, I'm Allen, the technical consultant from Feitian, China. You can access our company's website :"www.ftsafe.com" to get detailed information. The below is the brief introduction about Feitian. Feitian is from China. It's the leading innovator of smartcard and chip operating system based security technologies and applications. Feitian's USB interfaced Software Protection Dongle, Strong Authentication USB Key, and Smartcard Reader are CE and FCC certified and RoHS compliant. Today, Feitian High performance and Low cost devices and solutions are widely accepted from personal application to enterprise system globally. Feitian is also an global company. Now, Feitian has established branch offices in Japan, Canada and Malaysia.We have our market and customers in Asia, Europe, Oceania, the Americas, the Middle East and so on. We know, OpenDNSSEC is a great project. We're interesting in it. From your latest version, I know some usb key vendor's products have been added to your project, such as SafeNet's eToken. I send this Ticket to enquery the possibility of cooperation between OpenDNSSec and Feitian. We're looking forward to your reply. Thank you very much. You can also contact me by the below ways. Tel: +(86)010-62304466-861 Fax: +(86)010-62304416 Email: guoqing at ftsafe.com -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri May 7 08:17:06 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 07 May 2010 08:17:06 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #132: Cooperation enquery from Feitian, PKI products and security pioneer In-Reply-To: <068.9b599aaa27009c99028be3ae7c6f4522@kirei.se> References: <068.9b599aaa27009c99028be3ae7c6f4522@kirei.se> Message-ID: <077.c3c9f4db98d111de0ddecebc15535d57@kirei.se> #132: Cooperation enquery from Feitian, PKI products and security pioneer -------------------------------------------+-------------------------------- Reporter: Allen Yan | Owner: jakob Type: defect | Status: assigned Priority: major | Component: Unknown Version: trunk | Keywords: Feitian,ePass,Cooperation -------------------------------------------+-------------------------------- Changes (by jakob): * owner: rb => jakob * status: new => assigned -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri May 7 09:10:16 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 07 May 2010 09:10:16 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #132: Cooperation enquery from Feitian, PKI products and security pioneer In-Reply-To: <068.9b599aaa27009c99028be3ae7c6f4522@kirei.se> References: <068.9b599aaa27009c99028be3ae7c6f4522@kirei.se> Message-ID: <077.1869fdc5c38e4a59e89d51037eb2542f@kirei.se> #132: Cooperation enquery from Feitian, PKI products and security pioneer -------------------------------------------+-------------------------------- Reporter: Allen Yan | Owner: jakob Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: fixed Keywords: Feitian,ePass,Cooperation | -------------------------------------------+-------------------------------- Changes (by jakob): * status: assigned => closed * resolution: => fixed Comment: Out-of-band email sent to Feitian, ticket will be closed. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri May 7 15:21:28 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 07 May 2010 15:21:28 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #69: OpenDNSSEC + DLV (isc.org) In-Reply-To: <061.b91b466378c352603e347ab80651e414@kirei.se> References: <061.b91b466378c352603e347ab80651e414@kirei.se> Message-ID: <070.18796a8fc47734ec202212e9e61f0164@kirei.se> #69: OpenDNSSEC + DLV (isc.org) ---------------------------------------+------------------------------------ Reporter: archi.laurent@? | Owner: rb Type: defect | Status: closed Priority: trivial | Component: Unknown Version: trunk | Resolution: worksforme Keywords: OpenDNSSEC + DLV (isc.org) | ---------------------------------------+------------------------------------ Comment(by rosetta stone french): If you want to validate the DNS information from your local zone, then you should configure your DNSKEY in your local resolver. [http://www.jg02.com/rosetta-stone-version-3-french- level-1-2-3-set-p-10.html/] -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Fri May 7 15:23:03 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 07 May 2010 15:23:03 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #69: OpenDNSSEC + DLV (isc.org) In-Reply-To: <061.b91b466378c352603e347ab80651e414@kirei.se> References: <061.b91b466378c352603e347ab80651e414@kirei.se> Message-ID: <070.e64c2dcf9e5a1334a0cfaead134a4807@kirei.se> #69: OpenDNSSEC + DLV (isc.org) ---------------------------------------+------------------------------------ Reporter: archi.laurent@? | Owner: rb Type: defect | Status: closed Priority: trivial | Component: Unknown Version: trunk | Resolution: worksforme Keywords: OpenDNSSEC + DLV (isc.org) | ---------------------------------------+------------------------------------ Comment(by anonymous): If you want to validate the DNS information from your local zone, then you should configure your DNSKEY in your local resolver[http://www.jg02.com /rosetta-stone-version-3-french-level-1-2-3-set-p-10.html/ rosetta stone french] -- Ticket URL: OpenDNSSEC OpenDNSSEC From rickard.bellgrim at iis.se Mon May 10 13:47:49 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 10 May 2010 15:47:49 +0200 Subject: [Opendnssec-develop] Code sprint in Oxford? In-Reply-To: References: Message-ID: Hi We have now found a good date to have the code sprint. Date: 22-23 June Location: Oxford, England (Nominet) (Thanks Matthijs for being able to squeeze in two extra days in your schedule) // Rickard On 29 apr 2010, at 16.49, Rickard Bellgrim wrote: I think we discussed a two-day code sprint, some time in late May or June (to be decided by a doodle poll). I can confirm that Nominet would be happy to host this. Great! And here is the Doodle: http://www.doodle.com/chwhx4f4ztw78twg // Rickard -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Tue May 11 13:39:02 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 11 May 2010 13:39:02 +0000 Subject: [Opendnssec-develop] Enforcer changes Message-ID: Hi there, I'm looking at what I need to do to the enforcer and I'm going to suggest that I sort out key sharing before I restructure the code to try to improve speed. This is the opposite way to pivotal but I think that it is more logical as the changes to fix key sharing will have an impact on the redesign. Basically I will move all the timings into the dnsseckeys table from the keypairs table and shake until it works. Then I can look at indexing tables etc... Note that this means v1.2 will need a different database structure and so will not be backwards compatible, does that seem reasonable to everyone? One question, should we be able to mark an instance of a key in a zone as compromised without marking other uses of that key? I think that marking one should mark them all (this changes which table the "compromisedflag" column goes in). I also need to think about how to keep keys synchronised between zones, or how to not worry about it... When I formulate that question properly I'll ask the list. Cheers, Sion -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Tue May 11 14:12:32 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 11 May 2010 16:12:32 +0200 Subject: [Opendnssec-develop] Meeting tomorrow Message-ID: <8BC7E520-5F88-485C-A7F1-8FBED0AA876E@iis.se> Hi We have a telephone meeting tomorrow. Date: Wednesday 12 May Time: 14:00-15:00 CEST, 13:00-14:00 BST Draft agenda: http://trac.opendnssec.org/wiki/Meetings/Agenda/2010-05-12 // Rickard From rickard.bellgrim at iis.se Tue May 11 14:22:51 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Tue, 11 May 2010 16:22:51 +0200 Subject: [Opendnssec-develop] Enforcer changes In-Reply-To: References: Message-ID: <4D9FC2F2-AC64-44A1-9289-BC3915E8A20B@iis.se> On 11 maj 2010, at 15.39, Sion Lloyd wrote: Hi there, I'm looking at what I need to do to the enforcer and I'm going to suggest that I sort out key sharing before I restructure the code to try to improve speed. This is the opposite way to pivotal but I think that it is more logical as the changes to fix key sharing will have an impact on the redesign. The main goal is to get key sharing and handling of many zones working. Maybe we can throw some stuff out from Pivotal and write new stuff for the Enforcer once we have set our mind on what to do. Basically I will move all the timings into the dnsseckeys table from the keypairs table and shake until it works. Then I can look at indexing tables etc... Note that this means v1.2 will need a different database structure and so will not be backwards compatible, does that seem reasonable to everyone? As long as we can get a migration script. One question, should we be able to mark an instance of a key in a zone as compromised without marking other uses of that key? I think that marking one should mark them all (this changes which table the "compromisedflag" column goes in). If a shared key is compromised, then it is comprised for all of the zones sharing this key. // Rickard -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Tue May 11 15:05:19 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 11 May 2010 15:05:19 +0000 Subject: [Opendnssec-develop] Key sharing question Message-ID: As promised (threatened?) earlier here is my key sharing question. Do we need to do anything about zones drifting apart in terms of when keys are used? Say we have 2 zones sharing keys, but one consistently gets forgotten when it comes to having the ds-seen command issued. In this case we would have the same key in a different state in each zone... No problem here. But, given that the lifetime of the key is determined by the policy, it means that in an extreme case we could eventually see a key being published in one zone at the same time as it is retired from another... Maybe this is not too bad (except for the enforcer trying to keep track of all these keys). However I worry about things like rolling from one HSM to another being difficult and hugely delayed... My other worry is that the current rules for keys are complicated enough and I'd rather be making them simpler than more complicated. Should we look at synchronising keys by reducing the lifetime so that it will retire in all zones at the same time? Sion -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Wed May 12 17:45:47 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Wed, 12 May 2010 17:45:47 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #133: Issues with SOA serial "keep" mode Message-ID: <076.1c853891ecc1bd90390515123a98f990@kirei.se> #133: Issues with SOA serial "keep" mode ---------------------------------------------------+------------------------ Reporter: Anirban Mukherjee | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: trunk | Keywords: ---------------------------------------------------+------------------------ 1) If a sign zone is issued without an increment to the serial number, the error message is of the form "Cannot keep input serial(), output serial is too large" and not "Serial setting is set to 'keep', but input serial has not increased" as one would ideally expect. This seems to be due to the fact that negative and zero return values from compare_serial are being treated equivalently by perform_action in signer/signer_engine/Zone.py and both result in the first error message. 2) When the zone is being signed the very first time '''and''' the serial number in the unsigned file is greater than {{{2^31-1}}}, the same error message ""Cannot keep input serial(), output serial 0 is too large" is seen and the signing is aborted. I think this is caused by the fact that a .serial file is still not present in the working directory (default /var/opendnssec/tmp) and get_output_serial in Zone.py returns zero when a .serial file is not present. In sequence number arithmetic , zero is greater than any x>{{{2^31-1}}}. So compare_serial reports that the output serial of zero is larger than the input serial x from the unsigned file. A crude way to work around this is to make compare_serial say that any serial number is greater than a serial number of zero. But then zero cannot be used as a valid serial number. I have attached a modified Zone.py.modif and Zone.py.orig whose diff may be used to explain the above. There might be other places like find_serial that need to be considered similarly. -- Ticket URL: OpenDNSSEC OpenDNSSEC From AlexD at nominet.org.uk Thu May 13 15:20:35 2010 From: AlexD at nominet.org.uk (Alex Dalitz) Date: Thu, 13 May 2010 15:20:35 +0000 Subject: [Opendnssec-develop] NSEC3ing fails in RC2 In-Reply-To: <850A39016FA57A4887C0AA3C8085F949014D8759@KAEVS1.SIDN.local> Message-ID: Hi - Sorry for the delay in responding; I?ve been away. Can you please try svn revision 3417 and let me know if you still have these issues? Thanks, Alex. On 06/05/2010 16:04, "Rick Zijlker" wrote: Hey all, I can?t figure out what?s going wrong here. As I interpreted the logging, the auditor says there is no NSEC3 record present, but there are. Using default policy, with tighter timings (24H KSK rollover, 8H ZSK rollover, 15min resign etc.) . Can anyone help me out on this one? LOGGING: May 6 16:51:28 signer1 ods-enforcerd: opendnssec-enforcer starting... May 6 16:51:28 signer1 ods-enforcerd: opendnssec-enforcer Parent exiting... May 6 16:51:28 signer1 ods-enforcerd: opendnssec-enforcer forked OK... May 6 16:51:28 signer1 ods-enforcerd: opendnssec-enforcer started (version 1.1.0rc2), pid 24419 May 6 16:51:28 signer1 ods-enforcerd: HSM opened successfully. May 6 16:51:28 signer1 ods-enforcerd: Reading config "/etc/opendnssec/conf.xml" May 6 16:51:28 signer1 ods-enforcerd: Reading config schema "/usr/local/share/opendnssec/conf.rng" May 6 16:51:28 signer1 ods-enforcerd: Communication Interval: 3600 May 6 16:51:28 signer1 ods-enforcerd: No DS Submit command supplied May 6 16:51:28 signer1 ods-enforcerd: SQLite database set to: /var/opendnssec/kasp.db May 6 16:51:28 signer1 ods-enforcerd: Log User set to: local0 May 6 16:51:28 signer1 ods-enforcerd: Switched log facility to: local0 May 6 16:51:28 signer1 ods-enforcerd: Connecting to Database... May 6 16:51:28 signer1 ods-enforcerd: Policy default found. May 6 16:51:28 signer1 ods-enforcerd: Key sharing is Off. May 6 16:51:28 signer1 ods-enforcerd: SoftHSM: C_GenerateKeyPair: Key pair generated May 6 16:51:28 signer1 ods-enforcerd: Created KSK size: 2048, alg: 7 with id: eb57c8ad8ca6220932bdf15247351f19 in repository: SoftHSM and database. May 6 16:51:29 signer1 ods-enforcerd: SoftHSM: C_GenerateKeyPair: Key pair generated May 6 16:51:29 signer1 ods-enforcerd: Created KSK size: 2048, alg: 7 with id: 0424219554651888c2d6287eb85a8ebf in repository: SoftHSM and database. May 6 16:51:29 signer1 ods-enforcerd: SoftHSM: C_GenerateKeyPair: Key pair generated May 6 16:51:29 signer1 ods-enforcerd: Created ZSK size: 1024, alg: 7 with id: ee47a4ad43b7db7d3d155781c6a94ee2 in repository: SoftHSM and database. May 6 16:51:29 signer1 ods-enforcerd: SoftHSM: C_GenerateKeyPair: Key pair generated May 6 16:51:30 signer1 ods-enforcerd: Created ZSK size: 1024, alg: 7 with id: 357b7f1f5968385518e734dc3bc9850b in repository: SoftHSM and database. May 6 16:51:30 signer1 ods-enforcerd: zonelist filename set to /etc/opendnssec/zonelist.xml. May 6 16:51:30 signer1 ods-enforcerd: Zone ods found. May 6 16:51:30 signer1 ods-enforcerd: Policy for ods set to default. May 6 16:51:30 signer1 ods-enforcerd: Config will be output to /var/opendnssec/signconf/ods.xml. May 6 16:51:30 signer1 ods-enforcerd: INFO: Promoting ZSK from publish to active as this is the first pass for the zone May 6 16:51:30 signer1 ods-enforcerd: WARNING: Making non-backed up ZSK active, PLEASE make sure that you know the potential problems of using keys which are not recoverable May 6 16:51:30 signer1 ods-signerd: Received command: 'update ods' May 6 16:51:30 signer1 ods-signerd: Scheduling task to sign zone ods at 1273157488.15 with resign time 600 May 6 16:51:30 signer1 ods-signerd: Scheduling task to sign zone ods at 1273157488.15 with resign time 600 May 6 16:51:30 signer1 ods-signerd: Zone action to perform: 3 May 6 16:51:30 signer1 ods-enforcerd: Could not call signer engine May 6 16:51:30 signer1 ods-enforcerd: Will continue: call 'ods-signer update' to manually update zones May 6 16:51:30 signer1 ods-enforcerd: Disconnecting from Database... May 6 16:51:30 signer1 ods-enforcerd: Sleeping for 3600 seconds. May 6 16:51:30 signer1 ods-signerd: Client socket shut down May 6 16:51:30 signer1 ods-signerd: Preprocessing signed zone: ods May 6 16:51:30 signer1 ods-signerd: No signed zone yet May 6 16:51:30 signer1 ods-signerd: Sorting zone: ods May 6 16:51:30 signer1 ods-signerd: Nseccing zone: ods May 6 16:51:30 signer1 ods-signerd: No information yet for key eb57c8ad8ca6220932bdf15247351f19 May 6 16:51:30 signer1 ods-signerd: Generating DNSKEY RR for eb57c8ad8ca6220932bdf15247351f19 May 6 16:51:30 signer1 ods-signerd: Found key eb57c8ad8ca6220932bdf15247351f19 May 6 16:51:30 signer1 ods-signerd: No information yet for key ee47a4ad43b7db7d3d155781c6a94ee2 May 6 16:51:30 signer1 ods-signerd: Generating DNSKEY RR for ee47a4ad43b7db7d3d155781c6a94ee2 May 6 16:51:30 signer1 ods-signerd: Found key ee47a4ad43b7db7d3d155781c6a94ee2 May 6 16:51:30 signer1 ods-signerd: No information yet for key 357b7f1f5968385518e734dc3bc9850b May 6 16:51:30 signer1 ods-signerd: Generating DNSKEY RR for 357b7f1f5968385518e734dc3bc9850b May 6 16:51:30 signer1 ods-signerd: Found key 357b7f1f5968385518e734dc3bc9850b May 6 16:51:30 signer1 ods-signerd: signer stderr: Warning: unable to open /var/opendnssec/tmp/ods.signed: No such file or directory, performing full zone sign May 6 16:51:30 signer1 ods-signerd: signer stderr: signer: number of signatures created: 72 (within a second) May 6 16:51:30 signer1 ods-signerd: Created 72 new signatures May 6 16:51:30 signer1 ods-signerd: Running auditor on zone May 6 16:51:31 signer1 ods-auditor[24448]: Auditor started May 6 16:51:31 signer1 ods-auditor[24448]: Auditor starting on ods May 6 16:51:31 signer1 ods-auditor[24448]: SOA differs : from 1000 to 1273157490 May 6 16:51:31 signer1 ods-auditor[24448]: Auditing ods zone : NSEC3 SIGNED May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns2.label21.ods (0500q2sct81770labmqd07qg58u9nf1h.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns3.label17.ods (06ba5j2jegq44jfntoeaaej09n5jm6a8.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns4.label22.ods (0pgfld8lg2n0uh432q4q6ajd19uistqo.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns4.label14.ods (15igbgmrf4cla49bikads1tfqepnkl5u.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns5.label25.ods (16o5ithnkd0h2076590trkbd21bdf299.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns3.label8.ods (1f458tjkcpk555ms7rgrr9f06nlg5hs0.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns1.label6.ods (1qpoohlmjoveluert9s26og50crurgh5.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns6.label11.ods (1u3jah5m0tnc7kq8usqrkmtf34v3j4pc.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns6.label13.ods (2a4velsj96qmuupcv6i6i9ll1r0ksjm7.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found domain (ns4.label29.ods) whose hash (2s24haq50m31l4br2kcdl5jopp508ef8.ods) is between owner (2m05mung7vu3n9qtdh3vmu0b585pdl2b.ods) and next_hashed (3v5ieqoqrk1qnl5uft39sh4lfuqsegcj.ods)for non-optout NSEC3 May 6 16:51:31 signer1 ods-auditor[24448]: ERROR : expected at ns4.label29.ods (2m05mung7vu3n9qtdh3vmu0b585pdl2b.ods) but found A May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns4.label9.ods (2scoild81jadchp0canf7sh9bedmc49k.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns3.label18.ods (32dbcbfngc06qenimh6s1qij67kbuspt.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns1.label30.ods (34nj4k3fcbtpfnbt7l8bsm5uein0kdaf.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns2.label30.ods (3hs8tvtfbhm8bro055arpsg5ksf3l9ue.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns6.label30.ods (4040ubcevebghn5s7c1ogods8ue8aspm.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns2.label14.ods (439m51qiojp0gb4bbl19em529h6rfu5c.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns5.label4.ods (4ktt7ekohnh68vbpcll4k7di9p2ff84g.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns5.label21.ods (4smlu9arc4vvbd9f8tm2o9ihmufdrv3s.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns4.label32.ods (5985m4vgtrauoies0u5mjfl5frde4r0f.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns3.label14.ods (5kascm0vmrlojane8q7ebv5hjrqi7cgn.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns2.label22.ods (5u4gqjhklhfcr03h1gr5fai2ar9pi0m2.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns3.label4.ods (65urmqflp4r8lsfme7kfpb54b2v5qpma.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns1.label5.ods (6ct35gcbbsgh1j5sahsiisv1eit444u8.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns6.label4.ods (6e15lbkb0gujeh663tht6p8qjpv93cvn.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns3.label22.ods (6u4kt6d91rsh89na32qp0vkg9968ejsa.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns6.label33.ods (6unkss61rm9e7pfp265uliqec0m6o4ll.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for some.ns.at.label7.ods (70mbpd0n8t6s7krbca8eq50d6oiu2vto.ods) which was not covered by an NSEC3 record May 6 16:51:31 signer1 ods-auditor[24448]: Found RRs for ns2.label34.ods (7bq2ansdhctb00up3btett7lr9l2kup8.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label14.ods (7jrlt4kku7nc0bf0amhubr8hv2fkflsb.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label10.ods (7m047daqo4eiujds61s9t1qcr5sv2s1a.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label34.ods (7n8ef6dlqsck2jae9d132uvo3nu2rtjp.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label17.ods (7p0brl3i0vojkb2lm29t0m4mq5f2o90p.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label8.ods (7sbl2laio94tb9rmg367kpj0s3t6n9qo.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label10.ods (7vhhr0nrcufea2b367fti5qqo9cipi8s.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label25.ods (8pu2kvr2c513t606lc9rvv85q38gbvfg.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label9.ods (8r78m0tsfjgfk0vrtbqfpdj978gm0ri1.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label13.ods (8rmmclt46ief0csi6rhvh8miae8281a6.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label6.ods (9517n9q0ohaddftd9jgnb0hi1hoh3hml.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label33.ods (9gfku9lgt9ksp2enes7orlpb9ad581lj.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label21.ods (9l26ehlrjqfv059cipqs30to966l3ioe.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label10.ods (9p5tbff6k4iktts6eipfsfce1ili078j.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label13.ods (adabo19jemopvks1rcju794nq3npccrs.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label32.ods (besq4if7688o3rd1jb4jf7uf7t5r6dj0.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label30.ods (bje9l4b2jjes8v3og0r0r5vvo61jjskp.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label17.ods (bqd6aku51afcg5f3qpfaqu7hr6vqmb67.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label32.ods (buug5ukgu1q7d2dkqhh9iamrsr90ueb9.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label5.ods (cbc50kjttjlegij5e2qdbggcemj2a2e2.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label22.ods (cph6ad3nmj3ub8cjks30a4tj0l53grvr.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label32.ods (crff0fta791en33ajtok91ubv5li3jr5.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label11.ods (cuoilmom3rgbq42e3lnueg0hskq736rj.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label17.ods (d2pn32kv32pou650lfsoo7k4nq7eetn7.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label4.ods (dob2dgf2glfmohdagm2jfpkkgpdigd7i.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label5.ods (dpp69tnld7rc0510k5gtgikfr55m6svm.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label29.ods (e2husvlqtuot3qcltheeavcneopv4djs.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label18.ods (eqk1e45qf6ka8hs5ktkkqu17ll53tai9.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label34.ods (esgtngcslho8q44cljvlvnn0rkdh2359.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label18.ods (f3fih9dn1atrpkihbqollfv684h9r7m9.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label5.ods (fgokfk9ame3hinec6fqcqfmlr49l3jk8.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label25.ods (fldeg2bj2ie18n6mkcvacpoa9or1ta4o.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label8.ods (fq0hp42e1vutbsi72u3oifl6bmkdpvdf.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label13.ods (g406lbpft0po3dgjad4akqu34am8h1va.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found domain (ns4.label18.ods) whose hash (gliqlf2dsr3raeb5q4kp33ehmcfchk6c.ods) is between owner (gispjmo8f6ikpsgl5e3opvh400rd2e2b.ods) and next_hashed (hvggdmjnc74khi6lenmbjl69eijm9vr7.ods)for non-optout NSEC3 May 6 16:51:32 signer1 ods-auditor[24448]: ERROR : expected at ns4.label18.ods (gispjmo8f6ikpsgl5e3opvh400rd2e2b.ods) but found A May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label34.ods (hmng8eakfoo28s8gfb9mok3s719m07cs.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label9.ods (hq00uoahl4fgl473urf6s64e4i83cqt0.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label6.ods (i6jtvrh97r4ejg4a7vskt2npi30mrpe0.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label10.ods (i7q89egv792cqnh20sa7mo7m9e6b1ad1.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label33.ods (igs3bfm23c547spui06dg211ct59jjvq.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label11.ods (iheoe1ihamd13kd7joku1k0lmdv83eh5.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label11.ods (ir6r11kq3j7rlqbsar3o4fpthpdpdp8f.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label6.ods (iu689jck711kug4voj6fbo5ku66hqvv2.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label10.ods (j0ktpagkcatp1p7tak03mt9fs8ae1a42.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label18.ods (j19j0dqa8n0flaq8ofl41ft6sktct9r3.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label25.ods (j6a7n0eth8ensauo4ka3f2vi68vrj04v.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label29.ods (k1ll22l8v1ianvuffc76c83bcvhku9d3.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label9.ods (k3l51jbpc9541tfqn65cuc944quq9gdk.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label21.ods (k68eorm0emlmt5tm4sg83ah826b6sklo.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label6.ods (kioqei1vk5o52jreoubv9atvfc2p4n5d.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label11.ods (l9q0db2vocmvfs30lcibjdcqkf44b890.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label34.ods (lhlsenbs7di6uev2cblram47es6hknfh.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label18.ods (lrd8ujf9rhrphqe4kvufkkch52fos5qg.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label14.ods (lvdskfa9j3ttvfmt2mtu9g0qr0va99nc.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label17.ods (mvldnb4msovvh633nquntp7m4bmql0i4.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label30.ods (n6f0ovehd2jlfgl4ic6hhlmsomt7pgku.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label4.ods (n95hq28vmlqojnmbmrq39j0agav4km5q.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label13.ods (ngu2mf796q6dlniiu9764o8h94r2p7kg.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label4.ods (o2kifr82anr30ov65r9c509lmessse8r.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label10.ods (o2slm445gghnceep94v4f9bjlupl055m.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns2.label29.ods (o3h9kor3tudvj6l8ml3ff7f6jdkr8ln5.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label22.ods (o52tg8p8as7r5p7094vigh8spshfsu72.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label9.ods (o8klvgip3r28v9u2h3h2huetnp2s8cto.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns4.label21.ods (oaapfs5b5smc9t1r97jnm2c6a8tmbktm.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns5.label14.ods (osq29se5r4sl9sfi1sfmkhmu915fmm8r.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns3.label21.ods (ot114galqt8vteg0b49av79k99sbavf8.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns6.label8.ods (pk89iv6jt1p120v1vrr496nu18u1k04v.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Found RRs for ns1.label34.ods (pneq2bqqla57r1u9t2rntha7e66bu3nj.ods) which was not covered by an NSEC3 record May 6 16:51:32 signer1 ods-auditor[24448]: Too much output from auditor - suppressing for rest of run Piece from the /var/opendnssec/tmp/ods.signed: label21.ods. 3600 IN NS ns1.label21.ods. label21.ods. 3600 IN NS ns2.label21.ods. label21.ods. 3600 IN NS ns3.label21.ods. label21.ods. 3600 IN NS ns4.label21.ods. label21.ods. 3600 IN NS ns5.label21.ods. label21.ods. 3600 IN NS ns6.label21.ods. 7kctrj4d4djg7p1trhmv1isaokun2ebi.ods. 1800 IN NSEC3 1 0 5 6730d04f36602116 83us8o3j96vtapffs8ktm6gb3pu6v9t3 NS 7kctrj4d4djg7p1trhmv1isaokun2ebi.ods. 1800 IN RRSIG NSEC3 7 2 1800 20100506170422 20100506144630 59493 ods. KUbwz8kuGHlPeINluX5oW0zz1irsDCKkiufCwyk1SyqkavTpywuovyk1H9Ij92y0DjEth2hVLRB4LCmuMvoT46lb LkvWf7O4hsWWw+4jwbjQE1yeKyArW6n7tOMhy8jl3iIVF2mwPTDZFE7BMgm8FnzfYUQgSBLuiUv9QAIrIxg= ;{id = 59493} Cheers, Rick ________________________________ _______________________________________________ Opendnssec-develop mailing list Opendnssec-develop at lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.bellgrim at iis.se Fri May 14 10:46:44 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Fri, 14 May 2010 12:46:44 +0200 Subject: [Opendnssec-develop] RC3 Message-ID: Hi The sunet.se bug is now fixed. Are we ready for RC3? I think we are. // Rickard From rick at goldmoney.com Fri May 14 18:41:26 2010 From: rick at goldmoney.com (Rick van Rein) Date: Fri, 14 May 2010 18:41:26 +0000 Subject: [Opendnssec-develop] RC3 In-Reply-To: References: Message-ID: <20100514184126.GB12196@phantom.vanrein.org> Hey, > The sunet.se bug is now fixed. Are we ready for RC3? I think we are. Cool. The only practical limit on the "release early, release often" paradigm is how much effort release egnineers want to put into creating RCi versions. If you see fit, you automatically have my blessing :) -Rick From rick.zijlker at sidn.nl Mon May 17 13:02:40 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Mon, 17 May 2010 13:02:40 +0000 Subject: [Opendnssec-develop] 1.1.0RC3 Compile error on RHEL5.4 Message-ID: Hey, While installing according to the installation instruction I made earlier, I am getting errors at "make": This is the full output of "make" : Making all in libhsm make[1]: Entering directory `/home/rick/opendnssec-1.1.0rc3/libhsm' make all-recursive make[2]: Entering directory `/home/rick/opendnssec-1.1.0rc3/libhsm' Making all in src make[3]: Entering directory `/home/rick/opendnssec-1.1.0rc3/libhsm/src' /bin/sh ../libtool --tag=CC --mode=link gcc -std=c99 -g -O2 -pedantic -Wall -Wextra -dl -version-info 1:1:1 -export-symbols-regex '^hsm_.*' -o libhsm.la -rpath /usr/local/lib libhsm.lo strlcpy.lo strlcat.lo -L/usr/local/lib -lnsl -lcrypto -lcrypto -lldns -lxml2 -lz -lm -ldl libtool: link: rm -fr .libs/libhsm.exp .libs/libhsm.ver libtool: link: /usr/bin/nm -B .libs/libhsm.o .libs/strlcpy.o .libs/strlcat.o | sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | /bin/sed 's/.* //' | sort | uniq > .libs/libhsm.exp libtool: link: /bin/grep -E -e "^hsm_.*" ".libs/libhsm.exp" > ".libs/libhsm.expT" libtool: link: mv -f ".libs/libhsm.expT" ".libs/libhsm.exp" libtool: link: echo "{ global:" > .libs/libhsm.ver libtool: link: cat .libs/libhsm.exp | sed -e "s/\(.*\)/\1;/" >> .libs/libhsm.ver libtool: link: echo "local: *; };" >> .libs/libhsm.ver libtool: link: gcc -shared .libs/libhsm.o .libs/strlcpy.o .libs/strlcat.o -L/usr/local/lib /usr/local/lib/libldns.so -lnsl -lcrypto -lxml2 -lz -lm -ldl -Wl,-soname -Wl,libhsm.so.0 -Wl,-version-script -Wl,.libs/libhsm.ver -o .libs/libhsm.so.0.1.1 /usr/bin/ld: /usr/local/lib/libcrypto.a(md5_one.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libcrypto.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[3]: *** [libhsm.la] Error 1 make[3]: Leaving directory `/home/rick/opendnssec-1.1.0rc3/libhsm/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/rick/opendnssec-1.1.0rc3/libhsm' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/rick/opendnssec-1.1.0rc3/libhsm' make: *** [all-recursive] Error 1 If you need anything else, I'd like to hear it. Cheers, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner-dnssec-trac at kirei.se Mon May 17 14:00:45 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 17 May 2010 14:00:45 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #134: links in http://www.opendnssec.org/documentation/using-opendnssec/ are bad Message-ID: <047.5238354c1acd6ad5c53b405e83714e94@kirei.se> #134: links in http://www.opendnssec.org/documentation/using-opendnssec/ are bad ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: webpage links ----------------------+----------------------------------------------------- Hi, links in the following webpage are bad. They are refering to something like file:///wiki/Signer/Using/Migrating page concerned : http://www.opendnssec.org/documentation/using-opendnssec/ -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon May 17 14:17:47 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 17 May 2010 14:17:47 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #134: links in http://www.opendnssec.org/documentation/using-opendnssec/ are bad In-Reply-To: <047.5238354c1acd6ad5c53b405e83714e94@kirei.se> References: <047.5238354c1acd6ad5c53b405e83714e94@kirei.se> Message-ID: <056.7a49ce95285a5a21d1af3c369255c1e8@kirei.se> #134: links in http://www.opendnssec.org/documentation/using-opendnssec/ are bad ----------------------+----------------------------------------------------- Reporter: anonymous | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: webpage links ----------------------+----------------------------------------------------- Comment(by anonymous): Links concerned are those in the head of the HTML document before the "Installation" section. -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Mon May 17 20:11:04 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Mon, 17 May 2010 20:11:04 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #135: many links broken (points to file:/) Message-ID: <054.51d441acca413ff67ba6d7f914a76aaa@kirei.se> #135: many links broken (points to file:/) -----------------------------+---------------------------------------------- Reporter: fredrik@? | Owner: rb Type: defect | Status: new Priority: major | Component: Unknown Version: trunk | Keywords: -----------------------------+---------------------------------------------- The first 10 or so links in the documentation at http://www.opendnssec.org/documentation/using-opendnssec/ are broken, pointing to file:///... instead of this trac wiki. Among the broken links is the link to "where to report bugs" ... -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue May 18 07:59:29 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 18 May 2010 07:59:29 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #134: links in http://www.opendnssec.org/documentation/using-opendnssec/ are bad In-Reply-To: <047.5238354c1acd6ad5c53b405e83714e94@kirei.se> References: <047.5238354c1acd6ad5c53b405e83714e94@kirei.se> Message-ID: <056.07f8c087537813cd381b25631d0c7e72@kirei.se> #134: links in http://www.opendnssec.org/documentation/using-opendnssec/ are bad --------------------------+------------------------------------------------- Reporter: anonymous | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: fixed Keywords: webpage links | --------------------------+------------------------------------------------- Changes (by pawal): * status: new => closed * resolution: => fixed -- Ticket URL: OpenDNSSEC OpenDNSSEC From owner-dnssec-trac at kirei.se Tue May 18 07:59:47 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Tue, 18 May 2010 07:59:47 -0000 Subject: [Opendnssec-develop] Re: [OpenDNSSEC] #134: links in http://www.opendnssec.org/documentation/using-opendnssec/ are bad In-Reply-To: <047.5238354c1acd6ad5c53b405e83714e94@kirei.se> References: <047.5238354c1acd6ad5c53b405e83714e94@kirei.se> Message-ID: <056.7aa907b8232dc80ba31bf4fa0ee6cac3@kirei.se> #134: links in http://www.opendnssec.org/documentation/using-opendnssec/ are bad --------------------------+------------------------------------------------- Reporter: anonymous | Owner: rb Type: defect | Status: closed Priority: major | Component: Unknown Version: trunk | Resolution: fixed Keywords: webpage links | --------------------------+------------------------------------------------- Comment(by pawal): Thanks, that shouldn't be there. -- Ticket URL: OpenDNSSEC OpenDNSSEC From rick.zijlker at sidn.nl Tue May 18 08:19:05 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Tue, 18 May 2010 08:19:05 +0000 Subject: [Opendnssec-develop] RE: 1.1.0RC3 Compile error on RHEL5.4 In-Reply-To: References: Message-ID: Hey all, This compile error was caused by the installation of a new OpenSSL which caused libcrypto to get out of sync with libhsm. By reinstalling these 2 files the compile was succesfull. Cheers, Rick From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Rick Zijlker Sent: Monday, May 17, 2010 3:03 PM To: Opendnssec-develop at lists.opendnssec.org Subject: [Opendnssec-develop] 1.1.0RC3 Compile error on RHEL5.4 Hey, While installing according to the installation instruction I made earlier, I am getting errors at "make": This is the full output of "make" : Making all in libhsm make[1]: Entering directory `/home/rick/opendnssec-1.1.0rc3/libhsm' make all-recursive make[2]: Entering directory `/home/rick/opendnssec-1.1.0rc3/libhsm' Making all in src make[3]: Entering directory `/home/rick/opendnssec-1.1.0rc3/libhsm/src' /bin/sh ../libtool --tag=CC --mode=link gcc -std=c99 -g -O2 -pedantic -Wall -Wextra -dl -version-info 1:1:1 -export-symbols-regex '^hsm_.*' -o libhsm.la -rpath /usr/local/lib libhsm.lo strlcpy.lo strlcat.lo -L/usr/local/lib -lnsl -lcrypto -lcrypto -lldns -lxml2 -lz -lm -ldl libtool: link: rm -fr .libs/libhsm.exp .libs/libhsm.ver libtool: link: /usr/bin/nm -B .libs/libhsm.o .libs/strlcpy.o .libs/strlcat.o | sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | /bin/sed 's/.* //' | sort | uniq > .libs/libhsm.exp libtool: link: /bin/grep -E -e "^hsm_.*" ".libs/libhsm.exp" > ".libs/libhsm.expT" libtool: link: mv -f ".libs/libhsm.expT" ".libs/libhsm.exp" libtool: link: echo "{ global:" > .libs/libhsm.ver libtool: link: cat .libs/libhsm.exp | sed -e "s/\(.*\)/\1;/" >> .libs/libhsm.ver libtool: link: echo "local: *; };" >> .libs/libhsm.ver libtool: link: gcc -shared .libs/libhsm.o .libs/strlcpy.o .libs/strlcat.o -L/usr/local/lib /usr/local/lib/libldns.so -lnsl -lcrypto -lxml2 -lz -lm -ldl -Wl,-soname -Wl,libhsm.so.0 -Wl,-version-script -Wl,.libs/libhsm.ver -o .libs/libhsm.so.0.1.1 /usr/bin/ld: /usr/local/lib/libcrypto.a(md5_one.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libcrypto.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[3]: *** [libhsm.la] Error 1 make[3]: Leaving directory `/home/rick/opendnssec-1.1.0rc3/libhsm/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/rick/opendnssec-1.1.0rc3/libhsm' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/rick/opendnssec-1.1.0rc3/libhsm' make: *** [all-recursive] Error 1 If you need anything else, I'd like to hear it. Cheers, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick.zijlker at sidn.nl Tue May 18 11:28:10 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Tue, 18 May 2010 11:28:10 +0000 Subject: [Opendnssec-develop] Signconf Message-ID: Hey, Can anyone explain to me when and by whom the signconf of a zone is created? I'm am often running into situations where ODS is waiting/searching for a signconf and often I need to restart or just wait and suddenly it's there. I would like to know in more detail what happens. Thanks, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Tue May 18 12:10:17 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 18 May 2010 12:10:17 +0000 Subject: [Opendnssec-develop] RE: Signconf In-Reply-To: References: Message-ID: The signconfs are generated by the enforcer. The enforcer runs on a scheduled basis as configured in the conf.xml tag.This is actually how long the enforcer will sleep for between runs. If you want the enforcer to wake up out-of-sequence then send it a SIGHUP. Sion ________________________________ From: opendnssec-develop-bounces at lists.opendnssec.org [opendnssec-develop-bounces at lists.opendnssec.org] on behalf of Rick Zijlker [rick.zijlker at sidn.nl] Sent: 18 May 2010 12:28 To: Opendnssec-develop at lists.opendnssec.org Subject: [Opendnssec-develop] Signconf Hey, Can anyone explain to me when and by whom the signconf of a zone is created? I?m am often running into situations where ODS is waiting/searching for a signconf and often I need to restart or just wait and suddenly it?s there. I would like to know in more detail what happens. Thanks, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick.zijlker at sidn.nl Thu May 20 10:00:19 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Thu, 20 May 2010 10:00:19 +0000 Subject: [Opendnssec-develop] RE: Signconf In-Reply-To: References: Message-ID: Hey all, ODS (enforcer) is not generating any new keys where I expect it to do. The situation: I installed RC3 and signed some zones with it. Afterwards stopped the engines and I deleted the content of the following directories: /var/opendnssec/tmp /var/opendnssec/signconf /var/opendnssec/signed Then ran the following commands: Ods-ksmutil zone delete -all Ods-ksmutil update all Ods-ksmutil zone add -z nl Ods-ksmutil update all Zonelist.xml shows only nl with proper paths. "Ods-ksmutil key list" -v shows no keys. This is the way I always start a new test and it always worked out. The only difference is that since RC3 I'm using the Luna SA instead of SoftHSM. The Luna contains 14 keypairs, shown in both ods-hsmutil and the Luna client software. But now it seems ODS (enforcer) is unable to generate keys. There is still no signconf generated for nl. This has been logged exactly like this for about 16 hours now: May 20 11:00:02 signer1 ods-enforcerd: Reading config "/etc/opendnssec/conf.xml" May 20 11:00:02 signer1 ods-enforcerd: Reading config schema "/usr/local/share/opendnssec/conf.rng" May 20 11:00:02 signer1 ods-enforcerd: Communication Interval: 3600 May 20 11:00:02 signer1 ods-enforcerd: No DS Submit command supplied May 20 11:00:02 signer1 ods-enforcerd: SQLite database set to: /var/opendnssec/kasp.db May 20 11:00:02 signer1 ods-enforcerd: Log User set to: local0 May 20 11:00:02 signer1 ods-enforcerd: Switched log facility to: local0 May 20 11:00:02 signer1 ods-enforcerd: Connecting to Database... May 20 11:00:02 signer1 ods-enforcerd: Policy default found. May 20 11:00:02 signer1 ods-enforcerd: Key sharing is Off. May 20 11:00:02 signer1 ods-enforcerd: zonelist filename set to /etc/opendnssec/zonelist.xml. May 20 11:00:02 signer1 ods-enforcerd: Zone nl found. May 20 11:00:02 signer1 ods-enforcerd: Policy for nl set to default. May 20 11:00:02 signer1 ods-enforcerd: Config will be output to /var/opendnssec/signconf/nl.xml. May 20 11:00:02 signer1 ods-enforcerd: Not enough keys to satisfy ksk policy for zone: nl May 20 11:00:02 signer1 ods-enforcerd: ods-enforcerd will create some more keys on its next run May 20 11:00:02 signer1 ods-enforcerd: Error allocating ksks to zone nl May 20 11:00:02 signer1 ods-enforcerd: Disconnecting from Database... May 20 11:00:02 signer1 ods-enforcerd: Sleeping for 3600 seconds. Generating keys in the Luna SA manually works out fine. So it's not full. I couldn't even imagine since there is only 14 keypairs in there right now. I checked the kasp.db and there are traces of the old keys (previous signings) there. Should I try a ods-ksmutil setup? Even though if that works.. in my opinion ODS should be able to continue signing even with some traces of old keys. sqlite> select * from keypairs; 2|f0aa22d8c7d2e84ca9645fabec41de1d|7|2048|1|10|2010-05-17 16:16:35|2010-05-17 22:28:08|2010-05-17 22:28:08|2010-05-18 12:28:08|||1|||2010-05-17 16:19:15|0 6|955506bafe1fbfac64454489f3189667|7|2048|1|10|2010-05-17 16:26:24|2010-05-17 22:28:09|2010-05-17 22:28:09|2010-05-18 12:28:09|||1|||2010-05-17 16:28:00|0 9|d1b3af3e062ed1413c7785df7197228b|7|2048|1|7|2010-05-17 23:28:09|2010-05-17 23:28:10|||||1||||0 10|61a39bbb3dc9287509c7955ffcd8a8d3|7|2048|1|7|2010-05-17 23:28:09|2010-05-17 23:28:10|||||1||||0 11|e5bd27be08ab78c1cebe152b91aa4620|7|1024|1|1|2010-05-18 10:49:37||||||1||||0 12|5ed8fbe39e752e7760fdf4c7580e24dd|7|1024|1|1|2010-05-18 10:49:37||||||1||||0 Keys part of the policy if it might be of any interest: PT1H PT1H PT1H P1D 7 PT24H luna 1 7 PT8H luna 1 Who can help me out or confirm this is an issue? Cheers, Rick From: Sion Lloyd [mailto:sion at nominet.org.uk] Sent: Tuesday, May 18, 2010 2:10 PM To: Rick Zijlker; Opendnssec-develop at lists.opendnssec.org Subject: RE: Signconf The signconfs are generated by the enforcer. The enforcer runs on a scheduled basis as configured in the conf.xml tag.This is actually how long the enforcer will sleep for between runs. If you want the enforcer to wake up out-of-sequence then send it a SIGHUP. Sion ________________________________ From: opendnssec-develop-bounces at lists.opendnssec.org [opendnssec-develop-bounces at lists.opendnssec.org] on behalf of Rick Zijlker [rick.zijlker at sidn.nl] Sent: 18 May 2010 12:28 To: Opendnssec-develop at lists.opendnssec.org Subject: [Opendnssec-develop] Signconf Hey, Can anyone explain to me when and by whom the signconf of a zone is created? I'm am often running into situations where ODS is waiting/searching for a signconf and often I need to restart or just wait and suddenly it's there. I would like to know in more detail what happens. Thanks, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From sion at nominet.org.uk Thu May 20 13:55:27 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Thu, 20 May 2010 14:55:27 +0100 Subject: [Opendnssec-develop] Re: Signconf In-Reply-To: References: Message-ID: <4BF53F4F.4070807@nominet.org.uk> On 20/05/10 11:00, Rick Zijlker wrote: > > Hey all, > > > > ODS (enforcer) is not generating any new keys where I expect it to do. > The situation: > > > > Who can help me out or confirm this is an issue? > > When you say that you can manually create keys, do you mean that you can run ods-ksmutil key generate? If you have not tried that could you do so? Sion -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick.zijlker at sidn.nl Thu May 20 14:27:50 2010 From: rick.zijlker at sidn.nl (Rick Zijlker) Date: Thu, 20 May 2010 14:27:50 +0000 Subject: [Opendnssec-develop] RE: Signconf In-Reply-To: <4BF53F4F.4070807@nominet.org.uk> References: <4BF53F4F.4070807@nominet.org.uk> Message-ID: When you say that you can manually create keys, do you mean that you can run ods-ksmutil key generate? If you have not tried that could you do so? They were manually created with the Luna SA client. When using 'key generate' nothing would be generated. By running 'ods-ksmutil setup' and clearing the HSM of any keys, it is running again. But I don't understand why the keys in the kasp.db weren't purged since they were not in use by any zone. It was also not corresponding to the key list listed by the HSM at that time: [root at signer1 ~]# ods-hsmutil list luna Listing keys in repository: luna 14 keys found. Repository ID Type ---------- -- ---- luna 4cbe955b68f0201299537e51ca391a9f RSA/1024 luna c24a8dd3ab0f409d25c1ffce6eb7acad RSA/2048 luna eb4a7c10f974cdc23edf2bf19bd7925e RSA/2048 luna 404baab6dc60fef4342d1680d8ba700990d55197 RSA/1024 luna 829c9404b3b8b0f504904419691d587de9b34614 RSA/2048 luna 3d1c8641da88ba9e14af9f647d1c69cf RSA/1024 luna c04797e33c6ccc998ecf9e67d1d76a872d643172 RSA/1024 luna cf33fc0fd6758124bf45e375c057631fb722a555 RSA/1024 luna f0aa22d8c7d2e84ca9645fabec41de1d RSA/2048 luna 955506bafe1fbfac64454489f3189667 RSA/2048 luna d1b3af3e062ed1413c7785df7197228b RSA/2048 luna 61a39bbb3dc9287509c7955ffcd8a8d3 RSA/2048 luna e5bd27be08ab78c1cebe152b91aa4620 RSA/1024 luna 5ed8fbe39e752e7760fdf4c7580e24dd RSA/1024 Not all of these keys were present in kasp.db. Also didn't pregenerate any keys when comparing, so I would expect the old keys to be purged. I am gonna do some more testing on this matter and let you know as soon as I have any new findings. Cheers, Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at kirei.se Mon May 24 07:42:56 2010 From: jakob at kirei.se (Jakob Schlyter) Date: Mon, 24 May 2010 09:42:56 +0200 Subject: [Opendnssec-develop] Enforcer changes In-Reply-To: References: Message-ID: On 11 maj 2010, at 15.39, Sion Lloyd wrote: > Basically I will move all the timings into the dnsseckeys table from the keypairs table and shake until it works. Then I can look at indexing tables etc... Note that this means v1.2 will need a different database structure and so will not be backwards compatible, does that seem reasonable to everyone? sure. > One question, should we be able to mark an instance of a key in a zone as compromised without marking other uses of that key? I think that marking one should mark them all (this changes which table the "compromisedflag" column goes in). yes - if a keypair is compromised, all zones utilizing this keypair are affected. jakob From rickard.bellgrim at iis.se Mon May 24 11:51:25 2010 From: rickard.bellgrim at iis.se (Rickard Bellgrim) Date: Mon, 24 May 2010 13:51:25 +0200 Subject: [Opendnssec-develop] Meeting tomorrow Message-ID: <5C7D61CE-3A9E-4CF0-B5CD-19B799F6C319@iis.se> Hi We have a telephone meeting tomorrow. Date: Tuesday 25 May Time: 14:00-15:00 CEST, 13:00-14:00 BST Feel free to add more items to the agenda. http://trac.opendnssec.org/wiki/Meetings/Minutes/2010-05-25 // Rickard From sion at nominet.org.uk Tue May 25 15:20:49 2010 From: sion at nominet.org.uk (Sion Lloyd) Date: Tue, 25 May 2010 16:20:49 +0100 Subject: [Opendnssec-develop] Enforcer update Message-ID: <4BFBEAD1.4080601@nominet.org.uk> Just a quick update on the progress of the new enforcer. I have moved most of the state timestamp fields from the generic table to the table that tracks individual uses of the keys. (Except for generated which will always be the same.) I have also got the unit tests working against the new schema; but this is not saying much as they do not cover enough behaviour to catch most of what is now broken. I think that I will take this opportunity to split out all of the new states into their own timestamp fields; rather than reuse some which is what happens currently. Sion From owner-dnssec-trac at kirei.se Fri May 28 07:41:14 2010 From: owner-dnssec-trac at kirei.se (OpenDNSSEC) Date: Fri, 28 May 2010 07:41:14 -0000 Subject: [Opendnssec-develop] [OpenDNSSEC] #136: signer silently drops weird SOA refresh/retry values Message-ID: <070.f879292d01a84bba9522e991cc2f26d5@kirei.se> #136: signer silently drops weird SOA refresh/retry values ---------------------------------------------+------------------------------ Reporter: Tom Hendrikx | Owner: matthijs Type: defect | Status: new Priority: major | Component: Signer Version: trunk | Keywords: ---------------------------------------------+------------------------------ Today I got notified about very low SOA refresh/retry/etc values in all of my ods-signed zones. dig showed: {{{ dig +short soa whyscream.net @217.149.194.147 a.ns.whyscream.net. admin.whyscream.net. 2010052601 1 30 4 3600 }}} The ods-generated zone file contains these values also: {{{ ; Signed on 2010-05-26 17:53:05 whyscream.net. 3600 IN SOA a.ns.whyscream.net. admin.whyscream.net. 2010052601 1 30 4 3600 }}} When I check the corresponding input file, it contains: {{{ $ORIGIN whyscream.net. @ IN SOA a.ns.whyscream.net. admin.whyscream.net. ( 2010041901 ; serial YYYYMMDD** 1d ; refresh 30m ; retry 4w ; expire 1h ; negative caching TTL ) }}} When I review ods log files, I see no notifications regarding parse errors/issues about these values. They are silently converted, but not correctly ('1h' in input should yield '1h' or '3600' in output, but not '1'). I did some RFC reading but did not find this syntax defined somewhere, so I suspect it to be a widely-supported 'bindism' ;/ Suggested fix would be to either:[[BR]] - support the syntax with w/h/m values in it, and use these (or their converted-to-RFC-compliant) values in the output file[[BR]] - throw an error about non-RFC syntax in input file, and abort signing process -- Ticket URL: OpenDNSSEC OpenDNSSEC