On 22/09/2026 1:22 am, Marco Moock wrote:
Am 21.09.26 um 19:00 schrieb Max Nikulin:
On 21/09/2026 5:06 pm, Marco Moock wrote:
It still does not do any DNS lookups, it uses the libraries in listed
in nsswitch.conf.
If they handle SERVFAIL improperly, it is not nscd's fault.
[...]
Consider the following case:
- libnss_dns sends A and AAAA queries due to AF_UNSPEC argument.
- The result for AAAA is success with some addresses.
- "A" fails with some error.
When cache is not involved, trying IPv6 is the best that the calling
application can do. So the result is not simple failure. It is rather
success.
libnss_resolve will try the servers listed in /etc/resolve and stops
when it gets an answer (IIRC positive or negative DNS answer, not
failure). The timeouts can be configured and there is also an option for
round-robin.
I admit, I was not precise trying to generalize SERVFAIL to timeouts.
Let's consider just SERVFAIL. Vincent wrote that negative DNS answer is
immediate (I hope, it is not too far from reality), so there is no
reason to try other DNS servers.
(However there is another opinion:
<https://sourceware.org/bugzilla/show_bug.cgi?id=26601>
"getaddrinfo()/AF_UNSPEC: resolver does not try next DNS if SERVFAIL
received for IPv4")
Notice that Vincent does not have systemd-resolves, so libnss_dns in my
message was intentional.
However this partial result should be cached as negative to retry soon.
I doubt that this is being done. It does not store if a DNS server is
unreachable too, it will try again in the same order and reach timeouts.
systemd-resolve covers that.
Sorry, I have not got what are you trying to say. Systemd-resolved may
be tested if it behaves better than nscd host cache in specific
conditions, but it was not involved.
The issue is that nscd caches for an hour results with some IPv6
addresses and no IPv4 ones due to SERVFAIL in response to the A query.
As a result various tools can not connect the host due to lack of global
IPv6 routing.
You claim that it is not nscd failure. It is possible from my point of
view. You blame a resolver plugin that is actually libnss_dns. My idea
is that the trouble might be caused by plugin design, so plugins have no
chance to do their job better. The latter case is in agreement that "it
is not nscd's fault".
