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.
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?
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.
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).
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.
Where in 5155 does it say that the NXDOMAIN proof is different in
the opt-out case?
I quoted the text at the beginning of the thread. Here it is:
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.
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.
I think the example might thus be wrong and needs to have no optout.
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).
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.
Do you plan to change the behaviour of Unbound? I ask it because we
are developing monitoring tools and they rely on the presence/absence
of the AD bit, that's why we were disturbed by the discrepancy between
BIND and Unbound.
Example B.1 in RFC5155 is wrong, and it should be changed
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.
Do you plan to change the behaviour of Unbound? I ask it because we
are developing monitoring tools and they rely on the presence/absence
of the AD bit, that's why we were disturbed by the discrepancy between
BIND and Unbound.
It seems to me that underneath an optout-span, stuff is insecure, and
thus so must be the NXDOMAIN case we have here. So I am inclined to
change unbound. But I am also looking for guidance because of questions
about 5155.
Example B.1 in RFC5155 is wrong, and it should be changed
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.
But it is confusing:
The RFC 5155 also shows example responses with NSEC3 that matches the
QNAME also don't have the AD bit set. These records don't provide
closest encloser proofs, as far as I understand. As a result, examples,
B.2, B.2.1 and B.6 should have set the AD bit.
So I looked at it some more. It seems to me that the optout example
zone creates some issues in RFC5155 appendix B; it should note that the
optout NSEC3s mean the answer does not get the AD flag, (or not use
optout). We need to follow section 9.2.
The issue is broader than you notice, it also affects the other uses of
NSEC3 as next-closer with optout set. Those become securely-insecure(no
AD flag) too. This means example B.1 (nxdomain) and B.4 (wildcard).
I think unbound should implement this. And the errata (the shortest
one) is that example B.1 and B.4 have no ADflag from the validator; or
if 'the AD flag is left unspecified in the examples' as David says, no
errata is necessary.
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.)
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.
Yes
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.)
Yes, I was wrong about that in the email you quote.