dns: Resolver timeout seemingly doubled upon tries=1

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: https://github.com/nodejs/node/blob/ad7a5b8302ae54b6e6dc77e03eabc5a3218dfb85/src/cares_wrap.cc#L1002-L1008

Where the above ChannelWrap::AresTimeout callback is invoked by a libuv timer: https://github.com/nodejs/node/blob/ad7a5b8302ae54b6e6dc77e03eabc5a3218dfb85/src/cares_wrap.cc#L1074-L1085

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.

Start in src/cares_wrap.cc, especially ChannelWrap::AresTimeout, the polling setup, and ChannelWrap::StartTimer. Reproduce the issue with the provided Resolver script and 1.1.1.1:9999, then trace the c-ares and libuv timer sequence. Done means the configured tries=1, timeout=1000 query raises ETIMEOUT at about one second rather than two.