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

[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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: broken
Type: application/octet-stream
Size: 6374 bytes
Desc: broken
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20141006/dadd0c8e/attachment.obj>
-------------- 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: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20141006/dadd0c8e/attachment-0001.obj>
-------------- 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: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20141006/dadd0c8e/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: notbroken
Type: application/octet-stream
Size: 6374 bytes
Desc: notbroken
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20141006/dadd0c8e/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.zone
Type: application/octet-stream
Size: 209 bytes
Desc: test.zone
URL: <http://lists.nlnetlabs.nl/pipermail/ldns-users/attachments/20141006/dadd0c8e/attachment-0004.obj>