Docker Desktop 4.94.0 on Windows/WSL2: container IPv4 DNS A queries time out with internal DNS RPC DeadlineExceeded #742

Bug report

Expected / actual

Expected: normal IPv4 A-record resolution from a container using Docker Desktop's generated resolver.

Actual: A DNS queries to 192.168.65.7 time out. This behavior existed on 4.83.0 and persists on 4.94.0; this is not a claim that 4.94 introduced a regression. Root cause UNKNOWN.

Before the update, direct A queries over UDP and TCP timed out for packagist.org, repo.packagist.org, github.com and registry.npmjs.org. AAAA queries returned fast NOERROR / NODATA under ipv4only + auto. This is query-type asymmetry, not proof of IPv6 transport failure. Historical Windows host lookups succeeded slowly, not always simultaneously with container tests.

Minimal reproduction

Run this JavaScript with Node inside a normal default-bridge container, using its generated /etc/resolv.conf:

const { Resolver } = require('dns').promises;
const fs = require('fs');
const server = fs.readFileSync('/etc/resolv.conf', 'utf8')
  .match(/^nameserver\s+(\S+)/m)[1];
const resolver = new Resolver({ timeout: 5000, tries: 1 });
resolver.setServers([server]);
const start = Date.now();
resolver.resolve4('packagist.org').then(
  addresses => console.log({ server, addresses, ms: Date.now() - start }),
  error => {
    console.log({ server, error: error.code, ms: Date.now() - start });
    process.exitCode = 1;
  }
);

The code itself has no repository dependency; the observed run used an existing local immutable Node 24.21.0 image. A public node:24 image has not been tested; this report does not claim reproduction with it.

Correlated post-update evidence

The first A lookup after the upgrade began at 2026-10-12T11:45:27.344Z, returned ETIMEOUT after 5910 ms, and exited 1. Docker's internal DNS component subsequently logged:

2026-10-12T11:45:37.364900250Z component=dns
QUERY id=2956; packagist.org. IN A
rpc error: code = DeadlineExceeded desc = context deadline exceeded

The internal DNS component receives the A request, but its internal RPC does not complete before its deadline. Its recipient and deeper cause have not been identified. Client timeout and internal RPC deadline are distinct observations.

Restart / update already attempted

One normal Docker Desktop restart before the upgrade did not resolve the A timeout. A fresh official 4.94.0 installer matched the official SHA256 checksum and had Valid Authenticode with signer Docker Inc.; a normal in-place upgrade completed. The first post-update A lookup failed again. No restart loop, factory reset or manual uninstall/reinstall was performed.

No custom --dns, hosts override, DNS-server override, proxy override, VPN change, firewall change, IPv6 disable or network-mode workaround was used for this reproduction. Existing system proxy configuration was not changed; no proxy values are included here.

Related reports, not asserted duplicates

• com.docker.sailor leaks host UDP endpoints until the ephemeral port range is exhausted, breaking DNS host-wide (Windows, gvisor) #633 describes host UDP endpoint exhaustion on Hyper-V/gVisor, with DNS-over-TCP working and recovery after restart. Here WSL2 container A queries failed over UDP and TCP, and restart did not recover them. No same-root-cause claim.
• [Desktop] DNS interne 127.0.0.11 renvoie "server misbehaving" pour les conteneurs (Windows) #709 describes 127.0.0.11 SERVFAIL for internal service names on a custom network, unlike this default-bridge 192.168.65.7 external A-query timeout.

Questions for maintainers

Which internal service/RPC does Docker Desktop's gVisor DNS component use for IPv4 A-resolution on Windows/WSL2, and what supported diagnostic or remediation is recommended when that RPC reaches DeadlineExceeded?

Would maintainers like a Docker diagnostic upload / Diagnostic ID through an appropriate support channel?

Platform

Windows

Version information

• Docker Desktop: 4.94.0.241994; also affected: 4.83.0.234302.
• Engine: 29.8.2 after update.
• Windows 11 Home: 10.0.26300.9550.
• WSL: 2.5.10.0; kernel: 6.6.87.2-1.
• Context: desktop-linux.
• Effective configuration: defaultNetworkingMode = ipv4only, dnsInhibition = auto, networkType = gvisor.
• Container resolver: 192.168.65.7.

Diagnostics ID

Collected locally; not uploaded yet due privacy review.

An official docker desktop diagnose bundle has been collected locally, but has not been uploaded because it contains potentially sensitive environment information. I can provide a Diagnostic ID through an appropriate Docker support channel if requested.