Subject: Re: c-ares patch

Re: c-ares patch

From: Gisle Vanem <gvanem_at_broadpark.no>
Date: Wed, 09 Jan 2013 14:43:44 +0100

"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
Received on 2013-01-09