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.
>
> Great. 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.
> 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.)
> 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).
> 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.
> 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.
> To consider improvements in caching strategy you need to document
> patterns of failures you see: query timings, likelihood of errors,
> intervals to get result after failed queries. Perhaps it is
> impossible to implement a cache strategy that is better in *all*
> scenarios.
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.
> Have you find any discussion of nscd design?
I've found
https://lists.fedoraproject.org/archives/list/[email protected]/thread/4K634Q3567QMMVJIGXM6I6MOJPOWO6QF/
(November 2020): "While still maintained within the glibc source tree,
''nscd'' has received less than forty commits in the past three years
and has gathered significant technical debt, and has bugs which are
hard to fix. There are concurrency bugs in the shared mappings, cache
unification (IPv4 vs. IPv6 vs. AF_UNSPEC) issues, and more which would
require significant investment to fix in nscd."
But I'd say that SERVFAIL should not be cached as it may be a temporary
failure.
> 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).
--
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)
