Re: [reSIProcate] resip, ares, and IPv6

[David Stuart <dstuart@xxxxxxxxxxxxxxx>]

Hi All,

Sadly even after moving everything to c-ares it seems that c-ares has a
similar (in fact identical) deficiency.

Basically I disable IPv4 and enable IPv6, and have a single statically
provisioned DNS server on IPv6. c-ares reports that there is 1 server,
but oddly enough it gives me the IPv4 server (though it is disabled),
and no mention of the IPv6 DNS server.

Looking at the code it's not clear to me where it's supposed to read the
configuration, since I don't see the same MS "IP Helper" approach taken
as resip-ares.

The loopback stuff I think can resolve well enough, by comparing to the
sentinel values which c-ares sets things to (but again, I don't see
where for IPv6 c-ares is setting up the ::1 value in this case).



On 11-05-12 12:16 PM, Scott Godin wrote:
> That flag is used in AresDns.cxx - the piece of code in Dave's email
> contains the "read" access to this variable.  The comments on the code
> fragment Dave pasted in explains the use.  I added the flag to be able to
> detect scenarios where the ares user may have provided 127.0.0.1 as the DNS
> servers, instead of ares just using loopback because no DNS servers were
> provided.
> 
> Scott
> 
> 
> On Thu, May 12, 2011 at 11:32 AM, Adam Roach <adam@xxxxxxxxxxx> wrote:
> 
>> On 5/12/11 10:07 AM, David Stuart wrote:
>>
>>> There's some code there that goes like this (and I
>>> hope this isn't one of our local patches, but if it is, oh well):
>>>
>>
>> I think it is. I did a grep over the public resip tree, and find no
>> references to "default_localhost_server" outside of ares_init.c and
>> ares_private.h.
>>
>>
>>  And of course, c-ares has no concept of "default_localhost_server"
>>> (whatever that is).
>>>
>>
>> The really odd thing is that it appears to be a write-only variable. None
>> of the ares code ever attempts to read it. I've copied Scott Godin on this
>> message, since he's the one who added the variable to the ares code; perhaps
>> he can explain what's going on here. :)
>>
>> In any case, the resip ares code basically has logic that says "if there
>> are no configured nameservers, then configure a single nameserver, and set
>> it to INADDR_LOOPBACK." If it does that, it also sets
>> default_localhost_server to 1.
>>
>> I don't know what c-ares would do in this case. If it has the same kind of
>> behavior (no servers == use loopback), then your approach of checking for
>> 127/8 (note: 127/8, not 127.0.0.1) or ::1 is probably correct. On the other
>> hand, if it doesn't have the "no servers == use loopback" logic, then you'd
>> want to check for "mChannel->nservers == 0" instead. You'll probably have to
>> read the c-ares code (or play around with it) to see which approach is
>> correct.
>>
>> /a
>>
>>  #ifdef WIN32
>>>    // For windows OSs it is uncommon to run a local DNS server.
>>> Therefore if there
>>>    // are no defined DNS servers in windows networking and ARES just
>>> returned the
>>>    // loopback address (ie. default localhost server / named)
>>>    // then put resip DNS resolution into hostfile lookup only mode
>>>    if(mChannel->nservers == 1&&
>>>       mChannel->servers[0].default_localhost_server)
>>>    {
>>>       // enable hostfile only lookup mode
>>>       mHostFileLookupOnlyMode = true;
>>>    }
>>>    else
>>>    {
>>>       // disable hostfile only lookup mode
>>>       mHostFileLookupOnlyMode = false;
>>>    }
>>> #endif
>>>
>>>
>>> So, any advice as to how to clear this hurdle would be appreciated.
>>> Should I look at the addr and try to compare it to 127.0.0.1 or ::1 ?
>>>
>>> Is this even the right place to ask about c-ares?
>>>
>>> David
>>>
>>>
>>> On 11-05-11 12:08 PM, Adam Roach wrote:
>>>
>>>> On 5/11/11 10:39 AM, David Stuart wrote:
>>>>
>>>>> OK, sounds reasonable.
>>>>>
>>>>> Does anyone recall why resip forked ares to begin with? What am I losing
>>>>> by switching over to c-ares?
>>>>>
>>>> The big reason for the fork is that ares had gone dead, and the original
>>>> maintaners did not respond to emails. Resip had to "fork" the dead code
>>>> just to fix bugs and add features. It's the same reason c-ares ended up
>>>> forking ares, although they've clearly had different enhancements added
>>>> since the fork.
>>>>
>>>> Here is Brad's list of features that resip-ares had but c-ares did not.
>>>> This refers to c-ares 1.5.3, and I know that Brad was working with the
>>>> c-ares team to get some features added, so this might not be completely
>>>> accurate any longer:
>>>>
>>>> On 11/22/08, Brad Spencer wrote:
>>>>
>>>>> I have identified a set of "obvious" features that resiprocate depends
>>>>> on simply by looking at the API differences between contrib/ares and
>>>>> c-ares.  I have not searched for embedded behavioural changes that may
>>>>> have been made to contrib/ares without API changes.  However,
>>>>> especially if c-ares vs contrib/ares were to remain a choice at
>>>>> configuration time, I think this is okay, at least as a starting point
>>>>> because c-ares "works".
>>>>>
>>>>> The attached patch will allow resiprocate to be configured against the
>>>>> trunk version of c-ares (1.5.3 + patches).  Of course, it still allows
>>>>> resiprocate to be configured to use contrib/ares as well.  With this
>>>>> patch against resiprocate-1.4.1, the following features are missing
>>>>> only when using c-ares:
>>>>>
>>>>>   1. TryServersOfNextNetworkUponRcode3
>>>>>
>>>>>     I've read the mailing list history on item 7, and I'm still
>>>>>     digesting that.  It seems to be only supported on Windows in the
>>>>>     current contrib/ares source, though.
>>>>>
>>>>>   2. AfterSocketCreationFuncPtr
>>>>>
>>>>>     I haven't been able to find much information about the purpose of
>>>>>     the AfterSocketCreationFuncPtr feature, except I found some note
>>>>>     about it being related to QoS.
>>>>>
>>>>>     Is there a reason only UDP sockets from ares are identified via
>>>>>     this function?  If I can supply the reasons this is important for
>>>>>     QoS, and we can figure out what to do about TCP, there's probably a
>>>>>     good argument to be made for adding an analogue of this to c-ares.
>>>>>
>>>>>   3. DNS servers with IPv6 addresses themselves
>>>>>
>>>>>     contrib/ares can have IPv4 and IPv6 addresses of DNS_servers_
>>>>>     configured (via the additionalNameservers argument and via built-in
>>>>>     config parsing), while c-ares can only contact IPv4 addressed DNS
>>>>>     servers at the moment.  Note that this has nothing to do with AAAA
>>>>>     record lookups, which work fine when using c-ares.
>>>>>
>>>>>     This seems like a good candidate for a new c-ares feature, and I
>>>>>     will ask about it on the c-ares list and report back.
>>>>>
>>>>>  After some quick poking around, I think #2 has been added to c-ares (as
>>>> of 1.6) and integrated into resip's c-ares support; and I think #3 is
>>>> fixed in c-ares (as of 1.7.1) but is not yet integrated.
>>>>
>>>> Derek MacDonald also pointed out that resip-ares had added some features
>>>> to multi-lan failover support when hosts have multiple configured
>>>> interfaces. I think that's what #1 in the list above means, but I can't
>>>> recall.
>>>>
>>>> Byron Campbell noted, back in 2008, that c-ares is substantially faster
>>>> than the resip version (it can do about twice as many DNS transactions
>>>> per second).
>>>>
>>>> /a
>>>>
>>>
>>
> 

-- 
David Stuart, CounterPath
Email: dstuart (at) counterpath (dot) com
Phone: (613) 254-8886 x2234  Web: http://www.counterpath.com/
Address: 310 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5