[Unbound-users] AD bit set for NXDOMAIN but should not?

[David Blacka]

On Mar 1, 2011, at 3:11 AM, W.C.A. Wijngaards wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi David,
> 
> On 03/01/2011 12:52 AM, David Blacka wrote:
>> 
>> On Feb 28, 2011, at 11:07 AM, W.C.A. Wijngaards wrote:
>> 
>>> Example B.1 in RFC5155 is wrong, and it should be changed to have the
>>> optout flag removed from the nextcloser NSEC3
>>> (0p9mhaveqvm6t7vbl5lop2u3t2rp3tom).
>>> 
>>> (with the optout flag set, the example is insecure, and also the
>>> wildcard denial has to be removed).
>> 
>> Where in 5155 does it say that the NXDOMAIN proof is different in the opt-out case?  My memory (and a quick search through 5155) is that only the insecure referral proof is different with Opt-Out.
>> 
>> AFAICT example B.1 is correct.  The examples don't show the AD bit status (they are showing the responses from the authoritative server), but I thought section 9.2 was clear enough.
> 
> Well they are supposed to show 'secure' examples.  And B.1 has optout,
> thus unbound is correct in setting the AD flag on NXDOMAIN with optout.

Appendix B is showing examples.  It doesn't say 'secure' examples.  Just examples using NSEC3.

Again, the examples don't indicate whether or not the AD bit should be set.  None of them show the AD bit.  This is because they aren't responses from a validating resolver, but from an authoritative nameserver (hence the AA bit being set).

According to section 9.2, unbound *isn't* correct -- if the covering NSEC3 RR has the opt-out bit set, you don't set AD.  This doesn't change the proof -- you see the same NSEC3 RRs regardless.

> I think the example might thus be wrong and needs to have no optout.

Huh?

> If you think somehow the example should be for an 'insecure' NXDOMAIN.
> Then it is still wrong because it needs to have the wildcard denial
> removed (right? there can be no wildcard delegations).

No.  There is no separate 'insecure' NXDOMAIN proof.  The only response that is constructed differently due to the opt-out bit is the insecure referral (instead of a matching NSEC3, there is a closest encloser NSEC3 and a NSEC3 covering the next closer name which MUST have the opt-out bit set.)


> Best regards,
>   Wouter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk1sqk0ACgkQkDLqNwOhpPjftACeLxWXvMygze2dYWjOCkBrQ8Fn
> D/MAoJb3p3r6nLsQpdaZTCkF0JHUaI2r
> =fX3g
> -----END PGP SIGNATURE-----

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