RES_TRUSTAD, was Trying again on SERVFAIL

[Alessandro Vesely]

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
> 
>    https://man7.org/linux/man-pages/man5/resolv.conf.5.html
> 
> 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:

       +[no]adflag
            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.



Best
Ale
--