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. > > I opened tickets for these 2 issues. > > If you mean internal helpdesk service then, I suppose, it is the best > possible action to get quick result. Yes, the internal helpdesk service, but "quick result", maybe not. > > > 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. -- 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)
