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: Question about DNS timeout in libCurl
- 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: Tue, 14 Dec 2021 08:36:38 +0100 (CET)
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.
Date: Tue, 14 Dec 2021 08:36:38 +0100 (CET)
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.htmlReceived on 2021-12-14