WSL DNS Tunneling: Resolving Through Windows Without a Fragile Virtual-Network Packet

DNS resolution failing specifically inside WSL while the same VPN connection works fine for every native Windows application is one of the most common WSL networking complaints, and it has a specific architectural cause that Microsoft addressed with a feature called DNS tunneling — worth understanding both for why the old behavior broke and what actually changes once tunneling is enabled.

Why classic WSL 2 networking struggled with DNS behind a VPN

In WSL 2’s original NAT-based networking model, DNS queries from inside a distribution are sent as ordinary UDP or TCP packets across WSL’s internal virtual network to a resolver address derived from the Windows host’s own DNS configuration. This works fine on an unencumbered network, but a VPN client that reroutes or firewalls traffic at a level below where WSL’s virtual network packets travel can block or misdirect these DNS packets specifically, even while the VPN otherwise correctly handles traffic from native Windows applications. The result is a distribution that can’t resolve hostnames at all, or resolves them incorrectly, purely because its DNS packets never actually reached a working resolver — a frustrating failure mode because everything else about the network connection can look fine.

What DNS tunneling changes architecturally

DNS tunneling, configurable via the dnsTunneling setting in the experimental section of .wslconfig, replaces the ordinary UDP/TCP DNS packet path with communication over a virtualization channel directly to the Windows host, rather than an ordinary network packet traversing WSL’s virtual network interface. Because this communication doesn’t look like a conventional DNS packet on the wire, VPN clients and firewalls that specifically intercept or filter DNS traffic at the packet level have nothing to block — Windows itself resolves the name, using whatever resolver and policy Windows’ own network stack is currently configured with (including VPN-provided DNS servers and split-DNS configuration), and hands the result back to the Linux side through the tunnel.

Enabling it

# %UserProfile%\.wslconfig
[experimental]
dnsTunneling=true

As with most .wslconfig changes, this requires a full WSL restart to take effect:

wsl --shutdown

The generateHosts behavior change this introduces

A specific, documented side effect worth knowing about: when DNS tunneling is enabled, the generateHosts option in /etc/wsl.conf is ignored. Under normal WSL networking, generateHosts (enabled by default) controls whether WSL writes Windows-derived host entries into the distribution’s /etc/hosts file at boot. With tunneling active, this copying step doesn’t happen the same way — Windows’ own hosts file policy is applied directly to DNS queries originating from Linux through the tunnel itself, rather than needing to be materialized into a static /etc/hosts file first. A workflow or script that assumed a specific, static /etc/hosts content based on the old copying behavior may behave differently once tunneling changes how that information actually reaches the resolution path.

Don’t rely on a frozen, manually-copied resolv.conf

Some longstanding WSL troubleshooting advice for DNS problems involves manually freezing /etc/resolv.conf with a hardcoded, known-working resolver, disabling WSL’s automatic generation of that file entirely. This workaround predates DNS tunneling and can actively conflict with it — a manually frozen resolv.conf bypasses the tunnel’s resolution path entirely, which defeats the purpose of enabling tunneling in the first place and can reintroduce exactly the VPN-related resolution problems tunneling was meant to fix. Before applying an old frozen-resolv.conf fix found in an outdated forum post, test current default behavior on your actual WSL version first — the workaround that was necessary for an older WSL release may no longer be needed, and could actively work against a newer fix if applied unnecessarily.

Verifying resolution is actually working as expected

Test Windows-side and Linux-side resolution separately rather than assuming they behave identically:

resolvectl status
nslookup internal.corp.example.com
cat /etc/resolv.conf

Compare results against what the same hostname resolves to from a native Windows command prompt. For organizations using split-DNS (internal hostnames resolving only through an internal, VPN-reachable resolver, with a different or absent result on the public internet), specifically test both an internal-only hostname and a public one, since split-DNS is exactly the scenario tunneling is most directly aimed at improving.

How this relates to mirrored networking mode

DNS tunneling and mirrored networking mode (networkingMode=mirrored, available on Windows 11 22H2 and higher) are separate settings that address overlapping but distinct problems. Mirrored mode changes WSL’s entire networking architecture so Linux sees the same network interfaces Windows does, improving VPN, multicast, and LAN-reachability compatibility broadly. DNS tunneling can be used independently of mirrored mode, specifically targeting the DNS resolution path, and is also enabled as part of WSL’s newer default networking behavior on supporting systems. If VPN-related problems extend beyond DNS — a service simply unreachable rather than just unresolvable by name — mirrored mode is the more complete fix; if the specific, isolated symptom is broken name resolution while other connectivity works, DNS tunneling alone may already be enough.

When tunneling isn’t available or isn’t the right fix

DNS tunneling is a relatively recent addition and requires a sufficiently current WSL version — confirm with wsl --version before assuming the setting will have any effect at all. It’s also specifically aimed at the DNS-packet-filtering failure mode described above; a broader connectivity problem unrelated to DNS specifically (a VPN blocking WSL’s virtual network traffic generally, not just DNS) needs separate diagnosis, most directly through WSL’s newer mirrored networking mode, which changes how WSL’s network interfaces relate to Windows’ own more broadly, beyond DNS resolution alone.

Reading the actual resolver path when something still doesn’t add up

If tunneling is enabled but a specific hostname still resolves incorrectly, resolvectl status on the Windows side and resolvectl query from inside the distribution show, respectively, what Windows itself currently believes about a name and what the tunnel actually returned to Linux for the same query. A mismatch between those two outputs points at the tunnel or the distribution’s own resolver configuration; agreement between them but a result that’s still wrong points further upstream, at whatever DNS server or split-DNS policy Windows itself is actually configured against, which is a genuinely different problem DNS tunneling has no way to fix on its own. Related: Fixing WSL2 Networking and DNS Resolution Failures · Running a Custom WSL 2 Kernel Without Losing the Supported Rollback Path

Sources: