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.
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.
Your case, when some DNS server in the chain replies before it gets
response from its parent, is unusual.
Perhaps some RFC contains considerations on cache policy for each
response status. Or there may be discussions in communities around
popular DNS servers.
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.
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.
Another your statement is that dig succeeds a couple of seconds later,
so retries may be useful.
Finally, I figured out that I do not understand exact meaning of
SERVFAIL, so I am in doubts if libc bug #26601 is valid and whether
other servers from resolv.conf should be tried. Next server may get
failure from the same parent DNS server. Sorry, I am not going to dig
deeper now.
I suggest you to change the bug title to make the issue specific to
nscd. Without cache, providing partial result is the best that resolver
can do in the case partial failure.
I can not suggest a test that will reveal if nscd caches negative
results or its replies are based purely on presence of at least one
success for A or AAAA. Earlier I asked for output of getent, but it does
not allow distinguish variants. Likely only source code may answer this
question.
