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

[Stuart Browne]

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