You're of course free to do whatever you want. Let me just clarify a few things for the record.

First, libcurl and curl do IPv6 really good with the other two resolver backends (the "stock" and the threaded backends) because as I've said already: this IPv6 problem with c-ares is really due to c-ares' inability and not really libcurl's. It is not libcurl's job to do the actual resolving, that's job for the resolver functions libcurl uses.

Secondly, I know all this and I'm fully aware of the situation and you seem to mistake a previous discussion with me: *I* am the maintainer of c-ares as well and any IPv6 related thread you may have found me discussing in was probably with one of the contributors who brought the IPv6 support c-ares provides. I don't think we've ever considered it to be complete, but me and my fellow c-ares developers will GREATLY appreciate any help or patches we can get to improve the situation. As the fix NEEDS to be done in c-ares for it to be done properly, accurately and not in a kludgey way.

I'm sorry I'm not able to fix this myself but my TODO list is very long and IPv6 with c-ares is not a problem that hurt me personally very much. I work on both these projects for the fun of it on my spare time.

---
** [bugs:#1283] curl c-ares ipv6 search order incorrect**
**Status:** open
**Labels:** ipv6 
**Created:** Tue Sep 24, 2013 08:43 PM UTC by John Gardiner Myers
**Last Updated:** Fri Oct 04, 2013 06:01 PM UTC
**Owner:** Daniel Stenberg
Curl when compiled with c-ares and IPv6 support on a host that can create IPv6 sockets performs queries for hostnames in URLs in the wrong order.
With the /etc/resolv.conf:
search eng.proofpoint.com us.proofpoint.com corp.proofpoint.com lab.proofpoint.com spt.proofpoint.com proofpoint.com
nameserver 10.20.1.4
the command:
curl http://update2.proofpoint.com/
produces the following sequence of DNS queries:
13:35:59.240390 IP 10.22.60.14.55727 > 10.20.1.4.domain:  15948+ AAAA? update2.proofpoint.com.eng.proofpoint.com. (59)
13:35:59.241002 IP 10.20.1.4.domain > 10.22.60.14.55727:  15948 NXDomain* 0/1/0 (107)
13:35:59.241051 IP 10.22.60.14.56052 > 10.20.1.4.domain:  13748+ AAAA? update2.proofpoint.com.us.proofpoint.com. (58)
13:35:59.241699 IP 10.20.1.4.domain > 10.22.60.14.56052:  13748 NXDomain* 0/1/0 (103)
13:35:59.241747 IP 10.22.60.14.50248 > 10.20.1.4.domain:  36122+ AAAA? update2.proofpoint.com.corp.proofpoint.com. (60)
13:35:59.242293 IP 10.20.1.4.domain > 10.22.60.14.50248:  36122 NXDomain* 0/1/0 (116)
13:35:59.242346 IP 10.22.60.14.54461 > 10.20.1.4.domain:  27439+ AAAA? update2.proofpoint.com.lab.proofpoint.com. (59)
13:35:59.243529 IP 10.20.1.4.domain > 10.22.60.14.54461:  27439 NXDomain 0/1/0 (104)
13:35:59.243624 IP 10.22.60.14.57020 > 10.20.1.4.domain:  20176+ AAAA? update2.proofpoint.com.spt.proofpoint.com. (59)
13:35:59.244165 IP 10.20.1.4.domain > 10.22.60.14.57020:  20176 NXDomain 0/1/0 (116)
13:35:59.244216 IP 10.22.60.14.38387 > 10.20.1.4.domain:  17259+ AAAA? update2.proofpoint.com.proofpoint.com. (55)
13:35:59.244835 IP 10.20.1.4.domain > 10.22.60.14.38387:  17259 NXDomain 0/1/0 (99)
13:35:59.244981 IP 10.22.60.14.36776 > 10.20.1.4.domain:  11091+ A? update2.proofpoint.com. (40)
13:35:59.245525 IP 10.20.1.4.domain > 10.22.60.14.36776:  11091* 1/2/2 A 10.20.1.131 (127)
In short, it exhaustively queries each of the domains in the search path for AAAA records before querying for any A records.
Furthermore, if any of those intermediate AAAA queries returns SERVFAIL, the entire query will fail and the A record will never be used.
Per my reading of RFC 1738 section 3.1, the search path shouldn't even be used. Curl certainly shouldn't prefer or even use an AAAA record further down the search path if at least one A record on the input FQDN or earlier in the search path exists.
curl 7.32.0 (x86_64-unknown-linux-gnu) libcurl/7.32.0 OpenSSL/0.9.8b zlib/1.2.3 c-ares/1.10.0 libidn/0.6.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS Debug TrackMemory IDN IPv6 Largefile NTLM NTLM_WB SSL libz
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.