Wrong NSEC3 for wildcard cname

Timothe Litt litt at acm.org
Thu Nov 20 12:34:35 UTC 2014


On 19-Nov-14 19:03, Graham Clinch wrote:
> Hi Casey & List folks,
>> My apologies - this was actually a bug in DNSViz.  The NSEC3 computation
>> was being performed on the wrong name (the wrong origin was being
>> applied).  It should be fixed now, as shown in:
>>
>> http://dnsviz.net/d/foo.cnametest.lancs.ac.uk/VGzlkA/dnssec/
>> http://dnsviz.net/d/foo.cnametest.palatine.ac.uk/VGzrqg/dnssec/
> Thanks - that's certainly looking less red.  DNSViz is an exceptionally
> useful tool!
>
> The cnametest records were an attempt at simplifying a real issue that's
> been reported to us.
>
> An unsimplified version is cnametest2.lancs.ac.uk (here the RR is
> *.cnametest2 CNAME cnametest2, with an A RR for cnametest2), which (now)
> passes DNSViz, but not Verisign's DNSSEC debugger
> (http://dnssec-debugger.verisignlabs.com/foo.cnametest2.lancs.ac.uk).
>
> I'm more confident that this is a bug in Verisign's debugger, as the
> error is 'No DS records found for cnametest2.lancs.ac.uk in the
> cnametest2.lancs.ac zone' (where's the .uk gone, and why the interest in
> a DS where there's no zone cut?).  Do any Verisign DNSSEC debugger
> maintainers lurk on bind-users?  (The 'Contact Us' link on the page
> looks very corporate and not very useful)
Try the dnssec-deployment mailing list. 
dnssec-deployment at dnssec-deployment.org

> 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?  I'll try to dig (haha!)
> into the delv source tomorrow.  Tested with delv 9.10.0 & 9.10.1.
>
> 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...
>
> I'm attempting to discover more about the validating resolver, but since
> I have no access to it and the reporter is just a user of that resolver,
> odds are not stacked in our favour.
>
>> *snipping the bits where I obviously need to read about
>> NSEC3 again*
> 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.
>
> Regards,
>
> Graham
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20141120/3b13493e/attachment.bin>


More information about the bind-users mailing list