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

[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