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

[Willem Toorop]

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