Mac OSX 10.7

Jeroen Massar jeroen at unfix.org
Thu Jul 21 13:30:30 CEST 2011


On 2011-07-21 13:01 , Tim Chown wrote:
> 
> On 20 Jul 2011, at 17:01, Jeroen Massar wrote:
> 
>> On 2011-07-20 17:05 , Iljitsch van Beijnum wrote: [..]
>>>> Let's say what else 10.7 has, but so far it looks good.
>>> 
>>> RFC 3484 policy table support? (Try ip6addrctl)
>> 
>> Where is that one, as I can't seem to ssh outbound anymore without
>> it going for IPv4 first..... grmbl
> 
> I'm seeing preference for IPv6 for http and ssh here in Lion, when
> both A and AAAA records are returned quickly for the target.

The fun thing is Chrome and Safari do IPv6 just fine. Only app I found
that just defaults to IPv4 is SSH it seems.

> Previous to Lion the IP version choice seemed dictated by the
> ordering of the A and AAAA responses, so if you got an A back first
> then IPv4 was used (and to force IPv6 you could ping6 the target).

In Snow Leopard everything for IPv6 worked for me.

The only fun issue I encountered in SL was running an AFP server on an
IPv4 only address and SL then not bothering to ask DNS for an AAAA
record. Enabling the IPv6 flag on the AFP server resolved that one though.

> I wonder if they've done something 'happy eyeballs'-like with the
> responses now, so if the A and AAAA records come back quickly enough
> there's a preference for IPv6, otherwise the received data is used,
> be that A or AAAA?   Or are you seeing fast DNS reposes for A and
> AAAA Jeroen?

They are even in the local cache (sudo killall -INFO mDNSResponder; tail
-n <lot> /var/log/system.log

And timing wise they should come back at the same time from the same
server. I am still a bit confused about how when you do both an AAAA and
then an A request, that the A request answer could come back quicker
than the AAAA one, especially given that one is querying the same remote
server, but I must be missing something silly there ;)

So, I just tested with a "kill -USR2 -mDNSResponder" and then did an SSH
(I stripped the front a bit as it was the same anyway (thus in the same
single-second also)

-- Sent UDP DNS Query (flags 0100) RCODE: NoErr (0) RD ID: 51092 23
bytes from port 54032 to 198.18.99.41:53 --
 1 Questions
 0 abaddon.unfix.org. Addr
 0 Answers
 0 Authorities
 0 Additionals
--------------
-- Sent UDP DNS Query (flags 0100) RCODE: NoErr (0) RD ID: 15639 23
bytes from port 51617 to 198.18.99.41:53 --
 1 Questions
 0 abaddon.unfix.org. AAAA
 0 Answers
 0 Authorities
 0 Additionals
--------------
-- Received UDP DNS Response (flags 8180) RCODE: NoErr (0) RD RA ID:
51092 130 bytes from 198.18.99.41:53 to 198.18.99.55:54032 --
 1 Questions
 0 abaddon.unfix.org. Addr
 1 Answers
 0 TTL    3600    4 abaddon.unfix.org. Addr 62.220.146.203
 3 Authorities
 0 TTL    3600   18 unfix.org. NS ns.paphosting.nl.
 1 TTL    3600   18 unfix.org. NS ns.paphosting.eu.
 2 TTL    3600   19 unfix.org. NS ns.paphosting.net.
 0 Additionals
--------------
-- Received UDP DNS Response (flags 8180) RCODE: NoErr (0) RD RA ID:
15639 142 bytes from 198.18.99.41:53 to 198.18.99.55:51617 --
 1 Questions
 0 abaddon.unfix.org. AAAA
 1 Answers
 0 TTL    3600   16 abaddon.unfix.org. AAAA
2001:0788:0002:0117:0000:0000:0000:0203
 3 Authorities
 0 TTL    3600   18 unfix.org. NS ns.paphosting.nl.
 1 TTL    3600   18 unfix.org. NS ns.paphosting.eu.
 2 TTL    3600   19 unfix.org. NS ns.paphosting.net.
 0 Additionals
--------------

According to that there is first an "Addr" query, I assume a "A" record
query, then an IPv6/AAAA one, they probably just nearly race eachother
and as the A was asked first it is of course returned first.

Keeping an eye on the log though, I sometimes see the AAAA answered
before the A, which is well, weird, seeing that the recursive DNS cache
for those labels is sitting only a few ms away, it would mean that
unbound handles requests async or so ;)

> I guess whatever their mechanism is is no longer 'secret' within the
> beta, so we ought to be able to get some public confirmation from
> Apple.

Which 'beta' would that be?

The real solution to this all is 'simple':
 - Working RFC3484 support (an RFC from 2003...)
 - Clarity / Documentation on how resolving really works in OSX
   (seems everything goes through mDNSresolver with then lots of magic)
 - A toggle to tweak this thing as defined in RFC3484
   eg ala /etc/gai.conf would be awesome

Greets,
 Jeroen


More information about the ipv6-ops mailing list