Bug 240749

Summary:	Unnecessary IPv6 lookups.
Product:	[Fedora] Fedora	Reporter:	David Woodhouse <dwmw2>
Component:	glibc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED RAWHIDE	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	drepper
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-09-22 16:35:38 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Woodhouse 2007-05-21 13:17:46 UTC

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 09:20:44 UTC

What options were passed to getaddrinfo?

Comment 2 David Woodhouse 2007-05-22 11:40:17 UTC

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 14:46:59 UTC

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 16:26:42 UTC

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 18:28:54 UTC

Current CVS glibc ignores the loopback addresses, since
BZ#4599 patch.

Comment 6 Ulrich Drepper 2007-08-24 17:48:56 UTC

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 16:35:38 UTC

No reply, assuming it is fixed.  If not, please reopen with additional info.