On a machine without IPv6 support (IPv6 disabled in the kernel,
and no IPv6 addresses), how to prevent programs from using IPv6
by default?
So, if you want to reproduce the issue, set up a network
where DNS requests to the nameservers in /etc/resolv.conf
randomly fail. And (probably) use nscd.
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've found
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/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).
On 2026-09-08 14:44:07 +0200, Marco Moock wrote:
Am 08.09.26 um 12:10 schrieb Vincent Lefevre:
So, if you want to reproduce the issue, set up a network
where DNS requests to the nameservers in /etc/resolv.conf
randomly fail. And (probably) use nscd.
How is that related to IPv6?
If you have a faulty DNS setup, fix that first.
I don't see where it is faulty (to the point of getting the
observed behavior).
/etc/resolv.conf is queried by the order of entries by default every
time a request is being made.
strace does not show any access to this file when AF_UNSPEC is used.
Also check the nsswitch.conf, there might be additional entries for hosts
and resolve might be listed there, which is systemd-resolve, a local DNS
cache acting as a DNS server.
There is already a local DNS cache: nscd.
To be clearer: dig queries only IPv4 by default (for the "-t type"
option: "The default query type is A"), and I sometimes get SERVFAIL
with it, but a request a few seconds later seems to always succeed.
On 2026-09-12 01:09:06 +0700, Max Nikulin wrote:
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.
BTW, on this point, disabling SLAAC is a bit complex. I thought that accept_ra = 0 was sufficient (at least when I added it in 2015), but
it was actually ignored by NetworkManager, for which I had to add ipv6.dns-priority=-100 in its configuration several months ago.
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.
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.
Perhaps I should have looked closely to what ssh was giving (FYI, this
is because I got ssh failures for a repository update that I tried
with other tools):
ssh: Could not resolve hostname joooj.vinc17.net: Name or service not known
This is clearer that the issue is not directly related to IPv6, but
rather related to name resolution. I suppose that since socket()
fails for IPv6 (because it has been disabled in the kernel), ssh
ignores IPv6 completely. So this would be another reason to disable
IPv6 in the kernel when it is not supported by the network: to
hopefully get more meaningful error messages.
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.
Here, caching is used locally on the machine (with nscd). This is
a cache inconsistency. This is not a question of compromise.
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.
When errors are cached for several hours, they are much more noticeable!
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).
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)
Interesting to know. I'll suggest that to the admin.
And how do you think applications know that IPv6 is disabled in the
kernel? Do you suggest somebody who disables IPv6 in the kernel should rebuild all applications with `./configure --disable-ipv6`?
On 2026-09-15 22:07:42 +0200, Marco Moock wrote:
Am 13.09.26 um 00:30 schrieb Vincent Lefevre:
To be clearer: dig queries only IPv4 by default (for the "-t type"
option: "The default query type is A"), and I sometimes get SERVFAIL
with it, but a request a few seconds later seems to always succeed.
That is a clear indicator that the DNS server that it queries has an issue. >> It shows which one it uses. Investigate that.
I recall that I am not the admin. So I cannot. I'm still waiting
for information from the ticket I had opened.
On 2026-09-15 22:07:02 +0200, Marco Moock wrote:
Am 13.09.26 um 00:00 schrieb Vincent Lefevre:
On 2026-09-12 01:09:06 +0700, Max Nikulin wrote:
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.
BTW, on this point, disabling SLAAC is a bit complex. I thought that
accept_ra = 0 was sufficient (at least when I added it in 2015), but
it was actually ignored by NetworkManager, for which I had to add
ipv6.dns-priority=-100 in its configuration several months ago.
This doesn't disable SLAAC, but if that mitigates your problem, there is a >> major problem - and it is not SLAAC neither IPv6.
I don't know whether this mitigates the problem on this machine.
Then what do you suggest?
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.
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.
As you refuse to show the output of "ip a", it is not possible to help here.
Perhaps you should read the whole thread. I gave it last week:
Date: Tue, 8 Sep 2026 18:48:17 +0200
From: Vincent Lefevre <vincent@vinc17.net>
To: debian-user@lists.debian.org
Subject: Re: How to prevent programs from using IPv6 by default on a machine without IPv6 support?
Message-ID: <20260908164817.GP1165915@qaa.vinc17.org>
nscd is not installed by default in Debian. Please show us the
configuration.
enable-cache hosts yes
positive-time-to-live hosts 3600
negative-time-to-live hosts 20
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).
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)
Interesting to know. I'll suggest that to the admin.
Another shitty idea, as this doesn't address the real issue. Just my 2
cents.
So what do you suggest?
On 2026-09-15 21:46:17 +0200, Marco Moock wrote:
Am 10.09.26 um 18:50 schrieb Vincent Lefevre:
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.
Then investigate which machine that is. It might be a bogus attacker
or just a completely misconfigured device.
I just know that misconfigured devices are found on the network.
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).
Disable it for testing or at least clear the cache.
Is there a way to disable it for testing, as non-root?
Note that I can still test on domains that are not in the cache.
This is how I can see that there are still temporary failures,
probably due to SERVFAIL from the nameservers.
If disabling IPv6 mitigates the problem, there is a serious problem
on your machine/network, that needs to be investigated and fixed.
There is a serious problem with nscd, as already said.
Disabling IPv6 is a dead-end street.
I don't see why. IPv6 is not supported on the network, so there
are no drawbacks in disabling it for hostname resolution. And if
it were supported, then there wouldn't have been any major issue
with nscd.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 4 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 497102:17:39 |
| Calls: | 182 |
| Files: | 744 |
| D/L today: |
59 files (9,737K bytes) |
| Messages: | 73,647 |