Closed Bug 377282 Opened 14 years ago Closed 14 years ago
Camino appears to be unable to resolve AAAA records / connect to IPv6 sites
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:18.104.22.168pre) Gecko/20070223 Camino/1.1b Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:22.214.171.124pre) Gecko/20070223 Camino/1.1b If I try to surf websites which only have AAAA records, e.g.: http://www.v6.alchemistowl.org/ http://www.v6.northsea.sevenseas.org/ then Camino reports them as if the DNS name was invalid. Both sites have valid AAAA records and an IPv6-enabled Apache listening: anacleto:~$ host www.v6.alchemistowl.org www.v6.alchemistowl.org is an alias for stregatto.alchemistowl.org. www.v6.alchemistowl.org is an alias for stregatto.alchemistowl.org. stregatto.alchemistowl.org has IPv6 address 2001:1418:13:7::1001 anacleto:~$ host www.v6.northsea.sevenseas.org www.v6.northsea.sevenseas.org is an alias for tempest.v6.northsea.sevenseas.org. www.v6.northsea.sevenseas.org is an alias for tempest.v6.northsea.sevenseas.org. tempest.v6.northsea.sevenseas.org has IPv6 address 2001:1418:13:7::1 The system is IPv6-enabled and connected to IPv6: traceroute6 to stregatto.alchemistowl.org (2001:1418:13:7::1001) from 2001:1418:13:6:216:cbff:fe84:bf37, 30 hops max, 12 byte packets 1 outer-gw.darkpackets.org 1.075 ms 0.741 ms 0.878 ms 2 stregatto 1254.12 ms 68.599 ms 68.803 ms In a possibly related issue surfing to http://www.kame.net/ yields the IPv4 site rather than the IPv6 site. Reproducible: Always Steps to Reproduce: 1. Open Camino on an IPv6-enabled OS X system 2. Surf to, say, http://www.v6.alchemistowl.org/ Actual Results: Get error message: Address Not Found www.v6.alchemistowl.org could not be found. Please check the name and try again. Expected Results: See the website.
Can you visit those sites in Safari?
Yes, without any problems. Firefox 126.96.36.199 for OS X fails though.
There's a Core bug on enabling IPv6, or why we can't enable it, or something.
Ah, I found the discussion in bug 68796. Basically, OS X (at least up through some version of Panther) has some problems with IPv6 lookups, and as a result "network.dns.disableIPv6" is set to true by default for OS X in Mozilla products. You could try changing that to false in about:config, but be aware that unless the OS bug is fixed, you may see very long delays loading some sites. We should probably see where things stand with current OS versions; I'm having trouble finding a core bug where this has been looked at recently.
Well spotted :-) The network.dns.disableIPv6 set to "false" fixes the behaviour. I can see no visible degradation in performance to be perfectly honest but that is obviously just the sites I visit most often. Thank you!
Sorry, for reference this is OS X 10.4.9 (Intel) on an iMac 20" (2006, Core Duo).
Bug 96432 was the one I was thinking of, Stuart, and I guess where this should be duped? Bug 376226 implies there are still problems on 10.4/Intel in some cases, though.
I don't think it's a dup of 96432; that seems to be asking to do for all platforms what they did for OS X. I think we should probably just call this INVALID, since it does (at least sort of) work when enabled. If there were a tracking bug to re-enable for OS X I think it would make sense to dup to that, but since it seems to be blocked by an OS bug I'm not sure if there's a reason to have such a bug.
Please note that Bug 376226 can be easily solved: if you perform the DNS resolution elsewhere (e.g. Safari, host from the command line) then the IPv6 connection works. The issue appears to be with sites which have both an IPv4 _and_ IPv6 address defined. The sites in my example are IPv6 only and therefore work fine. So the bug in 376226 appears to be rather more interesting as it occurs if and only if the system resolver cache does not have a cached answer for the given website _and_ the website has both and IPv6 and IPv4 address.
Per irc, resolving this bug as INVALID since the pref exists and just needs to be flipped on an individual basis where required.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.