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

Status: VERIFIED INVALID

(Camino Graveyard :: General, defect)

Description

[Arrigo Triulzi]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.2pre) Gecko/20070223 Camino/1.1b
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.2pre) 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.

Comment 1

[Stuart Morgan]

Can you visit those sites in Safari?

Comment 2

[Arrigo Triulzi]

Yes, without any problems.

Firefox 1.5.0.11 for OS X fails though.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

There's a Core bug on enabling IPv6, or why we can't enable it, or something.

Comment 4

[Stuart Morgan]

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.

Comment 5

[Arrigo Triulzi]

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!

Comment 6

[Arrigo Triulzi]

Sorry, for reference this is OS X 10.4.9 (Intel) on an iMac 20" (2006, Core Duo).

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 8

[Stuart Morgan]

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.

Comment 9

[Arrigo Triulzi]

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.

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Per irc, resolving this bug as INVALID since the pref exists and just needs to be flipped on an individual basis where required.