RES_TRUSTAD, was Trying again on SERVFAIL
vesely at tana.it
Thu Feb 11 18:18:50 UTC 2021
On Thu 11/Feb/2021 17:44:20 +0100 Havard Eidnes wrote:
>> Yeah, by the time it lands on Debian's glibc we'll have grown a long
>> long beard. I'm still missing RES_TRUSTAD...
> Oh, this set me off on a tangent. I hadn't heard of RES_TRUSTAD
> before, so I found
> which under "trust-ad" contains this text:
> If the trust-ad option is active, the stub resolver
> sets the AD bit in outgoing DNS queries (to enable AD
> bit support), [...]
It's similar to dig's man page:
Set [do not set] the AD (authentic data) bit in the query.
This requests the server to return whether all of the answer
and authority sections have all been validated as secure
according to the security policy of the server. AD=1
indicates that all records have been validated as secure and
the answer is not from a OPT-OUT range. AD=0 indicate that
some part of the answer was insecure or not validated. This
bit is set by default.
> I could not get that to rhyme with what I had perceived to be the
> semantics of the AD bit, so I looked up RFC 4035 where near the
> end of section 3 (just before 3.1), I find this text:
> The AD bit is controlled by name servers; a security-aware
> name server MUST ignore the setting of the AD bit in queries.
That's the name server, not the resolver.
> So ... I can't get the glibc behaviour to mesh with the standard
> on this particular point.
It's set in RFC 6840:
5.7. Setting the AD Bit on Queries
The semantics of the Authentic Data (AD) bit in the query were
previously undefined. Section 4.6 of [RFC4035] instructed resolvers
to always clear the AD bit when composing queries.
This document defines setting the AD bit in a query as a signal
indicating that the requester understands and is interested in the
value of the AD bit in the response. This allows a requester to
indicate that it understands the AD bit without also requesting
DNSSEC data via the DO bit.
More information about the bind-users