On 10/09/2026 11:46 pm, Vincent Lefevre wrote:
On 2026-09-10 10:00:16 +0700, Max Nikulin wrote:
On 10/09/2026 6:37 am, Vincent Lefevre wrote:
this is because getaddrinfo returns
only the IPv6 address. This is not a question of precedence.
Do you see any benefits in disabling IPv6 on your machine?
Disabling completely, apparently not. Disabling a part of it, such
as SLAAC, yes, because in the past, some machines on the network
sent fake RA advertising. My main personal machine on the network
just has SLAAC disabled for this reason.
Thanks for clearly stating it. I asked, looking at the thread subject,
since host name resolution to IPv6 addresses and IPv6 link configuration
are orthogonal to some degree and it is not immediately obvious.
Have you figured out if changes made in libc to handle the case of
SERVFAIL for A and success for AAAA queries affect nscd? Some
security issues are mentioned in the bug tracker.
I don't know. Note that I've also seen the reverse on the concerned
machine: AF_INET giving the IPv4 address and AF_INET6 giving the
IPv6 address as always, but AF_UNSPEC giving only the IPv4 address.
(Of course, even though this is buggy, it is fine for me.)
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.
The bug reports, you have found, have patches attached. They can give a
hint what source files should be inspected to realize what is current
policy in respect to error handling.
Have you tried to stop nscd to compare if general impression is better?
Nothing has been done yet, AFAIK (I am not the admin, and I can still
see nscd running).
If you can create a VM or a container then it should be enough to test
without changing host settings.
I expect that changing DNS configuration should solve you issue.
There are actually 2 issues:
* Frequent SERVFAIL for new hosts with the 2 nameservers that
are used.
* The nscd behavior, which makes this issue much worse (making
such a failure permament for several hours instead of at most
a few seconds).
I opened tickets for these 2 issues.
If you mean internal helpdesk service then, I suppose, it is the best
possible action to get quick result.
Maybe you are motivated much more than libc developers to find a way to
better handle your specific case.
I don't think that this is a specific case. I suppose that a SERVFAIL
due to network issues can happen everywhere.
While errors are rare, their effect is hardly noticeable. Conditions
when they happen randomly and with high probability are quite specific.
The problem is to convince developers that invested efforts may lead to
significant improvements in important scenarios. I am in doubts if
failing local DNS server is a suitable case to ask for changes. Critical
services during some disaster may be perceived like speculations.
The fact that AF_INET gives the IPv4 address but not AF_UNSPEC
shows that there is a bug. Whatever the caching strategy, such
an inconsistency should never occur.
See above. In the case of AF_INET, there is no success for AAAA, so
retries are more reasonable.
However does libc really performs retry when it gets SERVFAIL, not
timeout? Otherwise AF_INET should sometimes fail.
Have you find any discussion of nscd design?
I've found
(November 2020): "While still maintained within the glibc source tree,
You may ask on the libc developers mailing list (if there is nothing
related in the archives).
But I'd say that SERVFAIL should not be cached as it may be a temporary
failure.
Perhaps it still may be cached for some short interval. Maybe for the
caching layer currently the result looks like a success since there are
known IPv6 (or vice versa IPv4) addresses that may be stored. The
question is whether partial success is handled as a special case (Or it
is not necessary since there is no separate cache for AF_UNSPEC and
results are derived from AF_INET and AF_INET6 caches).
Another question is whether it is reasonable to invest efforts into
suppressing AAAA queries completely at the libc level when IPv6 is
disabled.
This is probably not the way the nscd issue should be fixed (it is
not even sure that it fixes aything, and it wouldn't fix anything
when IPv6 isn't disabled but doesn't work).
Again, if you are saying that without AAAA query resolver reliably gets
IPv4 addresses, it might be an approach. By the way, resolv.conf(5):
options
no-aaaa (since glibc 2.36)
On 10/09/2026 6:37 am, Vincent Lefevre wrote:
On 2026-09-09 23:01:00 +0700, Max Nikulin wrote:
When inspecting behavior of DNS servers, I suggest to suppress retries when
you invoke dig.
It seems that this doesn't really matter. Even +retry=100 can fail:
I figured out that when I faced a similar issue with ISP DNS servers,
there were up to 25-50% timeouts, so retry count was important. In your
case the issue is 1 level up: "your" DNS server works but it is unable
to reach parent resolvers.
