467497 - getaddrinfo calls should use AI_ADDRCONFIG

Status: RESOLVED DUPLICATE of bug 614526

(NSPR :: NSPR, defect)

Description

[Max Kanat-Alexander]

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.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

So why's the code at http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/src/nsHostResolver.cpp#878 not working?

Comment 2

[Max Kanat-Alexander]

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.

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

Oh, that doesn't sound good... I emailed darin/wtc if they know the reason for that.

Comment 4

[Jo Hermans]

AI_ADDRCONFIG is not used in PR_GetAddrInfoByName (comment 2), but it is in nsHostResolver::ThreadFunc (comment 1). I'm not sure which one is really used.

Comment 5

[nemo]

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.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

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=3.21.2.13.10.4

(from the NSPR_GETADDRINFO_BRANCH)

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

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).

Comment 8

[Mike Hommey [:glandium]]

Attachment: Pass AI_ADDRCONFIG when supported (and not harmful) and when PR_AI_ADDRCONFIG was given

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.

Comment 9

[Wan-Teh Chang]

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.

Comment 10

[Mike Hommey [:glandium]]

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).

Comment 11

[Mike Hommey [:glandium]]

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.

Comment 12

[Wan-Teh Chang]

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.

Comment 13

[Wan-Teh Chang]

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.