Date: Wed, 31 Aug 2022 21:32:02 -0400 From: Jeffrey Walton <noloader@...il.com> To: musl@...ts.openwall.com Subject: Re: musl resolver handling of "search ." in /etc/resolv.conf On Wed, Aug 31, 2022 at 7:59 PM Rich Felker <dalias@...c.org> wrote: > > 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 220.127.116.11 > > 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? Forgive my ignorance Rich. What, exactly, does 'search .' mean? Does that mean lookup a single-label hostname in the TLD context? If so, that's not supposed to happen: https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/ . I would reject a 'search .' as malformed. And be careful of systemd and its networking implementation. The systemd folks do some shady things, like stripping a trailing dot from a fqdn when setting a hostname. Stripping that dot means it is no longer fully qualified. Jeff
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.