On Tue, May 19, 2020 at 07:00:57PM -0400, Viktor Dukhovni wrote: > On Tue, May 19, 2020 at 05:19:26PM -0400, Wietse Venema wrote: > > > > https://git.musl-libc.org/cgit/musl/commit/?id=fd7ec068efd590c0393a612599a4fab9bb0a8633 > > > > I understand that the AD (authentic data) bit now is 'true' if > > DNSSEC validation was successful. Thanks for that. > > > > Meanwhile I'll look into the possibility of a quick runtime check > > whether AD is propagated. It may be missing for reasons that have > > nothing to do with libc-musl. > > But keep in mind that the AD bit (in outgoing queries) is not required > in outgoing queries if the DO bit is instead present in the EDNS OPT RR. > Indeed that's what happens with "old glibc" and BSD libc. We set > RES_USE_DNSSEC and the library sets the DO bit. > > Setting just the AD bit is a recent innovation with new glibc, where we > may/must set RES_TRUST_AD instead, and with future MUSL where > RES_USE_DNSSEC is a NOOP, but the AD bit may be set in res_mkquery(), > which we can perhaps check by inspecting the output of a suitable > res_mkquery() call during initialization. > > For the initialization call be to general, it needs to include detection > and parsing of EDNS OPT psuedo-RRs, with success either if the AD-bit > is set or the DO bit is set.
Indeed, that sounds like a bigger task than I initially expected. > Another option, is to use res_mkquery() + res_send() rather than > res_search(), in which case we can set the AD bit, and not even > bother with RES_USE_DNSSEC|RES_EDNS0. That's exactly what I proposed from the beginning, and it's the patch Alpine is currently testing, though they also plan to patch musl so they may end up not needing it. I think with latest glibc though you'd also need to force the trust-ad flag, or glibc would strip AD from the result. Given how AD interacts with DANE, it seems like stripping it is a really bad idea (disables DANE), and we should probably push for glibc to reconsider doing it at all... Rich
