Starting with glibc-2.6.1 any ::1 address in /etc/hosts causes the name resolver to return "127.0.0.1, ::1" making it impossible to point to ipv6 localhost address only. This is specially problematic as ipv4 address is returned before the ipv6 one. -- /etc/hosts -- 127.0.0.1 localhost localhost4 ::1 localhost localhost6 127.0.0.2 x x4 ::2 x x6 -- An easy way to test name resolver is using "telnet localhost6". glibc-2.5-r2 - Correct! localhost4 => 127.0.0.1 localhost6 => ::1 glibc-2.6.1 / glibc-2.7 - problems localhost4 => 127.0.0.1 localhost6 => 127.0.0.1, ::1 ## ERROR x4 => 127.0.0.2 x6 => ::2
Created attachment 136211 [details] getaddrinfo.c i think this shows the problem you're talking about ... please confirm just run it like: ./getaddrinfo localhost ./getaddrinfo localhost4 ./getaddrinfo localhost6 ./getaddrinfo x ./getaddrinfo x4 ./getaddrinfo x6 and see what's what
Your test program shows only the FIST value returned by getaddrinfo hiding the fact that "localhost6" returns two values under new glibc. Anyway here are the significant results. The problem exists both in x86 and amd64. glibc-2.6.1-amd64$ ./getaddrinfo localhost6 --- looking up 'localhost6' for family 0 (0) getaddrinfo(...) = EAI_NONAME, trying again with AI_CANONNAME getaddrinfo(...) = 0 getnameinfo(...) = 0 name = 127.0.0.1 service = 23 --- looking up 'localhost6' for family AF_INET (2) getaddrinfo(...) = EAI_NONAME, trying again with AI_CANONNAME getaddrinfo(...) = 0 getnameinfo(...) = 0 name = 127.0.0.1 service = 23 --- looking up 'localhost6' for family AF_INET6 (10) getaddrinfo(...) = EAI_NONAME, trying again with AI_CANONNAME getaddrinfo(...) = 0 getnameinfo(...) = 0 name = ::1 service = 23 glibc-2.6.1-amd64$ ./getaddrinfo x6 --- looking up 'x6' for family 0 (0) getaddrinfo(...) = EAI_NONAME, trying again with AI_CANONNAME getaddrinfo(...) = 0 getnameinfo(...) = 0 name = ::2 service = 23 --- looking up 'x6' for family AF_INET (2) getaddrinfo(...) = EAI_NONAME, trying again with AI_CANONNAME getaddrinfo(...) = EAI_NONAME ... FAIL --- looking up 'x6' for family AF_INET6 (10) getaddrinfo(...) = EAI_NONAME, trying again with AI_CANONNAME getaddrinfo(...) = 0 getnameinfo(...) = 0 name = ::2 service = 23 For comparison the "localhost6" test under older glibc. glibc2.5-r4-amd64$ ./getaddrinfo localhost6 --- looking up 'localhost6' for family 0 (0) getaddrinfo(...) = EAI_NONAME, trying again with AI_CANONNAME getaddrinfo(...) = 0 getnameinfo(...) = 0 name = ::1 service = 23 --- looking up 'localhost6' for family AF_INET (2) getaddrinfo(...) = EAI_NONAME, trying again with AI_CANONNAME getaddrinfo(...) = EAI_NONAME ... FAIL --- looking up 'localhost6' for family AF_INET6 (10) getaddrinfo(...) = EAI_NONAME, trying again with AI_CANONNAME getaddrinfo(...) = 0 getnameinfo(...) = 0 name = ::1 service = 23
Created attachment 138050 [details] getaddrinfo.c if it wasnt showing the whole story, then you should have tweaked the file :P
$ ./getaddrinfo localhost6 --- looking up 'localhost6' for family 0 (0) getaddrinfo(...) = EAI_NONAME, trying again with AI_CANONNAME getaddrinfo(...) = 0 getnameinfo(...) = 0 name = 127.0.0.1 service = 23 getnameinfo(...) = 0 name = ::1 service = 23 --- looking up 'localhost6' for family AF_INET (2) getaddrinfo(...) = EAI_NONAME, trying again with AI_CANONNAME getaddrinfo(...) = 0 getnameinfo(...) = 0 name = 127.0.0.1 service = 23 --- looking up 'localhost6' for family AF_INET6 (10) getaddrinfo(...) = EAI_NONAME, trying again with AI_CANONNAME getaddrinfo(...) = 0 getnameinfo(...) = 0 name = ::1 service = 23
i sampled a few distros/glibc versions and moved this upstream
*** Bug 214839 has been marked as a duplicate of this bug. ***
unfortunately, upstream has their head up their ass and wont change the behavior. they claim it is correct behavior and wont be changed. see also: http://sourceware.org/bugzilla/show_bug.cgi?id=4980
Wow... the upstream thread is amazing. Basically, as I understand it, it was done on purpose to break all apps that are not handling ultra clean IPv6/IPv4 name resolution. And I got the issue with my local apache 2.2.8 and Firefox 3 beta... then those pieces of software need to have a cleaner IPv6/IPv4 name resolution... ouch! Then, if firefox resolves a name, it will have to parse all returned entries from the resolver in order to look *explicitely* for the entries with the proper address family *and* make an explicit difference between IPv6 mapped IPv4 addresses and real IPv6 address. Who does open in Mozilla for this?
putting this crap into firefox sounds so wrong, but you're right in that it seems to be the only "solution" i'd open a bug report at the upstream firefox bugzilla and then let us know the upstream bug #
