Fixing DNS leaks on Windows

Windows resolves names differently from every other desktop operating system, and the difference is a privacy problem behind a VPN. Rather than asking the resolver on the highest-priority interface, Windows asks the resolvers on every interface at once and takes whichever answer arrives first.

Microsoft calls this smart multi-homed name resolution. It is documented, it is intended to make name resolution faster and more robust on machines with several connections, and it means your ISP's resolver — which is physically closer than a VPN server — usually wins the race.

The traffic to the site is still encrypted. The lookup that preceded it is not, so your provider holds a timestamped list of every domain you opened.

Confirm it first

Run the DNS leak test with the tunnel up. If any resolver that answers belongs to your internet provider, or sits in your physical country rather than the server's, this is what you are looking at.

Fix one: use a client that blocks it

The cleanest fix is a VPN client that installs firewall rules permitting DNS only on the tunnel adapter. Everything else is blocked at the packet level, so the race has only one runner.

Most current clients do this and call it DNS leak protection or leak prevention. Check it is enabled rather than assuming: several ship with it off.

Fix two: turn the behaviour off yourself

On Windows Pro and Enterprise, in Group Policy:

Computer Configuration → Administrative Templates → Network → DNS Client → Turn off smart multi-homed name resolution → Enabled.

On Home editions, which have no Group Policy editor, the same setting is a registry value:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" ^
  /v DisableSmartNameResolution /t REG_DWORD /d 1 /f

A reboot applies it. This is a system-wide change that affects behaviour with the VPN off as well, and on a machine with several genuine networks it can make resolution marginally slower. That is the trade.

Fix three: set the resolver explicitly on the physical adapter

Not a real fix, but worth knowing. Setting your Ethernet or Wi-Fi adapter's DNS to a public resolver rather than your ISP's means that when the race is lost, the query goes to a third party rather than to the company that also knows your name and address.

It does not stop the leak. It changes who receives it. That is an improvement in some threat models and irrelevant in others.

The browser leak, which is separate

Chrome, Edge and Firefox can all use DNS-over-HTTPS to a resolver of their own, independently of Windows and of the VPN. When they do, the leak test reports a resolver you never configured anywhere.

This is not the same problem. The lookups are encrypted, and the recipient is a named resolver rather than your ISP. But they are not going where the tunnel intended, and if you have gone to the trouble of fixing the system-level leak, leaving the browser pointed elsewhere is inconsistent.

Turn it off in the browser's privacy settings, or set it to match the resolver the tunnel uses.

IPv6, which produces the same symptom

A tunnel carrying only IPv4 on a connection with working IPv6 leaks IPv6 lookups and IPv6 traffic around it. The leak test will show it.

Either use a tunnel that routes ::/0 as well as 0.0.0.0/0, or disable IPv6 on the adapter while connected. The first is better; the second is faster.

Verify the fix

Re-run the DNS leak test. Every resolver that answers should belong to the operator the tunnel configures — VPNmine's profiles use 1.1.1.1 and 1.0.0.1, so Cloudflare is the expected answer — and none should belong to your internet provider.

Several addresses from one operator is normal, because large resolver operators run anycast pools and a single configured server can answer from more than one address. What matters is who owns them, not how many there are.

Why Windows behaves this way at all

The behaviour exists because of a real problem. A laptop can be on a corporate Ethernet and a home Wi-Fi at once, or on a network whose resolver knows internal names that no public resolver does. Asking only the highest-priority interface means internal names fail whenever the priority order is not what the user expected.

Asking everything and taking the first answer solves that neatly and creates exactly one problem: it assumes every interface is equally trusted. That assumption was reasonable in 2014 and is wrong on any machine running a VPN, which is why the setting to disable it exists.

Checking what Windows will actually do

Two commands are worth knowing while debugging.

Get-DnsClientServerAddress
Resolve-DnsName example.com -Server 1.1.1.1

The first lists which resolvers are configured on which interface, including the tunnel's, which is the fastest way to see whether the VPN client set them at all. The second forces a query to a specific resolver, which separates "the resolver is unreachable" from "the wrong resolver is answering".

After a client uninstall

VPN clients that install firewall rules for leak protection do not always remove them. A machine that has no internet after uninstalling a VPN, or that resolves nothing, is often still carrying a block rule for DNS on the physical adapter.

Windows Defender Firewall with Advanced Security, Outbound Rules, sorted by name, will show them under the vendor's name. Removing the leftovers restores normal resolution.