[ldns-users] Strange behaviour - Signing error or ldns-verify-zone error?

[Willem Toorop]

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
>