[Dnssec-deployment] nsec3 and wildcards

[David Blacka]

On Oct 13, 2010, at 6:00 PM, Dave Lawrence wrote:

> Getting some curious validation failures involving wildcards, and
> wondering what other people think of it.
> 
...

> According to my reading of RFC 5155 7.2.6, the additional nsec3 is not
> needed:
> 
>   To this end, the NSEC3 RR that covers the "next closer" name of the
>   immediate ancestor of the wildcard MUST be returned.  It is not
>   necessary to return an NSEC3 RR that matches the closest encloser, as
>   the existence of this closest encloser is proven by the presence of
>   the expanded wildcard in the response.
> 
> Has something superseded this?  Are BIND/CNS being too thorough, or
> Unbound and the authority not thorough enough?

I don't think anything has changed this.  

Normally, when we return the NSEC3 matching the closest encloser, it is because there isn't any other way to determine that.  

In the wildcard case, since you can derive the original wildcard record using information in the RRSIG over the synthesized answer RRSet (and, as part of validating that RRSet, must actually do so), you can figure out what the closest encloser actually is, and thus just need the covering NSEC3 over the next closer name.

--
David Blacka                          <davidb at verisign.com> 
Principal Engineer    VeriSign Platform Product Development

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4272 bytes
Desc: not available
Url : http://dnssec-deployment.org/pipermail/dnssec-deployment/attachments/20101013/b226860b/attachment.bin