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