Fix a DNS leak on Windows 11 by setting DNS manually on every active adapter under Settings, Network and internet, Wi-Fi, Hardware properties, DNS server assignment, Edit, then disabling smart multi-homed name resolution and flushing the cache with ipconfig /flushdns.
Confirm you actually have a DNS leak
A DNS leak means your device is sending name-resolution queries to a resolver that is not the one your VPN or your chosen provider intended. The practical consequence is that whoever operates that resolver, usually your ISP, sees a timestamped list of every domain you visit even though the page content itself is encrypted.
Before changing anything, establish the baseline. Open Windows Terminal or PowerShell and look at what Windows believes its resolvers are, adapter by adapter. The order matters: an adapter with a lower interface metric wins, and VPN tunnel adapters do not always win.
Get-DnsClientServerAddressshows the configured resolver per interface, including the VPN tunnel.nslookup whoami.akamai.netreturns the public IP of the resolver that answered, not your own IP.- The Google TXT query returns the egress address of the resolver that reached Google's authoritative servers.
- If either query returns an address that belongs to your ISP's ASN rather than your VPN provider or your chosen public resolver, you have a leak.
Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, ServerAddresses
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Format-Table InterfaceAlias, InterfaceMetric
nslookup whoami.akamai.net
nslookup -type=TXT o-o.myaddr.l.google.com ns1.google.comA resolver IP that geolocates near you is a strong signal but not proof. Look up the ASN of the answering address. AS7922 (Comcast), AS701 (Verizon) or AS20115 (Charter) appearing while a VPN is connected is a leak; AS13335 (Cloudflare) or AS15169 (Google) may be legitimate depending on what you configured.
Why Windows 11 leaks DNS even with a VPN running
Windows does not have a single system resolver in the way people assume. It has a per-interface resolver list and a resolution policy that decides which interface to ask. When multiple interfaces are up at once, which is exactly the situation when a VPN is connected over Wi-Fi, Windows may query several of them in parallel and accept whichever answers first.
This behaviour is called smart multi-homed name resolution. It was introduced for laptop users moving between corporate and home networks, and it does what it was designed to do: it resolves names fast. It is also the single most common cause of DNS leaks on Windows, because the physical adapter often answers milliseconds before the tunnel does.
Two other mechanisms make it worse. The Name Resolution Policy Table can force specific suffixes to specific servers, which enterprise images and some security agents populate. And DNS over HTTPS templates configured at the OS level persist independently of the VPN, so a resolver you set months ago keeps answering.
Fix 1: Pin DNS servers on every adapter
The most reliable fix is to stop relying on DHCP-provided resolvers entirely. Set the same resolver explicitly on every adapter that can carry traffic, so there is no interface left that can answer with your ISP's server.
In the graphical settings, the exact path is Settings, then Network and internet, then Wi-Fi (or Ethernet), then Hardware properties, then the Edit button next to DNS server assignment. Change the dropdown from Automatic (DHCP) to Manual, switch IPv4 to On, and enter your preferred and alternate resolvers. Set Preferred DNS encryption to Encrypted only (DNS over HTTPS) if the provider you chose is on the known-templates list. Repeat for the Ethernet adapter even if it is currently unplugged.
The command line is faster and less error-prone when you have several adapters. Run Terminal as Administrator.
Check for virtual adapters while you are in there. VMware, VirtualBox, Hyper-V, WSL and Docker Desktop each install network interfaces that hold their own resolver entries, and any of them can answer a query if its interface metric happens to be favourable. Run netsh interface ip show interfaces and treat every entry with a state of connected as a candidate for the same treatment.
netsh interface ip show interfaces
netsh interface ip set dns name="Wi-Fi" static 1.1.1.1 primary
netsh interface ip add dns name="Wi-Fi" 1.0.0.1 index=2
netsh interface ip set dns name="Ethernet" static 1.1.1.1 primary
netsh interface ip add dns name="Ethernet" 1.0.0.1 index=2
ipconfig /flushdnsIf your VPN client pushes its own resolver, use that address instead of a public one. Pinning a public resolver while a VPN is up removes the ISP from the picture but still splits your DNS and your traffic across two organisations.
Fix 2: Turn off smart multi-homed name resolution
With resolvers pinned, disabling parallel queries removes the race condition that causes the leak in the first place. On Windows 11 Pro, Enterprise and Education, the setting lives in Group Policy at Computer Configuration, Administrative Templates, Network, DNS Client, Turn off smart multi-homed name resolution. Set it to Enabled, which counterintuitively disables the behaviour.
Windows 11 Home has no Group Policy editor, so set the registry value directly. The change takes effect on the next DNS query; a reboot is not required, though it is a clean way to confirm the value survives.
- Create the DNSClient key first if it does not exist:
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Force. - Some corporate VPN clients re-enable parallel resolution at connect time; re-check after a reconnect cycle.
- This does not slow browsing measurably on a single-homed desktop. On a laptop that roams between networks you may notice a short delay on the first lookup after switching.
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name "DisableSmartNameResolution" -Value 1 -PropertyType DWord -Force
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "DisableParallelAandAAAA" -Value 1 -PropertyType DWord -Force
ipconfig /flushdnsFix 3: Kill the IPv6 and Teredo side channels
A large share of reported DNS leaks are really IPv6 leaks. Your VPN tunnels IPv4, your ISP hands you a native IPv6 prefix, and the AAAA lookups plus the resulting connections walk straight out of the tunnel. Windows also ships Teredo, an IPv6-over-UDP transition tunnel, which can create an additional path.
The correct fix is to use a VPN that carries IPv6 inside the tunnel. If yours does not, disabling IPv6 on the physical adapter is the pragmatic option, with the caveat that some carrier networks and an increasing number of services now assume IPv6 is available.
Get-NetAdapterBinding -ComponentID ms_tcpip6 | Format-Table Name, Enabled
Disable-NetAdapterBinding -Name "Wi-Fi" -ComponentID ms_tcpip6
netsh interface teredo set state disabled
netsh interface 6to4 set state disabled
netsh interface isatap set state disabledDo not disable IPv6 via the registry-wide DisabledComponents value set to 0xFF. Microsoft does not support fully disabling IPv6 on the loopback interface, and several Windows components including some Office and Hyper-V features misbehave when it is gone. Disable it per adapter instead.
Verify the fix and keep it fixed
Re-run the same checks you used to find the leak, with the VPN connected and again after a disconnect and reconnect cycle. A configuration that survives one connection but not a reconnect is not fixed; VPN clients frequently rewrite adapter settings at connect time.
Test the failure case as well. Disconnect the network cable or toggle airplane mode while the VPN is connected, then restore it, and check within the first few seconds whether queries are going to the right resolver. The window between the physical link coming back and the tunnel re-establishing is where most real-world leaks happen, and it is the window a kill switch is supposed to close.
Finally, check the browser separately. Chrome and Firefox can run their own DNS over HTTPS resolver independently of Windows, so the operating system can be perfectly configured while the browser talks to an entirely different provider. In Chrome the setting is under chrome://settings/security, Use secure DNS. In Firefox it is Settings, Privacy and Security, DNS over HTTPS.
ipconfig /displaydns | Select-String "Record Name" | Select-Object -First 20
Resolve-DnsName example.com -Server 1.1.1.1
Get-DnsClientDohServerAddressFrequently asked
Does ipconfig /flushdns fix a DNS leak?
No. Flushing the cache clears previously resolved records from memory so the next lookup is fresh, which is useful for confirming a configuration change took effect. It does not change which resolver Windows asks. Use it after pinning DNS servers or editing the registry, not as a fix on its own.
Why does my VPN still leak DNS after I set 1.1.1.1 manually?
Two common causes. First, you set it on one adapter but another active adapter, usually Ethernet or a virtual adapter from a hypervisor, still has DHCP-supplied resolvers. Second, smart multi-homed name resolution is querying all interfaces in parallel and accepting the fastest answer. Pin every adapter and disable parallel resolution.
Is a DNS leak dangerous or just a privacy problem?
Primarily a privacy problem. The queries reveal which domains you contact and when, which is enough to profile browsing habits, but the content of those connections stays encrypted by TLS. The security concern is secondary: a resolver you did not choose can return manipulated answers, which is why an authenticated encrypted resolver is preferable.
Does DNS over HTTPS in Windows 11 prevent leaks by itself?
It encrypts the queries so your ISP cannot read them in transit, but it does not control which resolver is asked. If Windows still routes queries to your ISP's resolver over DoH, that resolver still logs your domains. Encryption and resolver choice are separate problems, and you need to fix both.
How do I check for a leak without a third-party website?
Run nslookup whoami.akamai.net and nslookup -type=TXT o-o.myaddr.l.google.com ns1.google.com. Both return the public address of the resolver that answered. Look up that address's ASN. If it belongs to your ISP while the VPN is connected, the leak is real and reproducible from the command line.