On 2026-09-14 00:06:06 +0700, Max Nikulin wrote:
> On 13/09/2026 4:59 am, Vincent Lefevre wrote:
> > Note that I was not really complaining about the host name resolution
> > to IPv6 addresses; but from their error message, I thought that some
> > utilities (ping, wget...) tried an IPv6 connection without trying
> > IPv4.
>
> I see your point, but I can not support it even despite I experienced
> similar failures in the past (timeouts instead of SERVFAIL and no nscd). I
> think, it is too much to demand from every tool some boilerplate code to
> explain to users what happens. From my point of view, the case is rare and
> it should be enough if search engines give description among top results in
> response to error message text and mention of IPv4.
Note that ssh does the right thing:
ssh: Could not resolve hostname joooj.vinc17.net: Name or service not known
If socket() fails, the tool should not attempt to consider
IPv6 addresses at all.
> > On 2026-09-12 01:09:06 +0700, Max Nikulin wrote:>> In my opinion, it is
> > realm of trade-offs and compromises. Should an
> > > application expect different result on retry if it has got 1 success and 1
> > > error for A and AAAA queries? Sometimes delays and timeouts are annoying
> > > for
> > > users. In other cases reliability is preferred.
> >
> > Here, caching is used locally on the machine (with nscd). This is
> > a cache inconsistency. This is not a question of compromise.
>
> Consider a case when authoritative servers for the zone are down for some
> reason. I would say that there is no point to waste time for repeating
> requests during a minute or two. With cached failures (short-lived entries)
> applications may fail faster.
Again, it is an *inconsistency* issue: the caching daemon has an
IPv4 address for AF_INET, but not for AF_UNSPEC.
Moreover, the issue does not occur for a minute or two, but for
several hours. Normally, the default should be what is given by
nscd.conf, e.g.
negative-time-to-live hosts 20
(this is 20 seconds here).
> > > While errors are rare, their effect is hardly noticeable.
> >
> > When errors are cached for several hours, they are much more noticeable!
>
> I believe that cache entries for negative results should be invalidated
> withing a few minutes and it is bug in nscd if it does not distinguish
> successful and failed queries, so the latter persist for hours.
This is not needed: nscd already has the IPv4 address as seen with
AF_INET, but it does not provide it with AF_UNSPEC, probably due to
an earlier failure. Perhaps it has one entry for AF_INET and one
for AF_UNSPEC, and forgets to make them consistent. This may be
the "cache unification (IPv4 vs. IPv6 vs. AF_UNSPEC) issues" that
https://lists.fedoraproject.org/archives/list/[email protected]/thread/4K634Q3567QMMVJIGXM6I6MOJPOWO6QF/
is mentioning.
> > > However does libc really performs retry when it gets SERVFAIL, not
> > > timeout?
> >
> > There doesn't seem to be any retry (this would be useless anyway
> > in my case).
>
> I am confused. I had impression that you wrote that getaddrinfo always
> return IPv4 addresses for AF_INET argument while dig may fail sometimes. I
> do not see which way it may happen without retries in libc.
I haven't done the same tests with getaddrinfo and with dig.
> Another your statement is that dig succeeds a couple of seconds later, so
> retries may be useful.
But a retry done during the same fraction of second still fails.
BTW, a SERVFAIL is *not* a timeout. It is always obtained immediately.
Some hosts (used for testing with dig) always give a SERVFAIL, but
I suppose that this is because they are misconfigured, or perhaps
no-one is supposed to use them.
> I suggest you to change the bug title to make the issue specific to nscd.
I'm wondering whether this would be redundant: the bug is in the
nscd component, so that's implied.
BTW, following the suggestion of the no-aaaa option done by someone
here, which I then suggested in my ticket[*], a "options no-aaaa" line
has been added to /etc/resolv.conf, and there is no longer any issue.
[*] This workaround is OK for ENS-Lyon since IPv6 is not supported.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
