On 2026-09-16 00:14:12 +0700, Max Nikulin wrote: > On 15/09/2026 7:34 am, Vincent Lefevre wrote: > > BTW, following the suggestion of the no-aaaa option done by someone > > here, which I then suggested in my ticket[*], a "options no-aaaa" line > > has been added to /etc/resolv.conf, and there is no longer any issue. > > Does it mean that you can not try some scenarios related to the > issue any more?
I don't think so. > Since you mentioned NetworkManager, This was for a different machine. > do you have enough permissions to create another connection without > "no-aaaa"? Perhaps I could try with one of my own machines on this network, but I don't have much time. > > On 2026-09-14 00:06:06 +0700, Max Nikulin wrote: > > > I suggest you to change the bug title to make the issue specific to nscd. > > > > I'm wondering whether this would be redundant: the bug is in the > > nscd component, so that's implied. > > You are right, it is redundant and I did not notice the component field. > However, I am afraid, the issue may appear in search results without > component. I can still see failures due to the remote issue with the nameservers. They affect getaddrinfo with nscd running, but I assume that this would be the same without nscd. But thanks to the no-aaaa option, such failures are no longer cached for hours. > It is not unusual for projects to have constantly growing backlog. You need > to convince developers that your issue is important and should be > prioritized. > > Currently your issue > 34606 "getaddrinfo with AF_UNSPEC sometimes returns only the IPv6 address" > may be perceived as a kind of duplicate for > 26601 "getaddrinfo()/AF_UNSPEC: resolver does not try next DNS if SERVFAIL > received for IPv4" No, 34606 is about the cache of failures with nscd, while with 26601, nscd is not involved. Fixing 26601 would *not* make the cache issue disappear with 34606; it would just make it occur less likely (and would not even change anything when there is a single nameserver). > I would consider something like > "nscd may ignore negative-time-to-live for host when A or AAAA AF_UNSPEC > query fails" Not exactly. The fact is that nscd seems to consider that there is an entry. But I agree that the bug title should be improved. > To my taste your description of the issue is excessively generic. > Personally I prefer more specific scenarios like > > Sometimes I am getting obscure errors like > [example chosen to avoid details on disabled IPv6] > > wget http://42.be > --2026-09-08 19:32:28-- http://42.be/ > Resolving 42.be (42.be)... 2001:470:1f15:29a::1 > Connecting to 42.be (42.be)|2001:470:1f15:29a::1|:80... failed: Network is > unreachable. > > that persist at least for an hour. This machine does not have global IPv6 > routing, but errors may happen for hosts having IPv4 address > > dig 42.be > [command output] > > It seems, DNS servers received through DHCP, currently may return SERVFAIL > if requested resource record is not in their cache > > [ date; dig ...; date; dig ...; to demonstrate the DNS issue ] > > I expect that wget should try the IPv4 address a minute later when negative > result for A query is expired in the nscd cache. > > etc. I don't understand what you mean. 42.be only has an IPv6 address, and there is no SERVFAIL with it. > > BTW, a SERVFAIL is *not* a timeout. It is always obtained immediately. > > It may be a bug either in the code or in the DNS server configuration. I > expect to get immediate SERVFAIL only if it is cached due to an earlier > query. Otherwise it should require some time to wait for response from > parent servers. Perhaps there is a response. -- 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)
