Yes, I generally agree with all that you've said .. having implemented
some code using "GetBestInterfaceEx" in the past I realize there are
some shortcomings even after that patch I put in.
I was not really trying to fix all the issues, just my urgent one at the
moment :)
And yes, I am working on an old version. So for the time being I have
just patched my old version but I think the code should be added in the
current version somewhere if need be.
There was a lengthy MSDN article I found somewhere, let me see if I can
locate it again..
Yes, here it is:
http://technet.microsoft.com/en-us/library/dd197552%28WS.10%29.aspx
Part 2 has several diagrams about the process involved in the windows
operating system (assuming you use their APIs) in order to determine the
correct DNS server to query. Probably the diagram labelled "Querying the
DNS Server, Part 3" is the most relevant?
I think ideally we should implement some kind of state machine like this
in order to "fully" remedy the problem. But it's kind of outside the
scope of my patch (at least until another customer complains about it
that is, haha)..
In my case (for this bug) the query was simply failing, never mind the 5
seconds delay.. Then again I have a little bit older version of c-ares
as you mentioned.
David
On 13-01-09 08:43 AM, Gisle Vanem wrote:
> "David Stuart" <dstuart_at_counterpath.com> wrote:
>
>> In the method "get_iphlpapi_dns_info" inside of "ares_init.c", instead
>> of this:
>
> Your customer surely has an old version of C-ares. There's is no
> get_iphlpapi_dns_info() in Git now. Renamed approx. 1 year to
> get_DNS_AdaptersAddresses(). But upgrading wont help.
>
>> Shouldn't it be:
>>
>> /* process the results */
>> for( pEntry = pFirstEntry ; pEntry != NULL ; pEntry = pEntry->Next )
>> {
>> IP_ADAPTER_DNS_SERVER_ADDRESS* pDNSAddr = NULL;
>> if( pEntry->OperStatus != IfOperStatusUp )
>> continue;
>>
>> pDNSAddr = pEntry->FirstDnsServerAddress;
>> for( ; pDNSAddr != NULL ; pDNSAddr = pDNSAddr->Next )
>> {
>> struct sockaddr *pGenericAddr = pDNSAddr->Address.lpSockaddr;
>> int stringlen = 0;
>>
>>
>> We have a customer complaining about enabled (but not connected)
>> interfaces being used for their DNS configuration, and I suspect this
>> might be the culprit.
>
> I think I agree.
> I searched MSDN / IpHlpAPI to figure out if Windows sets the state of
> DNS-server on a *connected* adapter. But didn't find any way. So the
> best way would IMHO simply to ensure 'ipaaEntry->OperStatus ==
> IfOperStatusUp' .
> Ref:
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa366058(v=vs.85).aspx
>
>
> But there is still problems in C-ares after this change. C-ares simply
> ignores the best interface to use for any given resolution. I.e. when I
> bring my Wireless or VPN-adapter down, C-ares still uses the DNS-
> server(s) for these down adapters. My Wireless uses Google's DNS
> at 8.8.* so C-ares programs still works off-cource.
>
> It just selects the DNS address(es) string ('outptr') given to
> config_nameserver() in a first-to-last loop. With no regard for the best
> interface. We could do better on Windows by using 'GetBestInterface' or
> 'GetBestInterfaceEx' (IP4+6) for for
> each lookup, but then things gets complicated. Even more so when
> adapters and link-state changes (back from sleep-mode, etc.).
> I've added some tracing to ares_init.c and ran 'acountry.exe www.vg.no':
>
> get_DNS_AdaptersAddresses:
> adapter 0, srv 0, stat 2, fam 2, descr NETGEAR WG111v2 54Mbps Wi:
> 8.8.8.8. Adapter down.
> adapter 0, srv 1, stat 2, fam 2, descr NETGEAR WG111v2 54Mbps Wi:
> 8.8.4.4. Adapter down.
> adapter 1, srv 0, stat 1, fam 2, descr Realtek PCIe GBE Family C:
> 217.13.7.140
> adapter 1, srv 1, stat 1, fam 2, descr Realtek PCIe GBE Family C:
> 217.13.4.24
> adapter 2, srv 0, stat 1, fam 2, descr WAN (PPP/SLIP) Interface :
> 98.158.112.60 << the VPN
> adapter 2, srv 1, stat 1, fam 2, descr WAN (PPP/SLIP) Interface :
> 199.127.248.22 << the VPN
> << hanging here for 5 sec >>
> Norway (no), number 578.
>
> Thus with your patch 'ares_init()' will add 1st DNS on adapter 1 to
> 'outptr'
> (217.13.7.140 is at my ISP). BUT my default route is via my VPN-adapter
> at index 2. All route destinations (except the fixed route-entries)
> should go over the VPN. Especially the DNS lookups. That's why people
> uses VPNs.
>
> Since the DNS at my ISP ignores non-customers, the lookup hangs approx.
> 5 sec. waiting before trying the next DNS at my VPN provider (which
> C-ares should have tried in the first place). Is the 5 sec. hang what
> your customer sees?
>
> --gv
-- 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 2P5Received on 2013-01-09