On 2026-09-08 12:48:34 +0200, Vincent Lefevre wrote: > On 2026-09-08 12:15:48 +0200, Nicolas George wrote: > > > > Anyway, if you suspect nscd, the obvious test is to stop it and > > > > try again. > > > Yes, this could be a temporary workaround > > > > It was not meant as a workaround but as a diagnostics. > > This would be both, if confirmed. SERVFAIL errors do occur in practice, > though normally they should be uncommon. But under no circumstances > a very temporary error somewhere on the network should become a > permanent error on the machine like here.
This might not be directly related to nscd. I found https://sourceware.org/bugzilla/show_bug.cgi?id=27929 (without nscd involved): "When a query for both IPv4 and IPv6 records is performed, glibc's stub resolver will treat ServFail for one of the two as equivalent to nonexistence (NODATA) as long as the other succeeds (and has data? not sure if this happens if it's NODATA)." This seems to be exactly what I can observe (except that in my case, this is cached by nscd, so the issue remains for a few hours). But there are also: * https://lists.fedoraproject.org/archives/list/[email protected]/thread/4K634Q3567QMMVJIGXM6I6MOJPOWO6QF/ (in November 2020), which contains: 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. * https://access.redhat.com/solutions/428273 getaddrinfo() call does not return both IPv6 and IPv4 addresses if nscd is used, unless cache is invalidated manually but I do not have access to the full contents. -- 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)
