Wrong NSEC3 for wildcard cname

[Casey Deccio]

On Wed, Nov 19, 2014 at 7:03 PM, Graham Clinch <g.clinch at lancaster.ac.uk>
wrote:

> Thanks - that's certainly looking less red.  DNSViz is an exceptionally
> useful tool!
>
>
Thanks!


> ...
>
> delv +vtrace continues to report "NSEC3 at super-domain" only for
> foo.cnametest2.palatine.ac.uk records, and not for
> foo.cnametest2.lancs.ac.uk.  Is this a similar
> miscalculating-the-owner-name as for DNSViz?


Don't know, but I would guess that this is simply recognizing the fact that
in addition to covering the non-existent name, the NSEC3 record also
happens to correspond to palatine.ac.uk.

I think this might be one of those cases where I should have trusted my
> gut instinct (to blame the validating resolver), but the more I
> investigated the more red and missing lines in output...
>

What version is your validating resolver?  For example, there are some
earlier versions of BIND that required that inclusion of the closest
encloser NSEC3, even though the closest encloser could be derived from the
RRSIG covering the wildcard.  As such, they would fail validation when the
authoritative server didn't send that (normally unnecessary) record.

At the start of the year, I received a piece of wisdom regarding NSEC3
> "It is much harder to understand and debug".  At the time I was sure
> that I could outsmart it.  Maybe not so much now.
>

Join the crowd :)  There is probably a local NSEC3 support group in your
area.

Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20141121/b24f7125/attachment.html>