[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220902080900.0291d2c8@ephyra>
Date: Fri, 2 Sep 2022 08:09:00 +0000
From: Luca BRUNO <lucab@...abruno.net>
To: musl@...ts.openwall.com
Subject: Re: musl resolver handling of "search ." in /etc/resolv.conf
On Thu, 1 Sep 2022 14:01:53 -0400
Rich Felker <dalias@...c.org> wrote:
> > 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.
Yes sorry, poor choice of wording from my side, that was the additional
logic I was hinting to.
For future reference, this bug was observed in the wild due to a
combination of recent systemd (>= v247) and kubernetes (= 1.25.0).
The on-host systemd behavior is on purpose, while the logic on
kubernetes side was not completely expected.
A bugfix for kubernetes is being assembled right now to avoid triggering
this case, see https://github.com/kubernetes/kubernetes/pull/112157.
But the same situation may crop up with other non-kubernetes runtimes,
if they try to blindly forward/merge the "search ." from the host
environment.
Ciao, Luca
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.
