Passing the AI_ADDRCONFIG flag to getaddrinfo on Linux (and likely other libc-based OSes) will prevent IPv6 DNS lookups on machines that have only IPv4 interfaces. This is particularly noticeable in Fedora 10, as it causes DNS lookups to fail about 1/3 of the time, and generally take forever, in any case. (More details here: https://bugzilla.redhat.com/show_bug.cgi?id=459756#c24 [and in earlier and later comments]). In any case, it'd save us an AAAA lookup on machines that can't use the returned data anyhow.
So why's the code at http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/src/nsHostResolver.cpp#878 not working?
Well, I have to admit a total unfamiliarity with Core, but it would seem that here: http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/misc/prnetdb.c#2013 The only hint that gets passed to getaddrinfo is AI_CANONNAME, and AI_ADDRCONFIG is actually being ignored. I could be misreading it, though--as I said, I'm very unfamiliar with the code.
Oh, that doesn't sound good... I emailed darin/wtc if they know the reason for that.
There are broken DNS servers on our network. I'd like to note that with: hints.ai_flags |= AI_ADDRCONFIG; on prnetdb.c line 2344 Firefox responded instantly with no delays. Without that, Lucid Lynx, Firefox took several seconds for each lookup. glandium pointed out: http://src.chromium.org/viewvc/chrome/trunk/src/net/base/host_resolver_proc.cc?revision=43947&view=markup (see the "DO NOT USE AI_ADDRCONFIG ON WINDOWS") BTW, ip -6 addr and ip -6 route *do* report a default ipv6 route with this machine in default setup. Despite that, AI_ADDRCONFIG does seem to help. Perhaps glibc uses the hint differently than my understanding of it. Additionally, I had gone to considerable lengths to disable ipv6 in every place I could think of to try and solve the AAAA lookup in things like wget which have no "disableIPv6" config pref. Oddly, while it did not help in those, it *did* help in Firefox where I did not need AI_ADDRCONFIG to have fast behaviour. I'm not sure of the reason for that.
As an explanation why we don't pass AI_ADDRCONFIG now: http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/nsprpub/pr/src/misc/prnetdb.c&rev=188.8.131.52.10.4 (from the NSPR_GETADDRINFO_BRANCH)
OK, let's confirm this bug. Since I don't know what the systems are that that CVS commit referred to, I think we can just pass AI_ADDRCONFIG on all systems where that's defined, except for windows (see http://code.google.com/p/chromium/issues/detail?id=5234).
Status: UNCONFIRMED → NEW
Ever confirmed: true
9 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
RFC 3493 is becoming more and more widespread and AI_ADDRCONFIG can get necessary. In fact, there is even a PR_AI_ADDRCONFIG flag that Firefox, or even the getai.c test in the nspr tree pass to PR_GetAddrInfoByName and that is simply ignored. It should be safe to pass AI_ADDRCONFIG to getaddrinfo when it is defined and when the caller specified the PR_AI_ADDRCONFIG flag. OTOH, AI_ADDRCONFIG is known to be harmful on Windows, so there is an explicit exclusion. See http://code.google.com/p/chromium/issues/detail?id=5234.
Assignee: nobody → mh+mozilla
AI_ADDRCONFIG seems to have the same or a similar problem on Linux with hostnames such as "localhost" that are mapped to a loopback address in /etc/hosts. See http://code.google.com/p/chromium/issues/detail?id=32522#c15 I don't have a good solution for this problem other than to handle these hostnames ("localhost", "ip6-localhost", etc.) as special cases. In any case, I agree we should use AI_ADDRCONFIG to make the common case work well.
On my system (debian) both getaddr1 and getaddr2 only return 127.0.0.1. Using the host program returns me both 127.0.0.1 and ::1, and that's because that comes from DNS instead of /etc/hosts. /etc/hosts only contains 127.0.0.1 for localhost. ::1 is ip6-localhost. OTOH, with network down, the first one says getaddrinfo failed: No address associated with hostname while the second returns 127.0.0.1. Arguably, this could be considered a libc bug (and I think there was a discussion along these lines on debian mailing lists some time ago, I'll try to look up).
FTR, http://sourceware.org/bugzilla/show_bug.cgi?id=4599 is why localhost is not resolvable without network connectivity... arguably, this should only apply when using the DNS, not when using /etc/hosts.
Thanks for the info. The specification of AI_ADDRCONFIG in RFC 3493 needs to be updated to handle this use case: when a computer has no outbound network connectivity, an application should still be able to resolve "localhost" as 127.0.0.1 or ::1 if the loopback interface has the 127.0.0.1 or ::1 address configured. Without this change, an application that uses AI_ADDRCONFIG cannot connect to "localhost" when the computer has no network connectivity.
I forgot this bug -- this problem has recently been brought up again in bug 614526 and I already checked in a patch on the NSPR CVS trunk.
Component: Networking → NSPR
Product: Core → NSPR
QA Contact: networking → nspr
Target Milestone: --- → 4.8.8
Version: unspecified → other
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 614526
You need to log in before you can comment on or make changes to this bug.