Dear c-ares,
I've been hearing about some incidents in the field where our combined libcurl/c-ares 7.19.5/1.6.0 are not behaving correctly. In our curl-using app, we try to resolve a certain internal DNS name, and the lookup fails immediately with with a CURLE_COULDNT_RESOLVE_HOST.
I got to play with an affected Windows machine, a laptop, and its network layout was as such:
- LAN connection (connected to our intranet)
- Wireless connection ("Not Connected" state - laptop wireless killswitch active)
After some futzing around, we ended up disabling the wireless connection via the Windows network connections control panel. And suddenly the problem went away, behavior returned to normal. Even after reenabling the wireless connection, de-killswitching it, etc., it still worked.
My hypothesis about this strange incident is that there was some kind of DNS server ordering issue that occurred because of the wireless connection being enabled yet not connected (and it used to be connected to a valid AP before.) So I have some questions:
1) How smart does c-ares try to be about determining which servers to use for resolving a given name? Is this problem one you have experienced before?
2) Defining CURLDEBUG in c-ares doesn't seem to print out the appropriate nameserver ordering for every c-ares instance. Is there a way to get that information printed out? It looks like ares_init.c is the right place to print out such things; should I iterate through channel->servers after all the init_by_* functions have been called?
Thanks,
Josh
Received on 2009-08-04