Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Happy Eyeballs doesn't seem to work with c-ares when IPv6 name servers on top of the name server list don't respond
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 25 Nov 2021 09:01:25 +0100 (CET)
On Thu, 25 Nov 2021, Dmitry Karpov via curl-library wrote:
> It seems the problem is that even though libcurl implements Happy Eyeballs
> for DNS queries and runs A and AAAA queries in parallel, c-ares still goes
> through the list of name servers as they are listed in the resolv.conf.
All the name resolver solutions libcurl uses performs the entire name resolve
phase first, before libcurl gets a chance to start trying to connect to the
first address. This makes a slow name resolve affect the starting point of all
connect attempts libcurl makes.
In an ideal world, libcurl could start trying to connect to addresses as they
trickle in from the DNS servers, but since they need to be sorted and provided
in a certain order, that's far easier said than done and the regular libc
getaddrinfo() API doesn't allow for it either.
> Is it possible to work around this issue somehow?
My immediate thought is that it needs to be dealt with in c-ares somehow. How
does the regular getaddrinfo() function behave in this situation?
Date: Thu, 25 Nov 2021 09:01:25 +0100 (CET)
On Thu, 25 Nov 2021, Dmitry Karpov via curl-library wrote:
> It seems the problem is that even though libcurl implements Happy Eyeballs
> for DNS queries and runs A and AAAA queries in parallel, c-ares still goes
> through the list of name servers as they are listed in the resolv.conf.
All the name resolver solutions libcurl uses performs the entire name resolve
phase first, before libcurl gets a chance to start trying to connect to the
first address. This makes a slow name resolve affect the starting point of all
connect attempts libcurl makes.
In an ideal world, libcurl could start trying to connect to addresses as they
trickle in from the DNS servers, but since they need to be sorted and provided
in a certain order, that's far easier said than done and the regular libc
getaddrinfo() API doesn't allow for it either.
> Is it possible to work around this issue somehow?
My immediate thought is that it needs to be dealt with in c-ares somehow. How
does the regular getaddrinfo() function behave in this situation?
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-11-25