DNS leak test: run it, read the resolver list

A DNS leak test prints the resolvers that answered a few unique lookups from your device. It cannot tell you whether that list is acceptable. That judgement is yours, and this page gives you a way to make it: run the test in three states, then read each row by asking who chose that resolver.

Think of a DNS resolver as the server that turns a name like example.org into an address. Your device asks it for every site you open, so its operator sees the names. A DNS leak is the case where those lookups reach a resolver you did not expect while a VPN is on, usually the one your network, and so your internet provider (ISP), handed out.

How do I run a DNS leak test?

Run it three times and write down the list each time. What you need: the ForestVPN app, one DNS leak test page and a second browser.

1. Tunnel down. With the VPN off, open the test and note the operators it prints. This is your baseline: what your own network's resolver looks like from outside. Write operator names, not addresses.
2. Tunnel up. Turn the app on and wait for the Working verdict, which means data is flowing both ways. Idle is not a fault, only a quiet app, but a test run then proves little: send some traffic first. A tunnel that carries nothing cannot carry the test. If the app shows something else, start with VPN connected but no internet or VPN not connecting.
3. Kill switch on, tunnel down (Windows and Linux). Switch the kill switch on and disconnect. There the firewall block stays while the tunnel is not up, so a working kill switch leaves the test nothing to reach, and seeing no list is the pass. On Android the app blocks a drop only while ForestVPN is running; to cover a disconnect, turn on Always-on VPN with Block connections without VPN in the system settings. On iPhone, iPad and Mac the kill switch is an on-demand rule and a manual disconnect disarms it, so a manual disconnect is not a kill-switch test there. No kill switch is absolute, and none covers every edge case.

Open a fresh tab for each run, since a cached page can pass for a new result. Then repeat step 2 in a browser you rarely use, to learn whether a setting inside the first browser decides the answer. Compare each site with itself, not with another site: every test prints the resolvers in its own wording.

What does a DNS leak test show with the VPN on and off?

In our run, the Linux client showed no lookups on the physical adapter at the Working verdict, 44 with the tunnel down, and nothing at all with the kill switch on and the tunnel down. It also showed one thing we did not expect.

Show the data

Tunnel down	44 packets
Idle read	4 packets
Working	0 packets
Kill switch on	0 packets

With the tunnel down, the lookups went to the network's resolver. With the tunnel up, the system resolver listed a second link for the tunnel, with its own server and a catch-all search domain, and the test then named a different operator.

At the Working verdict, the three captures showed 22, 20 and 20 packets on the tunnel adapter and none on the physical one.

Now the unexpected part. In a capture started before the connect, 18 DNS packets left on the physical adapter in the first seconds. They were lookups of the client's own service names, made through the system resolver before the tunnel existed.

After the tunnel came up, none followed in the 31-second capture. So in our Linux run the client asked the network's resolver for its own server names at connect time. A leak test cannot see those lookups, only the lookups it makes itself, and ours came after that window. The 4 packets in the Idle read went unexplained, and they did not recur in the three Working captures.

Our test tool printed the same warning text ("DNS may be leaking") in the tunnel-down and tunnel-up reads, so it is not a verdict on the tunnel. Read the operators, not the sentence.

How do I read a DNS leak test result?

Only one of three kinds of resolver is a leak. Ask who chose each row. The exit is the ForestVPN server where your traffic leaves the tunnel.

Row two can surprise you. At Working that operator is the exit's upstream resolver, reached from inside the tunnel. The test names the operator it sees at the far end, so with the VPN up it may print a public resolver operator, not your ISP. If your own network uses the same operator, compare the location too, and compare against your tunnel-down list from step 1.

Whether row three is a leak depends on what you expected. dnsleaktest.com's own guidance says that when DNS is managed elsewhere on your system, secure DNS set in the web browser could be considered a leak. If you want filtering, choose a filtering DNS provider yourself and read its resolver as row three.

Why does a DNS leak happen on Windows, Android and Linux?

A leak happens when something other than the VPN's setting wins the choice of resolver. Microsoft Windows name resolution, Android Private DNS, the Linux stub resolver and the secure DNS in Firefox and Chrome each have their own way to do it.

Microsoft documents the Windows behaviour as a name-resolution optimisation. Its policy, Turn off smart multi-homed name resolution, still leaves queries issued across all networks first, so the policy alone is not a fix. Wikipedia's entry records the same change in Windows 8 and says it exposed VPN users to leaks. No Windows run is behind this page.

On Linux, our run is the evidence. With systemd-resolved, the tunnel link took the catch-all search domain, so lookups moved to it once the tunnel link came up, while the physical link kept its own servers configured but unused.

Does Android Private DNS change a DNS leak test?

Yes, because Private DNS can name a provider that answers lookups on every network. Android's LinkProperties page says that with a private DNS server name set, queries must go to that server (strict mode); with no name and Private DNS active, apps should try encrypted queries to the network's servers and may fall back to unencrypted ones (opportunistic mode).

Android also keeps DNS servers per network, and its DNS resolver module answers app lookups. If you set a provider in Private DNS, it is the third kind of resolver in the reading table, on the list with the VPN on or off. Our run did not cover Android. ForestVPN's Always-on VPN, battery and Private DNS page says the app's diagnosis reports the Private DNS mode and that ForestVPN publishes no guidance on which mode to pick.

Does browser DNS over HTTPS count as a DNS leak?

Not a fault, and not always a leak. DNS over HTTPS carries lookups inside ordinary HTTPS to a provider, so a provider set in the browser answers instead of the VPN's resolver.

Chrome's help page says secure DNS is on by default in automatic mode, that Chrome looks the site up unencrypted if that mode has issues, and that a custom provider stops the fallback. Automatic mode uses your current service provider, so a browser-named provider appears only when you pick a custom one. Firefox documents its own DNS over HTTPS setting, so check it in the browser you test with.

Pick a side on purpose. Keep the provider and accept that it sees your names, or remove it so the system resolver, and so the VPN's setting, answers.

Why does my DNS leak on a router?

Whatever a router hands out, its devices use, so the fix lives on the router. Devices copy the resolver from its DHCP offer, and a router that forwards lookups outside the tunnel is a path around it.

The OpenWrt kill switch page says lookups from protected devices go to the tunnel's resolver. It adds that a lookup still reaching the router is refused, and that a browser doing its own secure DNS cannot be caught by the router.

Its verification status, verbatim: "Not yet verified on hardware as a whole. The leak suite ran in a lab on OpenWrt 21.02.7 (fw3) and 24.10.8 (fw4), and every row passed. On 21.02.7 four of its checks are skipped, three of them IPv6 checks. A hardware run is still owed."

On the MikroTik RouterOS side, the page choosing what goes through the tunnel says its Everything mode also moves the LAN's DHCP DNS to 1.1.1.1 and 8.8.8.8, so lookups go through the tunnel too. Names only your router answers stop resolving. The leak test itself is on the MikroTik kill switch and leak check page. Rerun your test from a device behind the router either way.

How do I fix a DNS leak?

Fix the choice, then prove it with another run. Start with the smallest change.

1. Reconnect and wait for the Working verdict, then rerun.
2. Decide on browser secure DNS and rerun in a second browser.
3. On Android, check the Private DNS mode in the network settings; a named provider there is the third kind of resolver. ForestVPN publishes no guidance on which mode to pick.
4. On Windows, remove static DNS entries from the physical adapter, as the dnsleaktest.com guide says, then flush the cache. The guide also has you add a 0.0.0.0 entry for its test; that entry is temporary and makes lookups fail while the VPN is off, so remove it afterwards.
5. On Linux, run resolvectl status and compare the Wi-Fi link's servers with the VPN link's.
6. On a router, follow the recipe page, then test from a device behind it.

If the app cannot resolve its own server names, that is a different message. The Apple apps show the code cp.dns_blocked today, with the text Name lookup is being blocked. It means the network's name service refuses or hides the lookup, and the suggested action is another network. For the general picture, see VPN basics: DNS leaks and Tor.

Is a DNS leak the same as an IP leak?

No. They are separate checks. An IP leak is your network address showing to the sites you visit, and a DNS leak is the names you looked up showing to a resolver. A VPN can fix one and leave the other.