mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <>
To: Dalton Hubble <>
Subject: Re: [musl] musl resolver handling of "search ." in /etc/resolv.conf
Date: Wed, 31 Aug 2022 19:59:15 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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 /bin/ash
> Edit /etc/resolv.conf to the following (not the "." at the end of search):
> ```
> search default.svc.cluster.local .
> nameserver
> options ndots:5
> ```
> ```
> wget
> wget: bad address ''
> ```
> Remove the "." from search and wget will work fine again.
> 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.
> -
> -
> -

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

- 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?


  reply	other threads:[~2022-08-31 23:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-31 17:33 Dalton Hubble
2022-08-31 23:59 ` Rich Felker [this message]
2022-09-01  1:32   ` Jeffrey Walton
2022-09-01 12:45     ` Rich Felker
2022-09-01 16:03       ` Luca BRUNO
2022-09-01 18:01         ` Rich Felker
2022-09-02  8:09           ` Luca BRUNO
2022-09-19 17:18           ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).