[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20200519013734.GL21576@brightrain.aerifal.cx>
Date: Mon, 18 May 2020 21:37:36 -0400
From: Rich Felker <dalias@...c.org>
To: postfix-users@...tfix.org
Cc: musl@...ts.openwall.com
Subject: Re: Outgoing DANE not working
On Tue, Apr 14, 2020 at 05:59:51PM -0400, Viktor Dukhovni wrote:
> > > That RFC was published in 2013. That's long enough ago.
> >
> > We support environments that haven't been touched since 2009 or so,
> > and to a lesser/minimal-support extent ones that haven't been touched
> > since around 2004. Your idea of environments Postfix might be running
> > on musl in is very different from the concept of environments that
> > arbitrary applications binaries linked to musl might be running in.
>
> Nevertheless, the AD bit is on by default in dig and similar tools, with
> no reports of any issues in a long time. Do you see dig fail where MUSL
> libc lookups succeed? I'm asking around the DNS community for any
> evidence of barriers to AD=1, so far nobody knows of any. I'll try to
> find more compelling evidence, but basically tolerating AD=1 (either
> ignoring or acting on it per the 2013 RFC) is *required* resolver
> behaviour.
>
> > So if there's any chance of this breaking there almost certainly needs
> > to be a way to turn it off that works even on static binaries.
>
> Whether and where to place such controls is your call. If novel
> /etc/resolv.conf options are not a problem for statically linked
> binaries using something other than musl-libc, then you could
> have:
>
> options noad ...
>
> 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 know what I find
> from dns-operations, and if possible perhaps a RIPE ATLAS probe,
> assuming they support enabling AD=1.
>
> > > In that case, set the AD bit unconditionally, or provide a documented
> > > mechanism to do so via a suitable configuration file.
> >
> > Putting it in resolv.conf on an options line is probably the best. The
> > main remaining question is just which default to use, and where to
> > apply it (at res_mkquery or at res_send).
>
> Your call.
>
> > > Find me a resolver that fails when the AD bit is set. Stub resolvers
> > > that always set it have been around for some time now.
> >
> > Do you know if the usual Windows, Android, iOS, etc. ones always set
> > it? If so it's almost surely safe to do so and this might not even
> > need to be an option (which would really be my favorite coarse of
> > action -- making it unconditional so there's no new configuration to
> > invent).
>
> Mostly dig, unbound-host, ... Most of the platform C libraries support
> DO=1, which obviates the need for AD=1, so they don't do that, but it is
> nevertheless safe. AD=1 is much cheaper than DO=1, because you get back
> just the AD bit without the excess RRSIG baggage, which is not needed
> when you're not doing your own validation.
I have a proposed solution expected to go upstream in this release
cycle: res_* set AD bit unconditionally in outgoing queries, but the
[backend for the] netdb.h functions clears it after calling
__res_mkquery.
This ensures that even if there are some broken nameservers/networks
still that can't handle AD in queries, the standard, widely-used,
high-level lookup APIs will still work, and at worst res_query breaks.
Note that the netdb.h functions have no use for the AD bit and no way
to pass it back to the caller, so there is no reduction in
functionality by having them clear it.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
