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












_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to