Maintained by: NLnet Labs

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

W.C.A. Wijngaards
Mon Feb 28 17:07:05 CET 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Stephane,

On 02/27/2011 02:00 PM, Stephane Bortzmeyer wrote:
> When comparing the results of:
> 
> dig +dnssec @$NS A www.doesnotexistatall-foo-bar.fr
> 
> for BIND and Unbound, I see they both return NXDOMAIN (and rightly
> so), but only Unbound sets the AD bit. I tested both on OARC's
> resolvers <https://www.dns-oarc.net/oarc/services/odvr> and on my own
> local resolvers. .FR is signed with NSEC3+opt-out.

Yes this is what unbound does right now, and we had a similar report
before about no-DS-record-here in an optout-span.

> According to its maintainer, BIND is right
> <https://lists.isc.org/pipermail/bind-users/2009-January/074539.html>.
> 
> My colleague Vincent Levigneron extracted from RFC 5155 two paragraphs
> which seem to indicate that BIND is indeed right:
> 
> 9.2.  Use of the AD Bit
> 
>    The AD bit, as defined by [RFC 4035], MUST NOT be set when returning a
>    response containing a closest (provable) encloser proof in which the
>    NSEC3 RR that covers the "next closer" name has the Opt-Out bit set.
> 
>    This rule is based on what this closest encloser proof actually
>    proves: names that would be covered by the Opt-Out NSEC3 RR may or
>    may not exist as insecure delegations.  As such, not all the data in
>    responses containing such closest encloser proofs will have been
>    cryptographically verified, so the AD bit cannot be set.
> 
> So,is Unbound right/wrong/neutral when setting the AD bit on
> NXDOMAINs?

Well, since below the optout stuff is not signed, it is true that the
NXDOMAIN is not fully secure, so I support the notion that unbound
should not give an AD flag.

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).

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1ryCkACgkQkDLqNwOhpPjKTACgp+tY9ZLikdjTZypa9CDs+sYc
XQEAnjdFyugnaiwDTgKXi8soT3ouUd4/
=SvfZ
-----END PGP SIGNATURE-----