I was working with curl with c-ares, when discovered a problem that
non-fully qualified domain names fail to be resolved. For some reason
c-ares fails to fall back to IPv4 when the IPv6 lookup doesn't bring
any result.
My knowledge of c-ares is extremely limited, all that I found is that
in "host_callback" function in ares_gethostbyname.c the lookup fails
to falls back to IPv4 as a result of failing the condition
else if ((status == ARES_ENODATA || status == ARES_EBADRESP || status
== ARES_ETIMEOUT ) && hquery->sent_family == AF_INET6)
due to the fact that status is ARES_ECONNREFUSED.
Why this status is set isn't really clear for me due to my limited
knowledge of the DNS lookup mechanism in c-ares. I tried to check the
responses from the servers and in process_answer function in
ares_process.c if found that response code rcode is always SERVFAIL
when the non-fully qualified domain name is send.
c-ares sends several requests when resolving a non-fqdn - first it
appends default domains found in the resolver configuration and sends
resulting fqdn with IPv6. At this point there is neither SERVFAIL nor
ARES_ECONNREFUSED. Then the original non-fqdn name is send, still with
IPv6, and here the failure occurs.
When a proper fqdn is resolved, no SERVFAIL or ARES_ECONNREFUSED
happens during IPv6 resolution stage so it falls back to IPv4 in
host_callback.
What might be a solution for this problem? First of all, the obvious
hack of adding ARES_ECONNREFUSED to the condition in host_callback
does the trick - the resolution falls back to IPv4. However I have no
idea what might be a consequences of this.
May be one of the status codes used for the fallback should be set
when SERVFAIL is received, e.g. to set the status ARES_EBADRESP? In
fact the connection wasn't refused, only the server didn't hand off
any meaningful response.
Or may be a non-fqdn shouldn't ever be send to the server? Are there
any name resolvers that can do this?
Thank you,
Martin
Received on 2010-08-05