Re: lib/42405: libc: getaddrinfo() should perform T_A lookups before T_AAAA lookups, was: Resolver problems

[Chuck Swiger <cswiger%mac.com@localhost>]

On Dec 4, 2009, at 11:33 AM, der Mouse wrote:
>> "* 0.238% of users have useful IPv6 connectivity (and prefer IPv6)
>>  * 0.09% of users have broken IPv6 connectivity [...]"
> 
>> Approximately 2 or 3 users per thousand prefer IPv6, and
>> approximately 38% of these IPv6 users have broken connectivity,
> 
> Um...what reason do you have to think ("of these") that the 0.09% is a subset 
> of the 0.238%?

Google discusses their testing methodology earlier in the PDF.  Evidently they 
use signed JSON/AJAX background queries against two hosts called 
ipv4.ipv6-exp.l.google.com or dualstack.ipv6-exp.l.google.com to obtain data 
about IPv6 support; both hostnames have A records; only the latter has AAAA 
records.

> Indeed, given the contrast between "useful" and "broken", I'd read those as 
> being disjoint, absent indication to the
> contrary.  (I'd be interested in the percentage of users who have useful v6 
> but prefer v4, though I suspect it's difficult to determine.)

Oh, I see: you're suggesting the total amount of IPv6 traffic from their data 
was 0.238% + 0.09% aka ~0.33%, in which case the IPv6 broken number would work 
out to around 27%.  Perhaps that's right; I suppose someone could mail 
<sesse%google.com@localhost> to clarify, if that difference really matters, 
given the level of uncertainly for these #s anyway.

So far, the best proposal for a mechanism for users to decide whether their 
system should to do A, AAAA, or both forms of queries appears to be Henning 
Brauer's suggestion for /etc/resolv.conf used by OpenBSD.  I'd also like to 
thank UME-san for his feedback, as I recall he worked on this specific area 
back in 2005 for FreeBSD.  In particular, the suggestion:

> The KAME's getaddrinfo(3) has the workaround for this issue.  Query A
> 1st then query AAAA.  And, if got A, query AAAA with shorten timeout.
> AFAIK, Windows Vista does this manner as well.


...is also pretty close to what MacOSX does in Libinfo's 
_mdns_query_mDNSResponder(), which issues both A and AAAA queries in parallel 
for AF_UNSPEC case:

        // Timeout Logic
        // The kevent(2) API timeout parameter is used to enforce the total
        // timeout of the DNS query.  Each iteration 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.

I don't have a strong opinion about whether something like that should be in 
libc or use an external DNS caching daemon (mdnsd, lookupd, nscd, etc).  I do 
recall infrequent but drastic problems with DNS caching (only under Solaris and 
not IRIX), and there seem to be plenty of people wanting to use NetBSD for an 
embedded platform where running an external DNS cache daemon isn't really what 
you want.

Regards,
-- 
-Chuck