On Tue, Apr 14, 2020 at 05:59:51PM -0400, Viktor Dukhovni wrote:
> but if that is incompatible with other stub resolver libraries on the
> same machine, you may need a private musl-specific configuration file.
>
> My money is on this being unnecessary. I'll let [you] know what I find
> from dns-operations, and if possible perhaps a RIPE ATLAS probe,
> assuming they support enabling AD=1.
The first interesting tidbit is:
https://lists.dns-oarc.net/pipermail/dns-operations/2020-April/020098.html
which points out that sufficiently recent glibc supports soliciting and
censoring the AD-bit.
https://gnutoolchain-gerrit.osci.io/r/c/glibc/+/461/3/NEWS
* The DNS stub resolver will optionally send the AD (authenticated data) bit
in queries if the trust-ad option is set via the options directive in
/etc/resolv.conf (or if RES_TRUSTAD is set in _res.options). In this
mode, the AD bit, as provided by the name server, is available to
applications which call res_search and related functions. In the default
mode, the AD bit is not set in queries, and it is automatically cleared in
responses, indicating a lack of DNSSEC validation. (Therefore, the name
servers and the network path to them are treated as untrusted.)
I read this to mean that the new "trust-ad" option, if set, causes the
glibc stub resolver to set AD=1 in queries, but otherwise, causes it to
strip the AD bit from replies.
I don't yet have access to systems with this recent a glibc to confirm
the above, but this is likely relevant to Postfix administrators who
enable DANE. You may need to explicitly add the "trust-ad" option to
your /etc/resolv.conf, while making sure that all the listed nameservers
are local (loopback interface).
--
Viktor.
