From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32068 invoked from network); 31 Aug 2022 23:59:32 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 31 Aug 2022 23:59:32 -0000 Received: (qmail 23621 invoked by uid 550); 31 Aug 2022 23:59:29 -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 23580 invoked from network); 31 Aug 2022 23:59:28 -0000 Date: Wed, 31 Aug 2022 19:59:15 -0400 From: Rich Felker To: Dalton Hubble Cc: musl@lists.openwall.com Message-ID: <20220831235914.GA19125@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] musl resolver handling of "search ." in /etc/resolv.conf On Wed, Aug 31, 2022 at 10:33:05AM -0700, Dalton Hubble wrote: > Hey folks, > > I wanted to flag a possible issue with musl handling of DNS "search ." in > /etc/resolv.conf.The easiest way I have to repro and consume musl is > starting an alpine or busybox musl container image. > > podman run -it docker.io/alpine:3.16.2 /bin/ash > > Edit /etc/resolv.conf to the following (not the "." at the end of search): > > ``` > search default.svc.cluster.local . > nameserver 8.8.8.8 > options ndots:5 > ``` > > ``` > wget www.google.com > wget: bad address 'www.google.com' > ``` > > Remove the "." from search and wget will work fine again. > > https://github.com/coreos/fedora-coreos-tracker/issues/1287 has some great > details showing DNS packet capture and a malformed packet. > > Broader context is that systemd and recently Kubernetes start adding > "search ." to resolv.conf in certain scenarios, which seems to break > musl-based resolvers. > - https://github.com/systemd/systemd/pull/17201 > - https://github.com/kubernetes/kubernetes/pull/109441 > - https://github.com/kubernetes/kubernetes/issues/112135 Uhg. It was not forseen that . would be put in the search domains list, and putting it there, especially anywhere but the final position in the list, recreates a bad behavior that we explicitly tried to avoid having in musl. The mechanism of the failure is that malformed DNS queries are sent with a literal . at the end of the name. This probably also happens if the domains in the search list end in dot. Since the queries are malformed, they don't get responses (or ServFail) and then the search cannot continue. This can be fixed by properly stripping the final dot in search entries, and skipping ones that are otherwise malformed. Then we need to decide what to do with the empty (root) search suffix. There are 3 options I see: - Actually support it as a search. This is *bad* behavior, but at least unlike the version of this behavior musl explicitly does not implement, it was explicitly requested by the user. Except that it wasn't, because systemd is just putting it in everyone's resolv.conf.. - Skip it completely. Never search root; wait for the end of the search list and query root as always. - End search on encountering it and go directly to the post-search query at root. If it weren't for systemd and other things creating searches for . without the user's intent, I think the first option would clearly be the most reasonable. It provides a way to explicitly "get back" the functionality musl omits, on an opt-in basis. And maybe systemd is only emitting it as "search .", not putting . in the middle of other search domains? One of the other options might be a more conservative choice to make now, to avoid creating a new "feature" without thinking through what consequences it might have. We could always allow searching root later after there's been time to think through the consequences, rather than rushing is as part of a bugfix. Anyone care strongly about this one way or another? Rich