Bug 240749 - Unnecessary IPv6 lookups.
Unnecessary IPv6 lookups.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-21 09:17 EDT by David Woodhouse
Modified: 2008-08-02 19:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-22 12:35:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2007-05-21 09:17:46 EDT
08:54:34.630754 IP 192.168.1.84.32820 > 68.87.71.226.domain:  32257+ AAAA?
www.cam.ac.uk. (31)
08:54:34.719520 IP 68.87.71.226.domain > 192.168.1.84.32820:  32257 0/1/0 (95)
08:54:34.720341 IP 192.168.1.84.32820 > 68.87.71.226.domain:  62758+ AAAA?
www.cam.ac.uk.infradead.org. (45)
08:54:34.763722 IP 68.87.71.226.domain > 192.168.1.84.32820:  62758 NXDomain
0/1/0 (101)
08:54:34.766618 IP 192.168.1.84.32820 > 68.87.71.226.domain:  12574+ A?
www.cam.ac.uk. (31)
08:54:34.776994 IP 68.87.71.226.domain > 192.168.1.84.32820:  12574 1/0/0 A
131.111.8.46 (47)

We get a 'nodata' response to the AAAA lookup for www.cam.ac.uk, not NXdomain.
So why do we still try for 'www.cam.ac.uk.infradead.org' before looking for the
A record? And where did that 'infradead.org' search domain come from anyway?
It's not in /etc/resolv.conf.

In fact, this machine doesn't have _any_ IPv6 addresses other than link-local
right now. Why are we bothering with AAAA lookups at all? Shouldn't we avoid
them unless we actually have a site- or global-scope address?
Comment 1 Jakub Jelinek 2007-05-22 05:20:44 EDT
What options were passed to getaddrinfo?
Comment 2 David Woodhouse 2007-05-22 07:40:17 EDT
Er, dunno. That was just 'telnet www.cam.ac.uk 80'. ltrace seems... unenlightening:

shinybook /shiny/git/olpc-combine $ ltrace -o foo telnet pentafluge.infradead.org 80
WARNING: Using e_entry from elf header (0x5920) for address of "_start"
Trying 213.146.154.40...
Connected to pentafluge.infradead.org.
Escape character is '^]'.
^]close

telnet> close
Connection closed.
shinybook /shiny/git/olpc-combine $ cat foo
unexpected breakpoint at 0x30016be4
+++ exited (status 0) +++
Comment 3 Ulrich Drepper 2007-05-22 10:46:59 EDT
How can getaddrinfo avoid the IPv6 lookup if there is an IPv6 address?  Even if
it's link-local.  Maybe the name is for a link-local interface.  We don't know
until we try to resolve it.  Correct me if I'm wrong, but connecting to a
link-local interface is similar to using 127.0.0.1 which is a legitimate use.
Comment 4 David Woodhouse 2007-05-22 12:26:42 EDT
Hm, yes and no. A link-local interface is really link-local. It isn't like
'127.0.0.1'. You can't use it unless you also specify the interface. It can't be
represented in DNS.

But we _do_ have a 'localhost' address (::1) on the 'lo' device which I had
forgotten about -- and which _is_ possible to represent in DNS. So you're right
that we should probably be doing the AAAA lookup anyway.
Comment 5 Jakub Jelinek 2007-06-28 14:28:54 EDT
Current CVS glibc ignores the loopback addresses, since
BZ#4599 patch.
Comment 6 Ulrich Drepper 2007-08-24 13:48:56 EDT
I fixed the one issue which the spec said (see comment #5).  What else do you
think is wrong?
Comment 7 Jakub Jelinek 2007-09-22 12:35:38 EDT
No reply, assuming it is fixed.  If not, please reopen with additional info.

Note You need to log in before you can comment on or make changes to this bug.