08:54:34.630754 IP 192.168.1.84.32820 > 22.214.171.124.domain: 32257+ AAAA?
08:54:34.719520 IP 126.96.36.199.domain > 192.168.1.84.32820: 32257 0/1/0 (95)
08:54:34.720341 IP 192.168.1.84.32820 > 188.8.131.52.domain: 62758+ AAAA?
08:54:34.763722 IP 184.108.40.206.domain > 192.168.1.84.32820: 62758 NXDomain
08:54:34.766618 IP 192.168.1.84.32820 > 220.127.116.11.domain: 12574+ A?
08:54:34.776994 IP 18.104.22.168.domain > 192.168.1.84.32820: 12574 1/0/0 A
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"
Connected to pentafluge.infradead.org.
Escape character is '^]'.
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
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.