On Wed, May 20, 2020 at 01:59:47PM -0400, Wietse Venema wrote: > Viktor Dukhovni: > > 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. > > My plan is to do an end-to-end test, and to completely ignore the > details of different libc implementations. That will also discover > the case that some intermediate resolver is breaking DNSSEC, leaving > it up to the user to figure out what is broken. > > Current plan: > > After Postfix DANE suport does a DNS lookup that requests DNSSEC > but gets a response with no AD bit set, Postfix will send a probe > query to find out if DNSSEC is working end-to-end. > > In order to make the DNSSEC probe meaningful for DANE support, this > probe MUST use the exact same code path that Postfix uses for DANE, > only with a different query. > > The idea is to make a query for, e.g., the root zone NS records > (configurable), and to look for the AD bit in the response. If that > bit is not set then DNSSEC is not working end-to-end, and any attempt > to use opportunistic or mandatory DANE will result in a warning. > Mandatory DANE would bounce or defer mail as it does now. > > So we're not turning off DANE, just logging that it is unavailable > because something broke DNSSEC end-to-end. > > This won't defend against nasty resolvers that break DNSSEC for a > subset of domains, but you get what you paid for.
This sounds like a great plan that will also mitigate the problem of glibc's AD-stripping by default. FYI I've raised concerns about that again on libc-alpha: https://sourceware.org/pipermail/libc-alpha/2020-May/114174.html > Postfix would still disable the res_nxxx() calls into libc-musl, but > that would be safe, even if those calls end up to get added later. Can you do this via the published __RES API version in resolv.h, rather than probing ldd? The latter is flaky and will get wrong result in various cases I mentioned before. Rich
