Subject: Re: ares_gethostbyname fails to resolve localhost with AF_INET6

Re: ares_gethostbyname fails to resolve localhost with AF_INET6

From: Uli <ToBeSpammed_at_web.de>
Date: Sat, 04 Jun 2011 17:41:07 +0200

Hi,

I just wanted to mention that RFC 3484 [42] defines rules about when to use
IPv4/v6 and which of many possible addresses to use for the communication
together with a mechanism for administrators to influence this algorithm.

However, I know of no implementations with c-ares and I bet it wouldn't be easy.
Especially if you also want to handle stuff like /etc/gai.conf... :-(

Cheers,
Uli

P.S.:
By that RFC, v6 would be preferred by default if both v6 and v4 are available.

[42] http://tools.ietf.org/html/rfc3484

On 04.06.2011 03:18, Charlie Fenton wrote:
> I have also developed a more extensive patch, which will always try IPv4 first and retry with IPv6 only if the IPv4 lookup failed.
>
> If I understand correctly, IPv6 was introduced to allow more Internet domains when all IPv4 addresses are exhausted, but currently only a small percentage of domains have actually gotten an IPv6 address. And few, if any, domains have only an IPv6 address at this time. So trying IPv6 first will require a second lookup far more often than if we look up IPv4 first, which makes the current (IPv6 first) implementation in c-ares less efficient.
>
> Please let me know if you would like me to post the more extensive patch to this list.
>
> Cheers,
> --Charlie
>
> --
> Charlie Fenton charlief_at_ssl.berkeley.edu
> BOINC / SETI_at_home Macintosh & Windows Programmer
> Space Sciences Laboratory
> UC Berkeley
>
>
>
> On Jun 2, 2011, at 4:33 AM, Charlie Fenton wrote:
>
>> I reported a long time ago that the fallback to IPv4 does not happen under certain circumstances. (I was dealing with problem reported by our users of BOINC on Mac OS X.)
>>
>> I have since determined the reason. The problem is that host_callback() in ares_gethostbyname.c falls back to IPv4 only for certain error codes, but the list of error codes is incomplete. I have fixed this on my local copy of c-ares 1.7.4 with the following patch, which falls back to IPv4 for any error from the IPv6 attempt:
>>
>> @@ -208,8 +208,7 @@
>> }
>> end_hquery(hquery, status, host);
>> }
>> - else if ((status == ARES_ENODATA || status == ARES_EBADRESP ||
>> - status == ARES_ETIMEOUT) && hquery->sent_family == AF_INET6)
>> + else if (hquery->sent_family == AF_INET6) /* Modified for BOINC */
>> {
>> /* The AAAA query yielded no useful result. Now look up an A instead.
>> We should possibly limit this attempt-next logic to AF_UNSPEC lookups
>>
>> I hope this helps.
>>
>> Cheers,
>> --Charlie
>>
>>> From: Sebastian Ramacher <s.ramacher_at_gmx.at>
>>> Date: June 1, 2011 3:34:49 PM PDT
>>> To: c-ares_at_cool.haxx.se
>>> Subject: ares_gethostbyname fails to resolve localhost with AF_INET6
>>> Reply-To: c-ares hacking <c-ares_at_cool.haxx.se>
>>>
>>>
>>> Hi,
>>>
>>> Since my first mail didn't seem to reach the list - it can't be found in the
>>> list archive - I'm resending it. I'm sorry if you got it twice.
>>>
>>> As I understand the source ares_gethostbyname together with AF_INET6 falls back
>>> to AF_INET if no IPv6 address can be found (at least if a DNS server is
>>> queried). But this does not seem to be true for hosts in /etc/hosts. For example
>>> localhost fails to resolve with ares_gethostname together with AF_INET6.
>>>
>>> As some programs depend on this fallback behavior (znc for example) it would be
>>> nice to have the same for hosts defined in /etc/hosts. A possible fix would be
>>> to do the following in next_lookup: if file_lookup fails with AF_INET6 retry
>>> with AF_INET.
>>>
>>> Kind regards,
>>> --
>>> Sebastian Ramacher
>> --
>> Charlie Fenton charlief_at_ssl.berkeley.edu
>> BOINC / SETI_at_home Macintosh & Windows Programmer
>> Space Sciences Laboratory
>> UC Berkeley

-- 
Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?
Received on 2011-06-04