Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Sep 2022 08:09:00 +0000
From: Luca BRUNO <>
Subject: Re: musl resolver handling of "search ." in /etc/resolv.conf

On Thu, 1 Sep 2022 14:01:53 -0400
Rich Felker <> 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
But the same situation may crop up with other non-kubernetes runtimes,
if they try to blindly forward/merge the "search ." from the host

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.