bradh352
commented
6 months ago The description isn't exactly accurate about the behavior. See https://github.com/c-ares/c-ares/pull/551 for a better description, but basically a change was made in c-ares 1.20.0 to not go through the entire timeout sequence if we had at least a partial reply as it is very likely that it won't work. It still waits for the other address family to timeout or have some other issue on the current request. So if someone has tries=3, timeout=2s and 2 dns servers, it could take a minimum of 3*2*2 = 12 seconds (its actually more as there's an additional penalty per retry to the same server), vs if one address class returned in 100ms, it would take at most 2s to return the partial result since it would terminate the other address family's additional attempts.
Now, there apparently have been reported issues to glibc that does something similar to this as per https://man7.org/linux/man-pages/man5/resolv.conf.5.html:
single-request (since glibc 2.10)
Sets RES_SNGLKUP in _res.options. By default,
glibc performs IPv4 and IPv6 lookups in parallel
since glibc 2.9. Some appliance DNS servers cannot
handle these queries properly and make the requests
time out. This option disables the behavior and
makes glibc perform the IPv6 and IPv4 requests
sequentially (at the cost of some slowdown of the
resolving process).So likely before c-ares 1.20.0, the retries allowed this to eventually succeed in such an environment. Currently c-ares doesn't honor the glibc single-request option.
It would probably be good to know if this is what is really happening in your environment, a tcpdump/pcap would be useful. You should probably open a ticket in https://github.com/c-ares/c-ares/issues with your findings.
niconoe-
Tithugues
aptalca
beroset
Hi, and thank you for your awesome work!
I'm experiencing an issue with alpine
3.19when using curl: it seems that curl only tries to match IPv6 rather than being able to switch to the right IP version to connect. The thing is this doesn't look like to come from cURL itself, as on alpine3.18, it works like a charm.How to reproduce
Alpine 3.19 (curl classic)
Alpine 3.19 (curl with --ipv4 option)
Alpine 3.18 (curl classic)
As you can see, the curl version is exactly the same between all tests (8.5.0-r0) but still, there's a difference between Alpine 3.18 and Alpine 3.19.
I expect the
curlcommand from Alpine 3.19 to work as expected without the requiring need to force ipv4.If you need more info, fell free to ask. Thanks a lot
EDIT: after a very short investigation, I can see that Alpine 3.19 is now adding
c-ares=1.22.1-r0as a dependency of cURL, and I just discovered that https://github.com/c-ares/c-ares/issues/652 could be related: AFAIK, when cURL tries to resolve the DNS, it tries with both IPv4 or IPv6 by default, and takes the faster match.c-aresis here to help cURL doing that in parallel so that the DNS resolution between both IPv4 or IPv6 is parallelized, resulting in faster cURL calls. But with the issue I just linked above, it looks like when multiple DNS researches are given and one fail, it gives the failure status definitly. Therefore, as the IPv6 fails faster than IPv4 is resolved,c-areswrongly says to cURL that the host is unreachable. I'm not 100% sure about this, but I think it deserves to take a look. I wasn't able to removec-aresand give it a try without it.