From willem at nlnetlabs.nl Wed Oct 1 11:03:36 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 01 Oct 2014 13:03:36 +0200 Subject: [ldns-users] [Unbound-users] suggestion for ldan-dane In-Reply-To: <20140930144735.Horde.B2bgqLY10oA-428C6uUmNw4@horde.andreasschulze.de> References: <20140930144735.Horde.B2bgqLY10oA-428C6uUmNw4@horde.andreasschulze.de> Message-ID: <542BDF88.3010009@nlnetlabs.nl> I've chosen 3 0 1 because it is more specific then 3 1 1. More material is processed to asses the validity. Though, I have to admit I use 3 1 1 myself as well because I'm lazy and don't want to roll over TLSA records every time the certificate needs to update. Is "3 1 1" mentioned somewhere in a BCP document somewhere? If so, I'm happy to alter the defaults right away. Actually, I'm happy to change the defaults anyway unless someone is against it... We have a ldns-users list too (CC'ed). I suggest we continue this topic there (if needed). -- Willem Op 30-09-14 om 14:47 schreef A. Schulze: > Hello, > > maybe it's a little bit off topic but I think its interesting anyway. > ldns-dane as part of http://nlnetlabs.nl/projects/ldns/ > allow users to create TLSA records. By default the tool create 3-0-1 > records > > $ ldns-dane -c mail.example.org.pem create mail.example.org 25 > _25._tcp.mail.example.org. 3600 IN TLSA 3 0 1 cafe... > > Today I learned from Viktor Dukhovni it's strongly recommended to use > TLSA Records > type 3-1-1 ( Selector = SubjectPublicKeyInfo ) > > To generate recommended records I have to specify additional arguments: > $ ldns-dane -c mail.example.org.pem create mail.example.org 25 3 1 1 > _25._tcp.mail.example.org. 3600 IN TLSA 3 1 1 beef... > > Would it be possible to modify ldns-dane to simply create > the record in a recommended way? > > Thanks, > Andreas > > _______________________________________________ > Unbound-users mailing list > Unbound-users at unbound.net > http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users From Stuart.Browne at bomboratech.com.au Mon Oct 6 23:13:10 2014 From: Stuart.Browne at bomboratech.com.au (Stuart Browne) Date: Mon, 6 Oct 2014 23:13:10 +0000 Subject: [ldns-users] Strange behaviour - Signing error or ldns-verify-zone error? Message-ID: <3FFD87182AD0AF4FAD60FE8DEF54EDEA28CD767B@MELEX01> Hi, I've been doing some testing recently and came across an inconsistency with regards to verifying a freshly (manually) signed zone. After some mucking about I was able to isolate the behaviour down to about 10 lines of zone file (instead of the 5k where it was originally witnessed). So here goes, trying to explain. Using BIND's dnssec tools to create keys and sign a zone with a wild-card record along with a 2-label deep delegation causes ldns-verify-zone to come out with " Error: there is no NSEC(3) for e.test.zone.". This doesn't occur every time the zone is signed (same arguments and keys every time). Test scenario. Generate new keys, using pseudo random for expediency: [bekar at mgmt1.mel test]$ dnssec-keygen -r /dev/urandom -a RSASHA256 -3 -b 2048 -f KSK test.zone Generating key pair.....+++ ..................................................+++ Ktest.zone.+008+43936 [bekar at mgmt1.mel test]$ dnssec-keygen -r /dev/urandom -a RSASHA256 -3 -b 1280 test.zone Generating key pair............+++++ .......................................................................+++++ Ktest.zone.+008+23094 Sign a small test zone and successfully verify it: [bekar at mgmt1.mel test]$ dnssec-signzone -n 3 -3 693D70A4 -H 1 -A -p -S -N increment -K ./ -o test.zone test.zone Fetching KSK 43936/RSASHA256 from key repository. Fetching ZSK 23094/RSASHA256 from key repository. Verifying the zone using the following algorithms: RSASHA256. Zone signing complete: Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked test.zone.signed [bekar at mgmt1.mel test]$ src/ldns-1.6.17/examples/ldns-verify-zone -k Ktest.zone.+008+23094.key -k Ktest.zone.+008+43936.key < test.zone.signed Zone is verified and complete Sign the same zone file again moments later, attempt verify it again and fail: [bekar at mgmt1.mel test]$ dnssec-signzone -n 3 -3 693D70A4 -H 1 -A -p -S -N increment -K ./ -o test.zone test.zone Fetching KSK 43936/RSASHA256 from key repository. Fetching ZSK 23094/RSASHA256 from key repository. Verifying the zone using the following algorithms: RSASHA256. Zone signing complete: Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked test.zone.signed [bekar at mgmt1.mel test]$ src/ldns-1.6.17/examples/ldns-verify-zone -k Ktest.zone.+008+23094.key -k Ktest.zone.+008+43936.key < test.zone.signed Error: there is no NSEC(3) for e.test.zone. There were errors in the zone This isn't a one-work-one-fail scenario. For this test zone, it succeeded 70-80% of the time. For the larger zone, it failed every time (with more than 4 or more of this error). All keys and zone files are attached. Initial testing was done with an RPM build of ldns from EPEL (on EL6, 1.6.16-2). Hoping it was a minor bug fixed in the more recent version, I manually built 1.6.17 on the same machine and received the same error. Sadly, I'm not much of a programmer, so don't really know where to start looking next to generate a fix or confirm it's the signzone causing the issue. Hopefully someone on the list can help out. STUART BROWNE Senior Unix Administrator, Network Administrator, Database Administrator BOMBORA TECHNOLOGIES Melbourne | Los Angeles P? +61 3 9866 3710? E? stuart.browne at bomboratech.com.au W?bomboratech.com.au Follow us on Twitter The Bombora Technologies group of companies includes AusRegistry, ARI Registry Services, AusRegistry International and ZOAK, and formerly carried the name AusRegistry Group. The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. -------------- next part -------------- A non-text attachment was scrubbed... Name: broken Type: application/octet-stream Size: 6374 bytes Desc: broken URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ktest.zone.+008+23094.key Type: application/octet-stream Size: 471 bytes Desc: Ktest.zone.+008+23094.key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ktest.zone.+008+43936.key Type: application/octet-stream Size: 601 bytes Desc: Ktest.zone.+008+43936.key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: notbroken Type: application/octet-stream Size: 6374 bytes Desc: notbroken URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.zone Type: application/octet-stream Size: 209 bytes Desc: test.zone URL: From willem at nlnetlabs.nl Fri Oct 10 21:46:14 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 10 Oct 2014 23:46:14 +0200 Subject: [ldns-users] Strange behaviour - Signing error or ldns-verify-zone error? In-Reply-To: <3FFD87182AD0AF4FAD60FE8DEF54EDEA28CD767B@MELEX01> References: <3FFD87182AD0AF4FAD60FE8DEF54EDEA28CD767B@MELEX01> Message-ID: <543853A6.3060101@nlnetlabs.nl> Thank you Stuart, The bug is in the order of the presented records with zones that have empty non-terminals derived from insecure delegations in an opt-out zone. When ldns reads such a zone, it keeps a list of NSEC3 RRs that do not match a name yet to be retried afterwards. Unfortunately before those NSEC3s are retried on a fully read in zone, first the empty-non terminals are added. This is not necessary for empty non-terminals derived from insecure delegations in an opt-out zone. This fix (that tries to match left-over NSEC3s before adding empty non-terminals) works for your test zone, and might work for your other (big) zone as well: http://git.nlnetlabs.nl/ldns/commit/?h=develop&id=df647670 It is not the appropriate fix for this issue though. This would still not work for opt-out zones that have empty non-terminals derived from secure records (for which the zone is authoritative) *and* empty non-terminals derived from insecure delegations. A proper fix will follow shortly. Thanks a lot for finding this issue, spending all the time to track it down and to report! Much appreciated! -- Willem Op 07-10-14 om 01:13 schreef Stuart Browne: > Hi, > > I've been doing some testing recently and came across an inconsistency with regards to verifying a freshly (manually) signed zone. After some mucking about I was able to isolate the behaviour down to about 10 lines of zone file (instead of the 5k where it was originally witnessed). > > So here goes, trying to explain. > > Using BIND's dnssec tools to create keys and sign a zone with a wild-card record along with a 2-label deep delegation causes ldns-verify-zone to come out with " Error: there is no NSEC(3) for e.test.zone.". > > This doesn't occur every time the zone is signed (same arguments and keys every time). > > Test scenario. > > Generate new keys, using pseudo random for expediency: > > [bekar at mgmt1.mel test]$ dnssec-keygen -r /dev/urandom -a RSASHA256 -3 -b 2048 -f KSK test.zone > Generating key pair.....+++ ..................................................+++ > Ktest.zone.+008+43936 > [bekar at mgmt1.mel test]$ dnssec-keygen -r /dev/urandom -a RSASHA256 -3 -b 1280 test.zone > Generating key pair............+++++ .......................................................................+++++ > Ktest.zone.+008+23094 > > Sign a small test zone and successfully verify it: > > [bekar at mgmt1.mel test]$ dnssec-signzone -n 3 -3 693D70A4 -H 1 -A -p -S -N increment -K ./ -o test.zone test.zone > Fetching KSK 43936/RSASHA256 from key repository. > Fetching ZSK 23094/RSASHA256 from key repository. > Verifying the zone using the following algorithms: RSASHA256. > Zone signing complete: > Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked > ZSKs: 1 active, 0 stand-by, 0 revoked > test.zone.signed > [bekar at mgmt1.mel test]$ src/ldns-1.6.17/examples/ldns-verify-zone -k Ktest.zone.+008+23094.key -k Ktest.zone.+008+43936.key < test.zone.signed > Zone is verified and complete > > Sign the same zone file again moments later, attempt verify it again and fail: > > [bekar at mgmt1.mel test]$ dnssec-signzone -n 3 -3 693D70A4 -H 1 -A -p -S -N increment -K ./ -o test.zone test.zone > Fetching KSK 43936/RSASHA256 from key repository. > Fetching ZSK 23094/RSASHA256 from key repository. > Verifying the zone using the following algorithms: RSASHA256. > Zone signing complete: > Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked > ZSKs: 1 active, 0 stand-by, 0 revoked > test.zone.signed > [bekar at mgmt1.mel test]$ src/ldns-1.6.17/examples/ldns-verify-zone -k Ktest.zone.+008+23094.key -k Ktest.zone.+008+43936.key < test.zone.signed > Error: there is no NSEC(3) for e.test.zone. > There were errors in the zone > > This isn't a one-work-one-fail scenario. For this test zone, it succeeded 70-80% of the time. For the larger zone, it failed every time (with more than 4 or more of this error). > > All keys and zone files are attached. > > Initial testing was done with an RPM build of ldns from EPEL (on EL6, 1.6.16-2). Hoping it was a minor bug fixed in the more recent version, I manually built 1.6.17 on the same machine and received the same error. > > Sadly, I'm not much of a programmer, so don't really know where to start looking next to generate a fix or confirm it's the signzone causing the issue. Hopefully someone on the list can help out. > > STUART BROWNE > Senior Unix Administrator, Network Administrator, Database Administrator > > BOMBORA TECHNOLOGIES > Melbourne | Los Angeles > P +61 3 9866 3710 > E stuart.browne at bomboratech.com.au > W bomboratech.com.au > Follow us on Twitter > The Bombora Technologies group of companies includes AusRegistry, ARI Registry Services, AusRegistry International and ZOAK, and formerly carried the name AusRegistry Group. > The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. > > > > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > From Ray.Bellis at nominet.org.uk Mon Oct 13 15:41:54 2014 From: Ray.Bellis at nominet.org.uk (Ray Bellis) Date: Mon, 13 Oct 2014 15:41:54 +0000 Subject: [ldns-users] Questions on ldns_dnssec_* functions Message-ID: I have a number of advanced-level questions relating to use of ldns to create a dynamic zone signer: 1. Given an apparently valid ldns_dnssec_zone structure that has had keys added and subsequently signed, I'm using ldns_dnssec_zone_find_rrset() to look for RRs in that zone. This works for normal RRs that do exist in the zone, but apparently not for RRs on a wildcard label. Do I have to handle those separately? 2. if the above call returns NULL I ideally need to return one or more NSEC records proving non-existence of the QTYPE (and/or QNAME). Pointers on functions that would assist in finding the right ones would be useful... 3. Is there a method by which I can add new RRs to an already signed zone and just have ldns update the RRSIGs and the NSEC chain for the new records? It's unclear whether the "special handling" in ldns_dnssec_zone_add_rr() covers this. kind regards, Ray From Stuart.Browne at bomboratech.com.au Mon Oct 13 22:41:40 2014 From: Stuart.Browne at bomboratech.com.au (Stuart Browne) Date: Mon, 13 Oct 2014 22:41:40 +0000 Subject: [ldns-users] Strange behaviour - Signing error or ldns-verify-zone error? In-Reply-To: <543853A6.3060101@nlnetlabs.nl> References: <3FFD87182AD0AF4FAD60FE8DEF54EDEA28CD767B@MELEX01> <543853A6.3060101@nlnetlabs.nl> Message-ID: <3FFD87182AD0AF4FAD60FE8DEF54EDEA28CF2294@MELEX01> Hi, The 'develop' branch patch does indeed fix the issue with the small 'broken' zone file. The 'notbroken' continues to work as well. I tried it on our larger zone file and the original issues are indeed gone. A new issue has popped up which isn't making much sense though. [bekar at mgmt1.mel test]$ ../git/ldns/examples/ldns-verify-zone xxx.xxx.xx.dump original of NSEC3 hashed name could not be found at 5273 As this zone file is the output of a 'dig axfr', I thought possibly that the comment lines and duplicate SOA were the issue so stripped them out; the issue remained but moved line number: [bekar at mgmt1.mel test]$ ../git/ldns/examples/ldns-verify-zone xxx.xxx.xx.dump original of NSEC3 hashed name could not be found at 5266 Trying with the '-k' key files passed as arguments produced the same results. Using the 1.6.17 release of the package, this is the output: [bekar at mgmt1.mel test]$ src/ldns-1.6.17/examples/ldns-verify-zone xxx.xxx.xx.dump Error: there is no NSEC(3) for eee.xxx.xxx.xx. Error: there is no NSEC(3) for hh.xxx.xxx.xx. Error: there is no NSEC(3) for pp.xxx.xxx.xx. Error: there is no NSEC(3) for sss.xxx.xxx.xx. Error: there is no NSEC(3) for uuuuuuuuuuu.xxx.xxx.xx. There were errors in the zone This suggests that the behaviour change isn't quite right. I'll contact you directly with the exact details if desired. STUART BROWNE Senior Unix Administrator, Network Administrator, Database Administrator BOMBORA TECHNOLOGIES Melbourne | Los Angeles P? +61 3 9866 3710? E? stuart.browne at bomboratech.com.au W?bomboratech.com.au Follow us on Twitter The Bombora Technologies group of companies includes AusRegistry, ARI Registry Services, AusRegistry International and ZOAK, and formerly carried the name AusRegistry Group. The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. > -----Original Message----- > From: ldns-users [mailto:ldns-users-bounces at open.nlnetlabs.nl] On Behalf > Of Willem Toorop > Sent: Saturday, 11 October 2014 8:46 AM > To: ldns-users at open.nlnetlabs.nl > Subject: Re: [ldns-users] Strange behaviour - Signing error or ldns- > verify-zone error? > > Thank you Stuart, > > The bug is in the order of the presented records with zones that have > empty non-terminals derived from insecure delegations in an opt-out zone. > > When ldns reads such a zone, it keeps a list of NSEC3 RRs that do not > match a name yet to be retried afterwards. Unfortunately before those > NSEC3s are retried on a fully read in zone, first the empty-non > terminals are added. This is not necessary for empty non-terminals > derived from insecure delegations in an opt-out zone. > > This fix (that tries to match left-over NSEC3s before adding empty > non-terminals) works for your test zone, and might work for your other > (big) zone as well: > > http://git.nlnetlabs.nl/ldns/commit/?h=develop&id=df647670 > > It is not the appropriate fix for this issue though. This would still > not work for opt-out zones that have empty non-terminals derived from > secure records (for which the zone is authoritative) *and* empty > non-terminals derived from insecure delegations. > > A proper fix will follow shortly. > > Thanks a lot for finding this issue, spending all the time to track it > down and to report! Much appreciated! > > -- Willem From Ray.Bellis at nominet.org.uk Wed Oct 15 15:09:11 2014 From: Ray.Bellis at nominet.org.uk (Ray Bellis) Date: Wed, 15 Oct 2014 15:09:11 +0000 Subject: [ldns-users] Questions on ldns_dnssec_* functions In-Reply-To: References: Message-ID: <6CCD8AB9-5F56-4B7C-9A5B-2388750A882F@nominet.org.uk> On 13 Oct 2014, at 16:41, Ray Bellis wrote: > I have a number of advanced-level questions relating to use of ldns to create a dynamic zone signer: > > 1. Given an apparently valid ldns_dnssec_zone structure that has had keys added and subsequently signed, I'm using ldns_dnssec_zone_find_rrset() to look for RRs in that zone. > > This works for normal RRs that do exist in the zone, but apparently not for RRs on a wildcard label. Do I have to handle those separately? > > 2. if the above call returns NULL I ideally need to return one or more NSEC records proving non-existence of the QTYPE (and/or QNAME). Pointers on functions that would assist in finding the right ones would be useful... > > 3. Is there a method by which I can add new RRs to an already signed zone and just have ldns update the RRSIGs and the NSEC chain for the new records? It's unclear whether the "special handling" in ldns_dnssec_zone_add_rr() covers this. FWIW, I?ve solved #2 above (albeit not for wildcards) Having dug into the internals of ldns?s code, rather than use `ldns_dnssec_zone_find_rrset()` I?m now using `ldns_frbtree_find_less_equal()` to find the closest entry to the desired name. The NSEC record can then be found in `((ldns_dnssec_name*)node->data).nsec` and its siblings `.signatures` and `.nsec_signatures` contains the RRSIGs over the original record and the NSECs themselves. Ray From Ray.Bellis at nominet.org.uk Fri Oct 17 10:58:59 2014 From: Ray.Bellis at nominet.org.uk (Ray Bellis) Date: Fri, 17 Oct 2014 10:58:59 +0000 Subject: [ldns-users] Questions on ldns_dnssec_* functions In-Reply-To: <6CCD8AB9-5F56-4B7C-9A5B-2388750A882F@nominet.org.uk> References: <6CCD8AB9-5F56-4B7C-9A5B-2388750A882F@nominet.org.uk> Message-ID: <08DF4C83-3761-4C96-A8A1-E8CF2E49C12C@nominet.org.uk> On 15 Oct 2014, at 16:09, I wrote: > On 13 Oct 2014, at 16:41, I wrote: > >> I have a number of advanced-level questions relating to use of ldns to create a dynamic zone signer: >> >> 1. Given an apparently valid ldns_dnssec_zone structure that has had keys added and subsequently signed, I'm using ldns_dnssec_zone_find_rrset() to look for RRs in that zone. >> >> This works for normal RRs that do exist in the zone, but apparently not for RRs on a wildcard label. Do I have to handle those separately? >> >> 2. if the above call returns NULL I ideally need to return one or more NSEC records proving non-existence of the QTYPE (and/or QNAME). Pointers on functions that would assist in finding the right ones would be useful... >> >> 3. Is there a method by which I can add new RRs to an already signed zone and just have ldns update the RRSIGs and the NSEC chain for the new records? It's unclear whether the "special handling" in ldns_dnssec_zone_add_rr() covers this. > > FWIW, I?ve solved #2 above (albeit not for wildcards) > > Having dug into the internals of ldns?s code, rather than use `ldns_dnssec_zone_find_rrset()` I?m now using `ldns_frbtree_find_less_equal()` to find the closest entry to the desired name. > > The NSEC record can then be found in `((ldns_dnssec_name*)node->data).nsec` and its siblings `.signatures` and `.nsec_signatures` contains the RRSIGs over the original record and the NSECs themselves. I've now solved what I was trying to do without needing #1 or #3 either. However #1 is certainly something that would be useful in LDNS. It seems that most of the zone-related functions in LDNS relate to zone signing and printing, and little (if any) to actually looking up data in a zone. kind regards, Ray From willem at nlnetlabs.nl Tue Oct 21 22:07:51 2014 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 22 Oct 2014 00:07:51 +0200 Subject: [ldns-users] Strange behaviour - Signing error or ldns-verify-zone error? In-Reply-To: <3FFD87182AD0AF4FAD60FE8DEF54EDEA28CF2294@MELEX01> References: <3FFD87182AD0AF4FAD60FE8DEF54EDEA28CD767B@MELEX01> <543853A6.3060101@nlnetlabs.nl> <3FFD87182AD0AF4FAD60FE8DEF54EDEA28CF2294@MELEX01> Message-ID: <5446D937.6010807@nlnetlabs.nl> Hi Stuart, I finally came around creating a proper fix, fitting left over NSEC3s on matching empty-nonterminals. You can find it here: http://git.nlnetlabs.nl/ldns/commit/?h=develop&id=5502a76c This one should work on your bigger zones as well. Thanks for finding the issue, reporting and giving feedback on the earlier patch... and your patience :/ -- Willem Op 14-10-14 om 00:41 schreef Stuart Browne: > Hi, > > The 'develop' branch patch does indeed fix the issue with the small 'broken' zone file. The 'notbroken' continues to work as well. > > I tried it on our larger zone file and the original issues are indeed gone. A new issue has popped up which isn't making much sense though. > > [bekar at mgmt1.mel test]$ ../git/ldns/examples/ldns-verify-zone xxx.xxx.xx.dump > original of NSEC3 hashed name could not be found at 5273 > > As this zone file is the output of a 'dig axfr', I thought possibly that the comment lines and duplicate SOA were the issue so stripped them out; the issue remained but moved line number: > > [bekar at mgmt1.mel test]$ ../git/ldns/examples/ldns-verify-zone xxx.xxx.xx.dump > original of NSEC3 hashed name could not be found at 5266 > > Trying with the '-k' key files passed as arguments produced the same results. > > Using the 1.6.17 release of the package, this is the output: > > [bekar at mgmt1.mel test]$ src/ldns-1.6.17/examples/ldns-verify-zone xxx.xxx.xx.dump > Error: there is no NSEC(3) for eee.xxx.xxx.xx. > Error: there is no NSEC(3) for hh.xxx.xxx.xx. > Error: there is no NSEC(3) for pp.xxx.xxx.xx. > Error: there is no NSEC(3) for sss.xxx.xxx.xx. > Error: there is no NSEC(3) for uuuuuuuuuuu.xxx.xxx.xx. > There were errors in the zone > > This suggests that the behaviour change isn't quite right. > > I'll contact you directly with the exact details if desired. > > STUART BROWNE > Senior Unix Administrator, Network Administrator, Database Administrator > > BOMBORA TECHNOLOGIES > Melbourne | Los Angeles > P +61 3 9866 3710 > E stuart.browne at bomboratech.com.au > W bomboratech.com.au > Follow us on Twitter > The Bombora Technologies group of companies includes AusRegistry, ARI Registry Services, AusRegistry International and ZOAK, and formerly carried the name AusRegistry Group. > The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. > >> -----Original Message----- >> From: ldns-users [mailto:ldns-users-bounces at open.nlnetlabs.nl] On Behalf >> Of Willem Toorop >> Sent: Saturday, 11 October 2014 8:46 AM >> To: ldns-users at open.nlnetlabs.nl >> Subject: Re: [ldns-users] Strange behaviour - Signing error or ldns- >> verify-zone error? >> >> Thank you Stuart, >> >> The bug is in the order of the presented records with zones that have >> empty non-terminals derived from insecure delegations in an opt-out zone. >> >> When ldns reads such a zone, it keeps a list of NSEC3 RRs that do not >> match a name yet to be retried afterwards. Unfortunately before those >> NSEC3s are retried on a fully read in zone, first the empty-non >> terminals are added. This is not necessary for empty non-terminals >> derived from insecure delegations in an opt-out zone. >> >> This fix (that tries to match left-over NSEC3s before adding empty >> non-terminals) works for your test zone, and might work for your other >> (big) zone as well: >> >> http://git.nlnetlabs.nl/ldns/commit/?h=develop&id=df647670 >> >> It is not the appropriate fix for this issue though. This would still >> not work for opt-out zones that have empty non-terminals derived from >> secure records (for which the zone is authoritative) *and* empty >> non-terminals derived from insecure delegations. >> >> A proper fix will follow shortly. >> >> Thanks a lot for finding this issue, spending all the time to track it >> down and to report! Much appreciated! >> >> -- Willem From Stuart.Browne at bomboratech.com.au Tue Oct 21 22:34:54 2014 From: Stuart.Browne at bomboratech.com.au (Stuart Browne) Date: Tue, 21 Oct 2014 22:34:54 +0000 Subject: [ldns-users] Strange behaviour - Signing error or ldns-verify-zone error? In-Reply-To: <5446D937.6010807@nlnetlabs.nl> References: <3FFD87182AD0AF4FAD60FE8DEF54EDEA28CD767B@MELEX01> <543853A6.3060101@nlnetlabs.nl> <3FFD87182AD0AF4FAD60FE8DEF54EDEA28CF2294@MELEX01> <5446D937.6010807@nlnetlabs.nl> Message-ID: <3FFD87182AD0AF4FAD60FE8DEF54EDEA28D627EB@MELEX01> Willem, Many thanks, this seems to have found all the issues I've had and resolved them all: [bekar at mgmt1.mel test]$ ../git/ldns/examples/ldns-verify-zone xxx.xxx.xx.dump Zone is verified and complete [bekar at mgmt1.mel test]$ ../git/ldns/examples/ldns-verify-zone broken Zone is verified and complete [bekar at mgmt1.mel test]$ ../git/ldns/examples/ldns-verify-zone notbroken Zone is verified and complete As a more full test, I ran it over all the signed public zones we have (300+ zones, roughly 44 million records), a number of which showed the same behaviour as the above 'broken' zone, they all came out clean. Let's hear it for xargs and many cpu cores running in parallel! Stuart > -----Original Message----- > From: Willem Toorop [mailto:willem at nlnetlabs.nl] > Sent: Wednesday, 22 October 2014 9:08 AM > To: Stuart Browne; ldns-users at open.nlnetlabs.nl > Subject: Re: [ldns-users] Strange behaviour - Signing error or ldns- > verify-zone error? > > Hi Stuart, > > I finally came around creating a proper fix, fitting left over NSEC3s on > matching empty-nonterminals. You can find it here: > > http://git.nlnetlabs.nl/ldns/commit/?h=develop&id=5502a76c > > This one should work on your bigger zones as well. > Thanks for finding the issue, reporting and giving feedback on the > earlier patch... and your patience :/ > > -- Willem > > Op 14-10-14 om 00:41 schreef Stuart Browne: > > Hi, > > > > The 'develop' branch patch does indeed fix the issue with the small > 'broken' zone file. The 'notbroken' continues to work as well. > > > > I tried it on our larger zone file and the original issues are indeed > gone. A new issue has popped up which isn't making much sense though. > > > > [bekar at mgmt1.mel test]$ ../git/ldns/examples/ldns-verify-zone > xxx.xxx.xx.dump > > original of NSEC3 hashed name could not be found at 5273 > > > > As this zone file is the output of a 'dig axfr', I thought possibly that > the comment lines and duplicate SOA were the issue so stripped them out; > the issue remained but moved line number: > > > > [bekar at mgmt1.mel test]$ ../git/ldns/examples/ldns-verify-zone > xxx.xxx.xx.dump > > original of NSEC3 hashed name could not be found at 5266 > > > > Trying with the '-k' key files passed as arguments produced the same > results. > > > > Using the 1.6.17 release of the package, this is the output: > > > > [bekar at mgmt1.mel test]$ src/ldns-1.6.17/examples/ldns-verify-zone > xxx.xxx.xx.dump > > Error: there is no NSEC(3) for eee.xxx.xxx.xx. > > Error: there is no NSEC(3) for hh.xxx.xxx.xx. > > Error: there is no NSEC(3) for pp.xxx.xxx.xx. > > Error: there is no NSEC(3) for sss.xxx.xxx.xx. > > Error: there is no NSEC(3) for uuuuuuuuuuu.xxx.xxx.xx. > > There were errors in the zone > > > > This suggests that the behaviour change isn't quite right. > > > > I'll contact you directly with the exact details if desired. > > > > STUART BROWNE > > Senior Unix Administrator, Network Administrator, Database Administrator > > > >> -----Original Message----- > >> From: ldns-users [mailto:ldns-users-bounces at open.nlnetlabs.nl] On > Behalf > >> Of Willem Toorop > >> Sent: Saturday, 11 October 2014 8:46 AM > >> To: ldns-users at open.nlnetlabs.nl > >> Subject: Re: [ldns-users] Strange behaviour - Signing error or ldns- > >> verify-zone error? > >> > >> Thank you Stuart, > >> > >> The bug is in the order of the presented records with zones that have > >> empty non-terminals derived from insecure delegations in an opt-out > zone. > >> > >> When ldns reads such a zone, it keeps a list of NSEC3 RRs that do not > >> match a name yet to be retried afterwards. Unfortunately before those > >> NSEC3s are retried on a fully read in zone, first the empty-non > >> terminals are added. This is not necessary for empty non-terminals > >> derived from insecure delegations in an opt-out zone. > >> > >> This fix (that tries to match left-over NSEC3s before adding empty > >> non-terminals) works for your test zone, and might work for your other > >> (big) zone as well: > >> > >> http://git.nlnetlabs.nl/ldns/commit/?h=develop&id=df647670 > >> > >> It is not the appropriate fix for this issue though. This would still > >> not work for opt-out zones that have empty non-terminals derived from > >> secure records (for which the zone is authoritative) *and* empty > >> non-terminals derived from insecure delegations. > >> > >> A proper fix will follow shortly. > >> > >> Thanks a lot for finding this issue, spending all the time to track it > >> down and to report! Much appreciated! > >> > >> -- Willem