[dns-operations] Any known AD=1 intolerant iterative resolvers?

[Viktor Dukhovni]

On Wed, Apr 15, 2020 at 07:25:30PM +0200, Florian Weimer wrote:

> > Your points are valid in general, but entirely out of scope in the
> > supported case, because the forwarder is a modern resolver on the
> > loopback interface.  But the stub resolver setting AD=1 needs to
> > not encounter breakage also in the unsupported (for Postfix) cases.
> 
> My concern is that given the limitations of the AD flag, there is no
> value in sending it by default, without explicit configuration.  So
> even if it is save to send the flag by default (in the sense that it
> does not increase query failure rates), you can't use the flag in
> responses.  Ergo, there is no incentive to send it by default.
> 
> At least that's what I was thinking while writing my response. 8-)

Now I've seen the Glibc 2.31 change, indeed the "send it by default"
becomes a matter of configuration, rather than a static feature of the
stub resolver implementation.  And ideally the administrator will not
set "trust-ad" when at least one resolver in /etc/resolv.conf is remote

[ Even nearby resolvers are subject to remote UDP/IP source address
  spoofing unless there are appropriate anti-spoofing filters at the
  network border. ]

The AD bit will be either explicitly solicited with "options trust-ad"
set, or else always censored.  This is a potential path forward for musl
libc (in which the present anaemic support for EDNS0, DNSSEC TCP
retries, ... breaks DANE support in at least Postfix and Exim).

So my question about safety of unconditionally setting AD=1 (to then be
actually used only on systems where the resolver is local) does become
more of a curiousity, since musl-libc can instead implement support for
a compatible with Glibc 2.31 "options trust-ad".

Indeed even BSD systems that support RES_USE_DNSSEC should perhaps
consider doing the same.  I'll reach out to the right NetBSD and FreeBSD
folks.  Unless someone has already beaten me to it...

-- 
    Viktor.