curl / Mailing Lists / curl-library / Single Mail
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

From: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 14 Dec 2021 20:08:26 +0000

> https://github.com/curl/curl/blob/f03cc1b7a693b03eddfed2b4c7f8b5fcba9a22e5/lib/asyn-ares.c#L789

Ahh! I was looking into 7.66. curl code, so now I see how ares_getaddrinfo() is used.

> c-ares details need to be taken to that mailing list.

Yes, I agree that most of this discussion belongs to c-ares mailing list.
But the question remains whether libcurl should always rely on a default DNS timeout set by c-ares, whatever it is, instead of explicitly setting the "curl" one?

The concern is that different c-ares versions may have different default timeouts which can create inconsistent behavior and the snippet:

/* How long we are willing to wait for additional parallel responses after
   obtaining a "definitive" one.

   This is intended to equal the c-ares default timeout. cURL always uses that
   default value. Unfortunately, c-ares doesn't expose its default timeout in
   its API, but it is officially documented as 5 seconds.

   See query_completed_cb() for an explanation of how this is used.
 */
#define HAPPY_EYEBALLS_DNS_TIMEOUT 5000

makes tight coupling libcurl with c-ares default timeout.


Don't you think that it would be better to break this dependency and have something like:

#define DEFAULT_DNS_TIMEOUT 2000 // i.e. 2 seconds
...
#define HAPPY_EYEBALLS_DNS_TIMEOUT DEFAULT_DNS_TIMEOUT
...
Curl_resolver_init() {
...
      int optmask = ARES_OPT_SOCK_STATE_CB | ARES_OPT_TIMEOUTMS;
      ...
      options.timeout = DEFAULT_DNS_TIMEOUT;
      ...
}

This simple change will make libcurl DNS timeout consistent regardless if the default timeout changes in c-ares.

Thanks,
Dmitry Karpov


-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Monday, December 13, 2021 11:37 PM
To: Dmitry Karpov <dkarpov_at_roku.com>
Cc: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Subject: RE: Question about DNS timeout in libCurl

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
Received on 2021-12-14