355087 - DNS lookup on mixed IPv6/IPv4 websites fails over to IPv4 while on a IPv6 network

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Michael Adams]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1) Gecko/20061001 BonEcho/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1) Gecko/20061001 BonEcho/2.0

IPv6/IPv4 mixed websites resolve as IPv4 websites, and IPv6 websites cannot resolve via DNS. Using a direct IPv6 address does work however.

Reproducible: Always

Steps to Reproduce:
1. Access http://www.kame.net/
2. Access http://[2001:200:0:8002:203:47ff:fea5:3085]/
3. Access http://[www.kame.net]/


Actual Results:  
Step 1 will produce a static turtle.
Step 2 will produce a dancing turtle.
Step 3 will produce a static turtle.

Expected Results:  
Firefox prefers IPv6 by design: it should have always loaded the IPv6 version.

I ran Ethereal to check the packet activity, and noticed 2 DNS attempts...

1 0.000000 Buffalo_16:30:fa Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/00:16:01:16:30:fa Cost = 0 Port 2 1.235898 fe80::216:1ff:fe16:30fa ff02::1 ICMPv6 Router advertisement
3 2.000253 Buffalo_16:30:fa Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/00:16:01:16:30:fa Cost = 0 Port 4 3.743475 192.168.1.100 192.168.1.1 DNS Standard query AAAA www.kame.net
5 3.744836 192.168.1.1 192.168.1.100 DNS Standard query response AAAA 2001:200:0:8002:203:47ff:fea5:3085
6 3.746792 192.168.1.100 192.168.1.1 DNS Standard query A www.kame.net
7 3.748249 192.168.1.1 192.168.1.100 DNS Standard query response A 203.178.141.194
8 3.750145 192.168.1.100 203.178.141.194 TCP 2773 > http [SYN] Seq=0 Len=0 MSS=1460
9 3.966583 203.178.141.194 192.168.1.100 TCP http > 2773 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
10 3.966641 192.168.1.100 203.178.141.194 TCP 2773 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
11 3.966787 192.168.1.100 203.178.141.194 HTTP GET / HTTP/1.1
12 4.000483 Buffalo_16:30:fa Spanning-tree-(for-bridges)_00 STP Conf. Root = 32768/00:16:01:16:30:fa Cost = 0 Port 13 4.197916 203.178.141.194 192.168.1.100 TCP [TCP segment of a reassembled PDU]
14 4.337276 192.168.1.100 203.178.141.194 TCP 2773 > http [ACK] Seq=399 Ack=1010 Win=64526 Len=0
15 4.577618 203.178.141.194 192.168.1.100 TCP [TCP segment of a reassembled PDU]
16 4.577809 203.178.141.194 192.168.1.100 TCP [TCP segment of a reassembled PDU]
17 4.577958 192.168.1.100 203.178.141.194 TCP 2773 > http [ACK] Seq=399 Ack=2981 Win=65535 Len=0
18 4.577964 203.178.141.194 192.168.1.100 HTTP HTTP/1.1 200 OK (text/html)
19 4.602843 192.168.1.100 203.178.141.194 HTTP GET /style.css HTTP/1.1
20 4.821068 203.178.141.194 192.168.1.100 TCP [TCP segment of a reassembled PDU]
21 4.821328 203.178.141.194 192.168.1.100 HTTP HTTP/1.1 200 OK (text/css)
22 4.821487 192.168.1.100 203.178.141.194 TCP 2773 > http [ACK] Seq=756 Ack=5548 Win=65535 Len=0
23 4.839667 192.168.1.100 203.178.141.194 HTTP GET /img/kame-noanime-small.gif HTTP/1.1

Apparently, Firefox preferred the second result to the 1st.

Comment 1

[Michael Adams]

I wiped out my whole old profile (and even corrupted my bookmarks.html file, so there's about 10-20 sites I just lost track of; kept the cookies.txt though) and loaded Firefox RC1 for Windows. The error is still present, so we know this has been around a while, trunk or branch.

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1) Gecko/20060918 Firefox/2.0

Comment 2

[Michael Adams]

Same results under Vista RC2, using Firefox 2 RC2

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1) Gecko/20061003 Firefox/2.0

Comment 3

[bjb]

This is always reproductible also on XP SP2 on FF2.0, including when setting a precedence table setup to prefer ipv6 over ipv4 as per RFC 3484 :

netsh interface ipv6>show prefix
Precedence  Label    Prefix
----------  -------  --------------------------------
        40      5  2001::/32
        20      3  ::/96
        30      2  2002::/16
        50      1  ::/0
        60      0  ::1/128
        10      4  ::ffff:0:0/96

Consequence, at this time, only solution to get ipv6 from FF on a website is to connect to ipv6 only server or type the ipv6 address manually in the address bar (anybody remember an ipv6 adress here ?). Knowing that today, most ipv6 enabled servers are also ipv4 nodes for obvious compatibility purposes, this means Firefox will almost never use ipv6 :( For early ipv6 adopters this seriously deprecate Firefox as a possible choice ... (FYI, Opera got it right !)

Anybody with ipv6 skills willing to fix this one ?

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

hm, your 3) variant should produce an malformed URL error.

As for the bug... Necko just uses the addresses in the order in which getaddrinfo returns them...

Comment 5

[Mark Smith]

I've been suffering from this problem too. A few years back Firefox used to "just work" once you enabled IPv6. I seem to remember there was some controversy with glibc at some point and IIRC they decided that there were too many broken DNS servers that were silently ignoring AAAA lookups rather than returning with an error that they decided to have glibc prefer As over AAAAs if both were returned. That doesn't explain it not working on XP though, although maybe Microsoft made the same decision.

Looking at the getaddrinfo manual page (on my Arch linux box with glibc 2.6.1), it seems that there is a "hints" parameter which can specify what types of response getaddrinfo should return, which seems to include indicating a preference for IPv6 AAAA records. Maybe if the mozilla network.dns.disableIPv6 variable is set to false, then this hint could be set to prefer IPv6 AAAA records. 

Comment 6

[Mark Smith]

I've done a bit more investigating. Here's what I've found :

* the getaddrinfo hints option I suggested earlier doesn't seem to have an option that prefers AAAA records over As if the AAAA records exist.

* it seems that firefox is using the first socket address structure in the returned list for getaddrinfo. For domain names with both an A and AAAA records, the A record always seem to be the first in the list. Maybe in the past this wasn't the case, which was why firefox just worked when IPv6 was enabled.

* I can't seem to find any way to change that order. I've come across a getaddrinfo configuration file called /etc/gai.conf which seems to be specifying preferences for IPv6 addresses when multiple are returned, but doesn't seem to have the option of influencing the decision between A verses AAAA.

* I've hacked up the example client program on the getaddrinfo manual page just to show the outcome of lookups, by walking through the supplied list of sockaddr structures in the order they are supplied :

[mark@ubu getaddrinfo]$ ./a.out www.kame.net

getaddrinfo(www.kame.net)
        rp->ai_family == AF_INET, 203.178.141.194
        rp->ai_family == AF_INET6, 2001:200:0:8002:203:47ff:fea5:3085

[mark@ubu getaddrinfo]$ ./a.out lb.nosense.org

getaddrinfo(lb.nosense.org)
        rp->ai_family == AF_INET, 127.0.0.1
        rp->ai_family == AF_INET6, ::1

[mark@ubu getaddrinfo]$ 


When I ran a tcpdump against the DNS lookups that this program triggers, I got a bit of a surprise - it's doing the AAAA lookup first.:

[root@ubu ~]# tcpdump -n -i lo
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
21:53:27.269299 IP 127.0.0.1.39483 > 127.0.0.1.53: 39353+ AAAA? www.kame.net. (30)
21:53:27.270955 IP 127.0.0.1.53 > 127.0.0.1.39483: 39353 1/2/5 AAAA[|domain]
21:53:27.271672 IP 127.0.0.1.39483 > 127.0.0.1.53: 18980+ A? www.kame.net. (30)
21:53:27.272692 IP 127.0.0.1.53 > 127.0.0.1.39483: 18980 1/2/5 A 203.178.141.194 (199)

Maybe the way to solve this would be to have firefox prefer AAAA answers if disableIPv6 is false and an AAAA answer is returned by getaddrinfo. Reading through the getaddrinfo page, it would seem that setting the AI_ADDRCONFIG flag would also be the right thing to do, if it isn't being done already.

Comment 7

[G Bedel]

I got the same problem using firefox 1.5.0.7 on Linux, with glib 1.2.10.
As Mark Smith pointed out, it seems that firefox is using the first socket address structure in the returned list for getaddrinfo.

Using a similar test program against names with both ipv4 and ipv6 associated addresses, I got the v6 firstly and the v4 secondly for most servers (such as http://www.kame.net/ or http://www.ipv6.org/), and firefox indeed use ipv6 for theses servers. But my problem comes using my personnal DNS server : for some reason, I always get the v4 firstly ond the v6 secondly, and firefox always uses ipv4. But, on another computer on my LAN (which uses an up-to-date glibc/firefox), with the same DNS server, I got the v6 first and the v4 then, so firefox uses ipv6.

I don't think that the DNS lookups IP version order is important, here it always do the AAAA firstly and then the A, whereas the getaddrinfo list order differ from my DNS server to other servers.

So for the moment the IP version choice is made by getaddrinfo. I don't know if there is a way to change it's beheaviour... Actually, the sorting order must follow the RFC 3484, section 6, which is quite obscur to me.

I also suggest that firefox should prefer AAAA answers if disableIPv6 is false and an AAAA answer is returned by getaddrinfo, that sounds obvious to me.
Maybe I could write that patch if I got the time.

Comment 8

[Lapo Luchini]

I have this problem too... but reading RFC 3484 section 6 it *MAY* just be right in my case to use the IPv4 address preferentially: my IPv6 connection is using 6to4, thus my local IPv6 address is in the 2002::/16 prefix: the implementation knows this prefix and, as the rule 7 states it MAY use a concept of interface preference and give a 6to4 interface lower preference.

In my case, specifically, the WinXP64 box on which I encounter the problem is NOT using a 6to4 interface... my FreeBSD home server is, the WinXP64 box got his IPv6 address automatically by the server's RTADV. Of course, being in the 6to4 prefix anyway, he "knows" that address is tunneled for sure even if the 6to4 virtual interface is not local.

Comment 9

[Lapo Luchini]

BTW: I can confirm this is happening on FreeBSD-7 too.
Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.11) Gecko/20071223 Firefox/2.0.0.11

Comment 10

[Michael Adams]

I forgot I posted this issue 2 years back. Firefox 3 seems to have fixed it on both Windows & Linux.

Comment 11

[Justin Kerk]

I'm using Minefield and the behaviour is still the same here:

http://www.kame.net/ - static turtle
http://[2001:200:0:8002:203:47ff:fea5:3085]/ - dancing turtle

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081024 Minefield/3.1b2pre ID:20081024032143

Comment 12

[Mike A. Harris]

I'm observing this same behaviour.  Firefox 3.0.10 running on CentOS 5.3.

Comment 13

[Lorenzo Colitti]

The order that the addresses are returned in depends on the system, and in the particular case of 6to4 or Teredo addresses (2002::/16 or 2001:0::/32) many systems prefer IPv4, since it's likely to lead to better performance.

Resolving invalid. If someone with a working global unicast IPv6 address is able to reproduce, please reopen.