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?
What options were passed to getaddrinfo?
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) +++
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.
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.
Current CVS glibc ignores the loopback addresses, since BZ#4599 patch.
I fixed the one issue which the spec said (see comment #5). What else do you think is wrong?
No reply, assuming it is fixed. If not, please reopen with additional info.