[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 19 May 2020 01:44:30 -0400
From: Rich Felker <dalias@...c.org>
To: postfix-users@...tfix.org
Cc: musl@...ts.openwall.com
Subject: Re: Outgoing DANE not working
On Mon, May 18, 2020 at 10:38:14PM -0400, Viktor Dukhovni wrote:
> On Mon, May 18, 2020 at 09:37:36PM -0400, Rich Felker wrote:
>
> > > 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.
>
> This sounds reasonable. Will there be a way for Postfix to detect the
> new library version, so that we don't disable DANE for musl-libc
> versions that do set the AD bit?
I'm really disappointed with the detection, which made things much
worse by producing postfix builds that won't do DANE even after
libc.so is upgraded. It should have just worked after upgrade. The
test is also somewhat broken in that it gets the wrong result if
/bin/sh is static-linked, or if you have postfix built against musl on
a system where /bin/sh is glibc-based, etc. and I don't even know what
happens if you're cross-compiling or if that's even supported at all.
There's not really a "test for versions that do set" by version; I
would expect once the patch is upstream and tested, distros like
Alpine would just apply it to their existing musl package rather than
waiting to upgrade to get it. The only real test is a runtime one,
calling res_mkquery and observing that it's set.
BTW I saw in git master you added an additional musl test of the same
form for the res_n* APIs. A simpler way to detect them is just with
__RES macro in resolv.h, which indicates the supported API version.
AIUI it's provided by all known implementations, though I haven't
actually checked that.
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.
