mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Jeffrey Walton <noloader@gmail.com>
To: musl@lists.openwall.com
Subject: Re: [musl] musl resolver handling of "search ." in /etc/resolv.conf
Date: Wed, 31 Aug 2022 21:32:02 -0400	[thread overview]
Message-ID: <CAH8yC8=ksLJ7gTvu6jN+zeDFbO5DZ5vWMxKBmAfe0qEGBj47Lg@mail.gmail.com> (raw)
In-Reply-To: <20220831235914.GA19125@brightrain.aerifal.cx>

On Wed, Aug 31, 2022 at 7:59 PM Rich Felker <dalias@libc.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 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?

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

  reply	other threads:[~2022-09-01  1:32 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
2022-09-01  1:32   ` Jeffrey Walton [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='CAH8yC8=ksLJ7gTvu6jN+zeDFbO5DZ5vWMxKBmAfe0qEGBj47Lg@mail.gmail.com' \
    --to=noloader@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://git.vuxu.org/mirror/musl/

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).