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
