[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220919171808.GR9709@brightrain.aerifal.cx>
Date: Mon, 19 Sep 2022 13:18:09 -0400
From: Rich Felker <dalias@...c.org>
To: Luca BRUNO <lucab@...abruno.net>
Cc: musl@...ts.openwall.com
Subject: Re: musl resolver handling of "search ." in /etc/resolv.conf
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 <dalias@...c.org> 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
search continue.
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.
Rich
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.
