Mac OSX 10.7

[Jeroen Massar]

On 2011-07-21 13:33 , Gert Doering wrote:
> Hi,
> 
> On Thu, Jul 21, 2011 at 01:30:30PM +0200, Jeroen Massar wrote:
>> 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 ;)
> 
> If the query goes through intermediate caches, and someone *else* queried
> for "just A" before you, that could explain things...

Agreed.

> Otherwise, hard to see a reason, yes.

Indeed, which is what is the case here in my setup:

Mac OSX Lion -> Unbound on a Linux box -> $Internet

and I know that the answers are still in the cache both locally (kill
-INFO mDNSResponder) and in unbound, (dig and checking TTLs) and a
second query for the same host, even if it already has an AAAA record,
will simply keep returning that A record.

And even a 'ping6 -c 1 <host>; ping -c 1 <host; ssh -v <host>" when thus
the addresses are also cached and the IPv6 one before the IPv4 one, will
just connect on v4....

Reading around, I think the portion which messes it up is here:
http://www.opensource.apple.com/source/Libinfo/Libinfo-391/

_mdns_search in lookup.subproj/mdns_module.c
8<----------------------------------------------------------------------
// Timeout Logic
// The kevent(2) API timeout parameter is used to enforce the total
// timeout of the DNS query. Each iteraion recalculates the relative
// timeout based on the desired end time (total timeout from origin).
//
// In order to workaround some DNS configurations that do not return
// responses for AAAA queries, parallel queries modify the total
// timeout upon receipt of the first response. The new total timeout is
// set to an effective value of 2N where N is the time taken to receive
// the A response (the original total timeout is preserved if 2N would
// have exceeded it). However, since mDNSResponder caches values, a
// minimum value of 50ms for N is enforced in order to give some time
// for the receipt of a AAAA response.
---------------------------------------------------------------------->8

The biggest change there though, solely is:
8<----------------------------------------------------------------------
1838,1839c1373
<       if (timeout_sec == 0) timeout_sec = RES_MAXRETRANS;
<       delta.tv_sec = timeout_sec;
---
>       delta.tv_sec = RES_MAXRETRANS + 5;
---------------------------------------------------------------------->8

Which could just tip the timing enough if the timeout was before by
something else which set it much bigger than RES_MAXRETRANS. But that
timeout_sec came from the resolver->timeout which does not get set
anywhere in the code from what I could find.

The return of that goes to si_addrinfo_list_from_hostent() which lists
IPv6 first then IPv4. As such my only conclusion is that IPv6 addresses
are not being included there.

Also interesting:
8<----------------------------------------------------------------------
diff -r Libinfo-330.10/gen.subproj/ifaddrs.h
Libinfo-391/gen.subproj/ifaddrs.h
1c1
< /*    $KAME: ifaddrs.h,v 1.3 2001/01/26 08:14:55 itojun Exp $ */
---
> /*    $FreeBSD: src/include/ifaddrs.h,v 1.3.32.1.4.1 2010/06/14
02:09:06 kensmith Exp $       */
---------------------------------------------------------------------->8

So it seems they finally upgraded stuff from the KAME stack in 2001 to
at least some headers/funcs of the FreeBSD stack of 2010/06/14 or later
last year ;)

And from mDNSResponder:
http://opensource.apple.com/source/mDNSResponder/mDNSResponder-320.5/

a quick diff between the 320.5 and the previous 258.21 from SL is sort
of fruitless because too much changed and there is obviously no
documentation what changed where. One thing that I did notice is that
they changed the mDNS_KnownBug_LimitedIPv6 value dropping some
PhantomInterfaces issue which was oldish.


That LimitedIPv6 thing apparently is:

8<------------------------------------------------------------------------
// Unsolicited Neighbor Advertisements (RFC 2461 Section 7.2.6) give us
fast address cache updating,
// but some older IPv6 clients get confused by them, so for now we don't
send them. Without Unsolicited
// Neighbor Advertisements we have to rely on Neighbor Unreachability
Detection instead, which is slower.
// Given this, we'll do our best to wake for existing IPv6 connections,
but we don't want to encourage
// new ones for sleeping clients, so we'll we send deletions for our SPS
clients' AAAA records.
------------------------------------------------------------------------>8

and there is another usage because Samba did not do IPv6 on SL.

8<------------------------------------------------------------------------
// Special-case hack: On Mac OS X 10.6.x and earlier we don't advertise
SMB service in AutoTunnel domains,
// because AutoTunnel services have to support IPv6, and in Mac OS X
10.6.x the SMB server does not.
// <rdar://problem/5482322> BTMM: Don't advertise SMB with BTMM because
it doesn't support IPv6
------------------------------------------------------------------------>8

Probably the stuff that is related to this:

mDNSMacOSX/mDNSMacOSX.c:
8<------------------------------------------------------------------------
mDNSlocal void ReissueBlockedQuestions(mDNS *const m, domainname *d,
mDNSBool success)
        {
        // 1. We deliberately restart AAAA queries before A queries,
because in the common case where a BTTM host has
        //    a v6 address but no v4 address, we prefer the caller to
get the positive AAAA response before the A NXDOMAIN.
        // 2. In the case of AAAA queries, if our tunnel setup failed,
then we return a deliberate failure indication to the caller --
        //    even if the name does have a valid AAAA record, we don't
want clients trying to connect to it without a properly encrypted tunnel.
        // 3. For A queries we never fabricate failures -- if a BTTM
service is really using raw IPv4, then it doesn't need the IPv6 tunnel.
        ReissueBlockedQuestionWithType(m, d, success, kDNSType_AAAA);
        ReissueBlockedQuestionWithType(m, d, mDNStrue, kDNSType_A);
        }

------------------------------------------------------------------------>8

That first comment is questionable, as there should be a NOERROR if a
AAAA exists but the A does not exit. NXDOMAIN means that the whole label
does not exist. But maybe it is a workaround to broken boxes (but the
ones which do AAAA records correctly wont break on this, the other way
around though).


I am starting to wonder what all this 'autotunnel6' stuff is in the code
btw it is only present a bit in the core and then only in the mDNSMacOSX
portion. Not much that google turns up on it.


Anyway, hard to find where all of this really goes wrong, only the folks
who know how this thing works for real will probably know...

Greets,
 Jeroen