dns: Resolver timeout seemingly doubled upon tries=1

[starrify]

Version

v26.7.0

Platform

`Linux 58e331aa718d 7.1.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 18 Jul 2026 17:30:57 +0000 x86_64 GNU/Linux`
(a Docker container of `node:26.7.0-trixie-slim`)

Also reproduces with:
- `node-v27.0.0-nightly20260816d099639740-linux-x64` (fetched https://nodejs.org/download/nightly/v27.0.0-nightly20260816d099639740/) with `Linux REDACTED 7.1.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 18 Jul 2026 17:30:57 +0000 x86_64 GNU/Linux`
- `v26.7.0` with `Linux REDACTED 7.1.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 18 Jul 2026 17:30:57 +0000 x86_64 GNU/Linux`

Subsystem

dns

What steps will reproduce the bug?

1. Initialize a Resolver with config { timeout: 1000, tries: 1, maxTimeout: 1000 }.
2. Configure your local network to block (drop) DNS traffic, or use a server netloc that won't respond (e.g. resolver.setServers(["1.1.1.1:9999"])) so that any query shall timeout.
3. Make a query (e.g. resolve4).

Here's a sample script:

const { Resolver } = require("dns");
const { promisify } = require("util");

(async () => {
  const resolver = new Resolver({ timeout: 1000, tries: 1, maxTimeout: 1000 });
  resolver.setServers(["1.1.1.1:9999"]);
  // expect ETIMEOUT here
  await promisify(resolver.resolve4.bind(resolver))("example.com");
})();

How often does it reproduce? Is there a required condition?

Every time. No required condition other than what's stated above.

What is the expected behavior? Why is that the expected behavior?

An ETIMEOUT shall raise after 1 second since it is configured so (both timeouts being 1000 and tries=1).

What do you see instead?

It takes 2 seconds to throw the timeout exception. E.g.:

$ time node a.js
node:internal/dns/callback_resolver:45
    this.callback(new DNSException(err, this.bindingName, this.hostname));
                  ^

Error: queryA ETIMEOUT example.com
    at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/callback_resolver:45:19) {
  errno: undefined,
  code: 'ETIMEOUT',
  syscall: 'queryA',
  hostname: 'example.com'
}

Node.js v26.7.0

real	0m2.013s
user	0m0.017s
sys	0m0.009s

Additional information

c-ares seems to work as expected

I then went checking c-ares with a small PoC code in C that configures the same (timeout=1000, tries=1, maxtimeout=1000). A query using ares_query_dnsrec failed due to timeout after slightly more than 1s (e.g. 1.001s) which is the expected outcome.

Also, other users of c-ares, like curl, appear to have their timeout triggered after 1s as well. E.g.:

$ time ./src/curl --dns-servers 1.1.1.1:9999 --connect-timeout 1 https://example.com/
curl: (28) Resolving timed out after 1001 milliseconds

real	0m1.014s
user	0m0.008s
sys	0m0.007s

Issue likely caused by the c-ares wrapper code (polling with a libuv timer)

Given the observation above, I started checking Node.js's wrapper code. Looks like it uses ARES_OPT_SOCK_STATE_CB and poll's c-ares for possible timeouts:

node/src/cares_wrap.cc

Lines 1002 to 1008 in ad7a5b8

	/* This is called once per second by loop->timer. It is used to constantly */
	/* call back into c-ares for possibly processing timeouts. */
	void ChannelWrap::AresTimeout(uv_timer_t* handle) {
	ChannelWrap* channel = static_cast<ChannelWrap*>(handle->data);
	CHECK_EQ(channel->timer_handle(), handle);
	ares_process_fd(channel->cares_channel(), ARES_SOCKET_BAD, ARES_SOCKET_BAD);
	}

Where the above ChannelWrap::AresTimeout callback is invoked by a libuv timer:

node/src/cares_wrap.cc

Lines 1074 to 1085 in ad7a5b8

	void ChannelWrap::StartTimer() {
	if (timer_handle_ == nullptr) {
	timer_handle_ = new uv_timer_t();
	timer_handle_->data = static_cast<void*>(this);
	uv_timer_init(env()->event_loop(), timer_handle_);
	} else if (uv_is_active(reinterpret_cast<uv_handle_t*>(timer_handle_))) {
	return;
	}
	int timeout = timeout_;
	if (timeout <= 0 || timeout > 1000) timeout = 1000;
	uv_timer_start(timer_handle_, AresTimeout, timeout, timeout);
	}

This may explain the issue already. The design here IMHO relies on precise synchronization that is not guaranteed. Here's a sample sequence of events that may cause the issue here:

1. libuv's timer fires at 1s (while c-ares's query has not yet timed out).
2. After a short amount of time (e.g. a few microseconds or even shorter) the query from c-ares's end timed out.
3. However Node.js does not seem to be able to pick that timeout up until the next time that libuv timer fires, which is at around 2s.

Possible fix

Given the knowledge of c-ares's implement, maybe configure the polling timer in a way that better catches upstream timeouts, like to delay the call of ChannelWrap::StartTimer by a small amount like 100us or 1ms?

Or, maybe move to ARES_OPT_EVENT_THREAD (instead of ARES_OPT_SOCK_STATE_CB) so that explicit ares_process_fd calls are no longer needed (ares_query_dnsrec callbacks would be invoked on c-ares's event thread, in which Node.js's code shall then post the task to libuv's event loop). This should look better IMHO but moving to ARES_OPT_EVENT_THREAD requires further changes than fixing this timeout issue alone.

[starrify]

With a local build I was able to locate the actual cause of issue: libuv's event loop time upon calling ChannelWrap::StartTimer may be late by 10~30 ms (on my local machine). The timer's callback would then fire earlier by that disparity, which is large enough to miss the timeout calculation from c-ares.

A local build with uv_update_time called before starting the timer resolves this issue. A sample patch as of ad7a5b8:

diff --git a/src/cares_wrap.cc b/src/cares_wrap.cc
index bf47c239abb..55e210386b2 100644
--- a/src/cares_wrap.cc
+++ b/src/cares_wrap.cc
@@ -1081,6 +1081,7 @@ void ChannelWrap::StartTimer() {
   }
   int timeout = timeout_;
   if (timeout <= 0 || timeout > 1000) timeout = 1000;
+  uv_update_time(env()->event_loop());
   uv_timer_start(timer_handle_, AresTimeout, timeout, timeout);
 }