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.
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 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.
Another bullshit argument.
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.
nscd is not installed by default in Debian. Please show us the
configuration.
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!
nscd offers options for caching negative responses. Which values are set
here?
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.
--
Gruß
Marco
Spam bitte an [email protected]
