Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250915155747.GT1827@brightrain.aerifal.cx>
Date: Mon, 15 Sep 2025 11:57:47 -0400
From: Rich Felker <dalias@...c.org>
To: Gal Luspam <galluspam@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: getnameinfo waits timeout with no DNS configured

On Mon, Sep 15, 2025 at 04:44:50PM +0200, Gal Luspam wrote:
> Hi,
> I noticed that on a system without dns configuration, a call to
> getnameinfo() will return only after timeout, even if dns queries sent
> to 127.0.0.1:53 have a prompt "icmp port unreachable" reply.
> This leads for example to the issue of slow output of some iptables
> commands (see https://devnonsense.com/posts/slow-iptables-reverse-dns/
> ). This issue is not showing on systems with glibc.
> Is this behaviour by design? Any hints?

In the general case, it is by design -- if the nameserver gets icmp
unreachable due to network momentarily going down migrating to a new
address, different wifi AP, etc. that's exactly the type of transient
condition you're waiting to get resolved before the timeout window
ends.

The things that seem specific to your case that make the behavior
questionable are that (1) it's a loopback address, that wouldn't be
unreachable for network reasons, but could be momentarily unreachable
while restarting the dns service, and (2) it wasn't explicitly
configured but using default nameserver in absence of a configuration
file.

I wonder if maybe we should only apply the default nameserver when
there is no resolv.conf file. Then, you'd at least be able to specify
"no dns at all" by having an empty resolv.conf. Right now, the default
nameserver is added whenever, after parsing the (possibly nonexistant)
file, the total number of nameservers is 0.

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.