[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200414155324.GA11469@brightrain.aerifal.cx>
Date: Tue, 14 Apr 2020 11:53:24 -0400
From: Rich Felker <dalias@...c.org>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: Christian <list-christian@....de>, musl@...ts.openwall.com
Subject: Re: Resolver routines, Postfix DNSSEC troubles - how to check
for incompatibilities?
On Tue, Apr 14, 2020 at 11:57:17AM +0200, Florian Weimer wrote:
> * Rich Felker:
>
> > On Mon, Apr 13, 2020 at 05:52:34PM +0200, Florian Weimer wrote:
> >> * Christian:
> >>
> >> > So Viktor did some digging:
> >> >
> >> > "The comment on line 25:
> >> >
> >> > https://github.com/runtimejs/musl-libc/blob/master/include/resolv.h#L25
> >> >
> >> > is not encouraging. It suggests that _res is unused. If so, Postfix
> >> > DNS does not work correctly with this C library. And not just for DANE, since Postfix is also unable to to control RES_DEFNAMES and RES_DNSRCH.
> >>
> >> Are these changes to the RES_DEFNAMES and RES_DNSRCH flags really
> >> necessary? Why doesn't Postfix use res_query (or perhaps res_send) as
> >> appropriate?
> >
> > But to actually answer these questions, modifying the flags is
> > presumably because traditional req_query builds an rfc1035 query or
> > edns query based on these flags derived from from resolv.conf, and
> > Postfix either assumes or wants to support the case where resolv.conf
> > is not already configured for edns, perhaps because it was generated
> > by a dhcp client.
>
> In my comment above, I specifically meant RES_DEFNAMES and RES_DNSRCH.
>
> RES_USE_EDNS0 seems different; I would expect applications to use
> their own DNS libraries if they need to access DNSSEC data and
> non-address record types (where there is no benefit gained form
> integrating with /etc/hosts or other data sources).
Oh. For those it seems to be to suppress search domains, so that when
looking up the MX or TLSA for example.com it doesn't get records for
example.com.searchdomain.
I don't know why they poke at flags in _res rather than just appending
a . to the name, and/or comparting the name in the result to ensure
that it matches.
Also res_query is *documented* not to use search domains. You have to
use res_search if you want them. So the flags would only affect A/AAAA
lookups via getaddrinfo etc. anyway. Maybe that's the case they care
about, but appending . would still solve it, and it's not a DANE
integrity issue anyway since if you contacted the wrong server IP the
certificate/key would not match.
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.
