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 10724 invoked from network); 13 Apr 2020 15:29:30 -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; 13 Apr 2020 15:29:29 -0000 Received: (qmail 13806 invoked by uid 550); 13 Apr 2020 15:29:26 -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 13782 invoked from network); 13 Apr 2020 15:29:26 -0000 Date: Mon, 13 Apr 2020 11:29:13 -0400 From: Rich Felker To: Christian Cc: musl@lists.openwall.com Message-ID: <20200413152913.GT11469@brightrain.aerifal.cx> References: <9832107bf742db3145a3960c28cde867f924fe1f.camel@web.de> <4524b127ea99b2d1edcd8c91555a9af21e46a9b3.camel@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4524b127ea99b2d1edcd8c91555a9af21e46a9b3.camel@web.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Resolver routines, Postfix DNSSEC troubles - how to check for incompatibilities? On Mon, Apr 13, 2020 at 01:20:49PM +0200, Christian wrote: > Hi again, > > 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. This is correct. It was probably a really bad idea to offer it at the header level at all, rather than having a compile-time failure if software is attempting to use it to configure the resolver. It's always been intentional that musl's res_* functions are stateless and thread-safe. > 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. > > Indeed searching the github repo for RES_USE_DNSSEC and RES_USE_EDNS0 > finds hits only the header file, and similarly: > > > https://raw.githubusercontent.com/runtimejs/musl-libc/master/src/network/res_state.c > > pretty much rules out support for configurable lookup options." > > and > > "The musl-libc resolver code also includes [...]: > > > https://github.com/runtimejs/musl-libc/blob/master/src/network/__dns.c#L67-L69 > > So not terribly safe if using a remote resolver. Definitely no support > for EDNS(0) or sending the "DO" or "AD" bits in the request. > > Always queries all resolvers in parallel without waiting for a short > timeout from the first one (or use connect(2) for prompt notification of host/port unreachable). > > There is no support for truncated responses or TCP failover, so if a > host has enough IP addresses, some may be dropped, and FcRDNS checks may fail spuriously." > > I guess this all shows the incompatibility. > > Big questions is now: Will/Can this be resolved? The intended usage model for musl's resolver has always been that the stub resolver (which gets static linked into programs if you static link and is therefore non-upgradeable) be minimal and speak only the most basic original DNS protocol (RFC 1035) that's understood by all nameservers. The intended usage model for DNSSEC with this is that you run your DNSSEC-validating nameserver on localhost (or if you want to YOLO it, somewhere on a trusted LAN where you daringly assume nobody can root a random box and use it to spoof DNS replies) and thereby get ServFail if DNSSEC validation fails (which translates into EAI_AGAIN/temporary failure with the higher-level functions) and a trusted result if there's any result at all. So, the intended fix is simply not doing what Postfix is doing, and just making the queries normally, and getting DNSSEC protection if it's configured. However, that's not necessarily immutable policy. Indeed it doesn't let a program alter its behavior based on whether the records looked up were DNSSEC-protected, which presumably Postfix wants to do, since it's required for conforming use of DANE. (Personally I disagree with this requirement and believe it's useful to honor TLSA records even on non-signed domains, but don't expect everyone to just do that.) However I don't know when or how this sort of change would take place. The easy short-term fix to use Postfix unmodified with fully conforming policy is to just link it to a copy (probably static so as not to conflict with system) of BIND's resolver library. The easy short-term fix if you don't care that (or are happy that) TLSA records for unsigned domains would be honored is to just disable (comment-out/#if 0) the code in Postfix that's checking whether the result was signed treat all results as if they were. > Out of what I can understand it makes Postfix with musl pretty much > unusable, at least less secure (not only because of the lib itself, but > as well as security features, like DANE get crippled without noticing). > > Also I am not sure why there are stubs build to "satisfy broken apps"? > An exception would have showed right away that something is not working > and prevented the use. Indeed I think that was a bad idea, and may remove them (the header-level parts, not the ABI symbol _res). If so I'll coordinate with distros first to make sure they have patches ready for any software that will fail to build (and this might uncover bugs in the existing packages that need to be fixed, too). On the other hand if part of the resulting changes end up being addition of res_n* APIs that do use a configuration context, then it can't be removed. Rich