Safari 7.0 can't access to ipv6 address whereas Chrome can do

I confirm Safari isn't issuing AAAA queries in my setup, while Mail.app does, ping6 does, host does and telnet does.

Chrome, however, isn't issuing AAAA queries either, for me.

I have ipv6 connectivity (a darknet) but its tun interface doesn't show up in the Network System Preference pane.

a friend of mine has the same symptoms as zhaoweir.

Also Firefox and Subversion cannot access ipv6 sites. It seems that subversion uses APR to resolve names, but don't know if the browsers use it too. This is a really annoying problem...

It seems mDNSResponder will only query for IPv6 address on interfaces with an IPv6 address in System Preferences. Since aiccu tunnels don't show up in System Preferences the IPv6 connection is not detected.

This seems to be by design, I don't know how to resolve it. FWIW, IPv6 works in Chrome for me, but not in Safari. I guess Chrome does its own DNS queries.

Dec  2 13:28:12 MacBook-Air.local mDNSResponder[59] : ShouldSuppressUnicastQuery: Query suppressed for ipv6.google.com., qtype AAAA, since DNS Configuration does not allow (req_A is true and req_AAAA is false) Dec  2 14:29:42 MacBook-Air.local mDNSResponder[59] : DNS Server . 8.8.4.4:53 0 Unscoped 0 1326  v4 !v6 !cell !DNSSECAware

Since this is one of the few places that mentions this problem, here's another one: https://www.sixxs.net/forum/?msg=setup-10869082

Oh, and after a forey through the ipv6-dev mailing list at apple, I've also got a hint at a workaround:

-- snip --

- How can I understand how the dns resolver is resolving ip addresses?

scutil —dns; look for

flags : Request A records, Request AAAA records

vs. just A records.

The moment this changes is the moment you have an IPv6 address on an “officially managed interface”. So despite having a tun0 with an IPv6 address and an inet6 default route it will not do AAAA lookups. Workaround: set the IPv6 configuration to “Manual” and just put a 2001:db8::1 in the address field of your wifi or ethernet.

-- snap --

In addition to the ipv6 address, I also had to add the prefix length of 64 to make it work, but now it does and I have ipv6 in Safari. Finally.

Sadly this is not a permanent workaround since as soon as I hit a spot where I have native ipv6 (and I don't want to use the tunnel then) I have to remove this manual configuration.

But at least it's a workaround.

I confirm this workaround works for me as well.

"luckily" I the only thing I use ipv6 for is the aforementioned darknet, so this is a very viable workaround for me.

Thanks!

I wonder what "officially managed interface" is? If I create a tunnel with OpenVPN (tun0 interface) I seems to be a non-officially managed interface. (no AAAA lookups with mDNSResponder)

In contrast, creating a tunnel with Cisco VPN Client (utun0 interface) it seems to be officially managed interface. All works perfect.

I'm not sure how, but if you could provide some kind of 'interface diff' maybe we can find out?

Both tunnel devices are detailed below. With OpenVPN tunnel mDNSResponder does not resolves AAAA. With Cisco VPN there is no problem. I can't see there significant differences.

OpenVPN Tunnel

tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500

inet 10.1.11.111 --> 10.1.11.112 netmask 0xffffffff

inet6 fe80::223:1111:1111:1108%tun0 prefixlen 64 scopeid 0x9

inet6 2a01:1111:1111:fe00:1:2:32:: prefixlen 64

nd6 options=1<PERFORMNUD>

open (pid 15397)

Cisco Tunnel

utun0: flags=80d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1406

inet 139.30.111.11 --> 139.30.111.11 netmask 0xffffffff

inet6 fe80::223:1111:1111:1108%utun0 prefixlen 64 scopeid 0x7

inet6 2001:111:111:1ff::1e prefixlen 128

nd6 options=1<PERFORMNUD>

Notice: Some numbers are replaces by 1s by me.

I believe it might depend on how the kernel extension used is written, but I haven't investigated it very much.

I have found another workaround. Turning on Apple's 6to4 interface (stf0) from network preferences will also trigger AAAA lookups by mDNSResponder. This is still a hack, I hope there is a way to make a device "managed" so that mDNSResponder will consider it.