From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 31292 invoked from network); 14 Apr 2020 15:53:40 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 14 Apr 2020 15:53:40 -0000 Received: (qmail 18036 invoked by uid 550); 14 Apr 2020 15:53:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 18018 invoked from network); 14 Apr 2020 15:53:37 -0000 Date: Tue, 14 Apr 2020 11:53:24 -0400 From: Rich Felker To: Florian Weimer Cc: Christian , musl@lists.openwall.com Message-ID: <20200414155324.GA11469@brightrain.aerifal.cx> References: <9832107bf742db3145a3960c28cde867f924fe1f.camel@web.de> <4524b127ea99b2d1edcd8c91555a9af21e46a9b3.camel@web.de> <87imi32xj1.fsf@mid.deneb.enyo.de> <20200413163800.GV11469@brightrain.aerifal.cx> <87blnuo0ea.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87blnuo0ea.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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