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 dnsTunneling under the [wsl2] 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 less opportunity to misroute it — Windows resolves the name using its current DNS policy, including VPN-provided servers and split-DNS configuration, and hands the result back through the tunnel.

Confirming or explicitly enabling it

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

Microsoft’s current documentation says DNS tunneling is already enabled by default on supported Windows 11 22H2-and-newer systems. The explicit setting is useful when auditing a managed configuration, but it is not evidence that an older inbox WSL build supports the feature. Check wsl --version from PowerShell and update WSL through the approved channel before troubleshooting a key the installed release may not understand.

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. In PowerShell, inspect Windows’ configured resolvers and resolve the same names Windows-side:

Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName internal.corp.example.com

Then inspect and query the Linux resolver inside WSL:

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

Compare the results. 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 hostname still resolves incorrectly, compare PowerShell’s Resolve-DnsName result with resolvectl query inside the distribution. A mismatch points toward WSL or the distribution’s resolver configuration; agreement on an incorrect answer points further upstream, at the DNS server or split-DNS policy Windows is using. resolvectl is a Linux/systemd tool, not a Windows-side diagnostic command.

Related:

Sources: