Leaks & Masking · Network Tests
DNS Leak Test
See which resolvers your lookups reach, and whether a VPN or DoH is actually containing them.
Each probe asks for a name that cannot exist. The request stops at the resolver, so what you see is the lookup itself.
Resolution probes
DNS posture your browser exposes
Split-tunnel check
A browser cannot see which resolver answered, and no JavaScript API exposes the resolver address or the Secure DNS setting. The probes below use names under .invalid, a top-level domain reserved by RFC 2606 that no resolver should translate, so the request fails at the lookup stage and never opens a connection. That measures how long a lookup takes and whether an impossible name was intercepted — not who performed it. Showing a resolver list would require a server logging its own DNS queries, which this page cannot do.
On this page
What a DNS leak actually is
Before your browser can load anything it has to turn a hostname into an address, and that question goes to a resolver — usually the one your router handed out over DHCP, which in turn forwards to your ISP. Every name you visit passes through it in the clear on UDP port 53.
A VPN is supposed to capture that step as well as your traffic. Many do. The problem is the ones that do not: a split-tunnel configuration, a VPN client with "use my ISP's DNS" enabled, or a leak after the tunnel drops all leave the ordinary resolver in charge. Your page content then travels encrypted while the list of sites you visit travels in plaintext next to it, which is the leak in the name.
The leak is a list, not a page
Nothing about your traffic is exposed by a DNS leak — just the names. That is still a detailed record of where you went and when, and it is often easier for a network operator to read than the encrypted traffic beside it.
What a browser can and cannot observe
It is worth being blunt here, because most pages that promise a DNS leak test from the browser alone are overstating what they can do. A web page cannot read the resolver address. There is no API for it, request timings include TCP and TLS work that dwarfs the lookup, and browsers do not expose their Secure DNS setting to scripts at all.
- Not readable: the resolver's address, whether DoH is active, the contents of a query, and any query made by another app on your machine.
- Readable: how long your own lookups take, whether a name that cannot exist was answered anyway, the network your address belongs to, its timezone, your browser's timezone and your locale.
The panel above reports only the second list. The split-tunnel rows compare the organisation behind your address and its timezone against your browser's, which is a smell test, not proof. For an honest resolver-level answer you need a server-side test, which is described further down.
Reading the probe timings
Each probe asks for a random subdomain of a .invalid name. That top-level domain is reserved by RFC 2606 precisely so it can never resolve, which makes it a clean measuring stick: the browser fails at the lookup, no connection is opened, and the elapsed time is dominated by the DNS round trip.
A typical result is somewhere between a few milliseconds and roughly a hundred. The lower end usually means a local cache or an on-router resolver answered — including the negative answer, which browsers and resolvers cache for a short period under RFC 2308. The higher end means the question travelled further before coming back.
What matters more than the number is the shape. All four probes failing cleanly and quickly is the ordinary outcome. A stall past two seconds points at a blocked, filtered or unreachable resolver. And a probe that succeeds is the interesting one — it means a name with no possible address reached a server, so something answered a query it should have refused.
When DNS really does leak
The classic leak is a VPN whose adapter is configured with the ISP's resolver. The tunnel carries your traffic, the resolver query stays outside it, and the ISP can log every hostname. A second, subtler case is the tunnel dropping: many clients keep the old resolver while reconnecting, so names keep flowing to a network you thought you had left.
IPv6 is the third case worth knowing about. A machine can hold both an IPv4 address through the tunnel and a native IPv6 address that bypasses it, and the resolver may be reached over IPv6 without you noticing. Checking with the IPv6 test alongside this one is the quickest way to see whether one family is escaping.
An intercepting resolver is a different problem
Some access providers rewrite the answers to names that should not exist, serving a search page instead of an error. If the probes above came back with a result rather than a failure, that behaviour is the likely cause. It is worth reading about on its own terms, not just as a leak.
How to check your DNS properly
A real resolver test needs a server. The usual design gives you a one-off hostname, you load it, and the server records which resolver asked for that name and shows it back to you. That is the only way to learn the actual address, and it is why server-side tests exist next to browser-side ones like this.
- Turn on encrypted DNS in the browser. Firefox has a DNS-over-HTTPS setting, Chrome and Edge have Secure DNS, and Brave ships its own. This covers browser lookups only.
- Check your VPN's DNS setting. Look for the option that routes DNS through the tunnel instead of the local network, and prefer the provider's own resolver.
- Check the whole device, not the browser. Other apps and the operating system keep their own resolver regardless of what the browser does.
Whichever route you take, re-run this page afterwards. The timing probe will not tell you the resolver, but the split-tunnel rows and the proxy and VPN detection test will show whether your address and your browser still disagree about where you are.