Closed Bug 377282 Opened 14 years ago Closed 14 years ago

Camino appears to be unable to resolve AAAA records / connect to IPv6 sites


(Camino Graveyard :: General, defect)

Not set


(Not tracked)



(Reporter: arrigo, Unassigned)




User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv: Gecko/20070223 Camino/1.1b
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv: Gecko/20070223 Camino/1.1b

If I try to surf websites which only have AAAA records, e.g.:

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 is an alias for is an alias for has IPv6 address 2001:1418:13:7::1001

anacleto:~$ host is an alias for is an alias for has IPv6 address 2001:1418:13:7::1

The system is IPv6-enabled and connected to IPv6:

traceroute6 to (2001:1418:13:7::1001) from 2001:1418:13:6:216:cbff:fe84:bf37, 30 hops max, 12 byte packets
 1  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 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,
Actual Results:  
Get error message:

Address Not Found 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 for OS X fails though.
There's a Core bug on enabling IPv6, or why we can't enable it, or something.
Whiteboard: DUPEME
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.
Group: security
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.
Group: security
Per irc, resolving this bug as INVALID since the pref exists and just needs to be flipped on an individual basis where required.
Closed: 14 years ago
Resolution: --- → INVALID
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.