On Mon, 13 Dec 2021, Dmitry Karpov wrote:
Somehow, I didn't find ares_getaddrinfo() in libcurl code, so you probably meant ares_gethostbyname() used by Curl_resolver_getaddrinfo() in lib\asyn-ares.c, right?
Line 789: https://github.com/curl/curl/blob/f03cc1b7a693b03eddfed2b4c7f8b5fcba9a22e5/lib/asyn-ares.c#L789
my concern was that if we lowered it in c-ares, then it would not be aligned with the default 5s value expected from the resolv.conf on Linux systems anymore, which might be not a default behavior expected from a general-purpose resolver library.
That's a discussion for the c-ares mailing list! My personal view is that c-ares isn't bound to that timeout value.
But on the other hand, libcurl doesn't have to follow exactly the resolver library constraints (if it is agreed that having 5s default in c-ares to match the default value from resolv.conf is a must ), and it can use its own default DNS resolver value, which may be lower than the c-ares default value.
I think you can drop this line of thinking, switch to ares_getaddrinfo() and then if there are remaining timeout issues, they will be entirely in the c-ares camp.
If you insist on doing c-ares the old way, I agree that we can lower the timeout.
If it is agreed that changing the c-ares default timeout from 5s to some lower value and thus breaking its connection with the default value implied by resolv.conf is not a problem, then it is the best plan. Especially, if things can be done in parallel, which is very important for dual-stack and Happy Eyeballs.
c-ares details need to be taken to that mailing list. -- / 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.html
