How to read a DNS leak test result
The test resolves unique one-time hostnames and reports which servers asked for them. A resolver belonging to your internet provider is a leak. Several addresses belonging to one operator you deliberately chose is normal rather than alarming, because large resolvers answer from anycast pools spread across many locations.
4 min read
A DNS leak test works by asking your browser to resolve hostnames that have never existed before. Because nothing has them cached, every lookup must reach an authoritative server, and that server records which resolver asked. The list you get back is the set of resolvers your device actually used.
Reading it correctly means knowing which entries are findings and which are normal.
A leak: your internet provider's resolver
If any resolver belongs to your ISP, lookups are leaving the tunnel. The traffic to sites is still encrypted, and your provider holds a timestamped list of every domain you opened, which is most of what a tunnel was supposed to prevent.
Recognise it by the operator name — usually the ISP's own name or its network identifier — or by the location matching where you physically are rather than where the server is.
Also a leak: your physical country when the server is elsewhere
If you connected to a server in Germany and the resolvers answering are in your own country, the lookups did not go through the tunnel even if they went to a public resolver.
Not a leak: several addresses from one operator
Large resolver operators run anycast, meaning the same address is announced from many locations, and a single configured resolver may forward through a pool of outbound addresses. Seeing four or five entries all belonging to one operator is normal behaviour, not five leaks.
Judge by ownership, not by count.
Not a leak, but worth noticing: a resolver you did not configure
If a large public resolver appears that you never set anywhere, something on your device chose it independently. Three usual causes:
- Browser DNS-over-HTTPS. Chrome, Edge and Firefox can all send lookups to their own resolver over HTTPS regardless of system settings.
- Android Private DNS, which applies system-wide and overrides the tunnel.
- A router or a security product with its own resolver configured.
The lookups are encrypted, so nobody on the network reads them, but they are not going where the tunnel intended and they are visible to a party you may not have chosen deliberately.
What "no leak" should look like
Every resolver belongs to the operator your tunnel configures, and none belongs to your ISP. With a VPNmine tunnel that means Cloudflare's 1.1.1.1 and 1.0.0.1, reached through the tunnel — so Cloudflare sees the query arriving from the VPN server rather than from you.
Being specific about that is deliberate. A provider that says "our own resolvers" should be able to name them, and if the test shows something else, one of the two statements is wrong.
Test methodology matters
A test that resolves a fixed hostname can be answered from a cache anywhere along the path, which produces a result about caching rather than about your configuration. A test that resolves unique, single-use hostnames cannot be, which is why the DNS leak test here generates them per run.
Testing in more than one browser is also worth doing. Because browsers can resolve independently of the system, one may leak while another does not, and a single clean result does not cover the device.
Fixing what you find
ISP resolver answering: enable the client's DNS leak protection, or on Windows disable smart multi-homed name resolution, which asks every interface at once by design.
A resolver you did not configure: turn off the browser's secure DNS, or set Android's Private DNS to Automatic.
Resolvers in your physical country with a foreign server: the tunnel is not carrying DNS at all. Check the client set the resolver, and confirm with what is my IP that traffic is going through the tunnel either.
Why this matters more than it sounds
DNS is small, cheap to store and extremely revealing. A list of every domain you resolved, with timestamps, describes your reading habits, your health concerns, your employer, your banks and your interests, without a single byte of content being decrypted.
That is why it is the first thing to check after confirming the exit address, and why a provider's policy on DNS retention is worth reading specifically rather than accepting a general no-logs claim that never mentions it.