From: Rich Felker <email@example.com>
To: Luca BRUNO <firstname.lastname@example.org>
Subject: Re: [musl] musl resolver handling of "search ." in /etc/resolv.conf
Date: Mon, 19 Sep 2022 13:18:09 -0400 [thread overview]
Message-ID: <20220919171808.GR9709@brightrain.aerifal.cx> (raw)
On Thu, Sep 01, 2022 at 02:01:53PM -0400, Rich Felker wrote:
> On Thu, Sep 01, 2022 at 04:03:18PM +0000, Luca BRUNO wrote:
> > On Thu, 1 Sep 2022 08:45:12 -0400
> > Rich Felker <email@example.com> wrote:
> > > "search ." by itself is a semantically a no-op. It specifies a single
> > > search domain that's the DNS root, which is exactly what gets queried
> > > with no search at all. systemd is writing this into resolv.conf
> > > because of a glibc "misbehavior" (to put it lightly) where, in the
> > > absence of any search directive, it defaults to searching the domain
> > > of the system hostname (so hostname=foo.example.com would implicitly
> > > search example.com, which is obviously wrong to do, and systemd is
> > > trying to suppress that). But it would also cause failing lookups to
> > > be performed in duplicate, unless there's logic to suppress the final
> > > non-search lookup when root was already searched explicitly.
> > While tracking down this musl bug, I empirically observed from
> > network traces that glibc does apply such de-duplication logic under the
> > same configuration.
> > That is, it performs the root-anchored query in the specified order, and
> > in case of a negative response it does *not* perform the query again as
> > it would otherwise do for the final fallback case.
> Thanks! This is good to know.
> > > > > 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.
> > > > >
> > > > > Anyone care strongly about this one way or another?
> > From my observations, option 1 is consistent with other libc's behavior.
> > But it has the above caveat that it needs additional caching to
> > avoid duplicate root-queries on negative responses.
> > If it isn't too invasive to implement, that would be my preferred one.
> I'm not clear what additional caching you have in mind. AFAICT the
> search loop can just set a flag if it searched root already, and the
> final root query can be skipped if it's reached and the flag is set.
> > Option 2 looks somehow reasonable too. The skewed order would be
> > a bit surprising, but it can be documented and it's unlikely to affect
> > many real-world usages.
> If we go this route, I think the way to document it would be that
> search list entries are strings of one or more label, and that
> malformed ones (including zero-length, over-length, etc.) are ignored.
OK, I've looked at it in more detail now and there are actually
multiple layers to this bug, separate from the search logic itself:
1. res_mkquery does not error out on multiple consecutive dots in the
name, but instead produces a malformed query packet. There are
likely other error conditions it doesn't handle right, too.
2. name_from_dns wrongly returns EAI_NONAME (inhibiting further
search) rather than 0 when res_mkquery produces an error. This
causes entries in the search list that cannot exist as valid domain
names (due to invalid characters, exceeding max total length or
label length, etc.) to break the whole search when they should
conclusively prove nonexistence of the attempted name and let the
With these two fixed, we will "automatically" get the option 2
behavior, since concatenating name+"."+search where search is "." will
produce a malformed name ending in double dot.
If we want to later change this to the option 1 behavior, we can make
the search logic remove final dot itself.
I'll work on patches for the above two issues.
prev parent reply other threads:[~2022-09-19 17:18 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
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 [this message]
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).