getaddrinfo calls should use AI_ADDRCONFIG

RESOLVED DUPLICATE of bug 614526

Status

defect
RESOLVED DUPLICATE of bug 614526
11 years ago
8 years ago

People

(Reporter: mkanat, Assigned: glandium)

Tracking

other
4.8.8
All
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

11 years ago
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.
Reporter

Comment 2

11 years ago
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.

Comment 4

9 years ago
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

9 years ago
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=3.21.2.13.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
Status: NEW → UNCONFIRMED
Ever confirmed: false
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee

Comment 8

9 years ago
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
Attachment #444041 - Flags: review?(wtc)

Comment 9

9 years ago
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.
Assignee

Comment 10

9 years ago
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).
Assignee

Comment 11

9 years ago
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

9 years ago
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

8 years ago
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
Assignee

Updated

8 years ago
Attachment #444041 - Flags: review?(wtc)
Assignee

Updated

8 years ago
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.