DNS leak test
While you are on a VPN or proxy, do your DNS lookups slip past the tunnel to your real ISP's resolver?
What actually counts as a DNS leak
Before your browser loads a site, it asks a recursive resolver for the site's address. A VPN protects the traffic that follows; if the lookup still goes to your real ISP's resolver, your ISP learns which domains you visit, and the sites you visit can see who your real ISP is. That is a leak.
Many leak tests get this wrong:
- A resolver IP that differs from your exit IP is not a leak. The resolver is always a different machine; by that standard everyone leaks.
- Using a public resolver is not a leak. Exit in Sweden and resolver at Cloudflare means different ASN and country, but that is just public DNS, often a privacy plus.
- No VPN, no leak. A direct user on their ISP's resolver is normal; nothing is being hidden. Severity has to depend on whether the exit is anonymized.
How n0.wiki tests it
We run our own authoritative DNS server for dl.n0.wiki. The browser requests a few random one-time subdomains, so your recursive resolver has to ask our server, and we see two independent pieces of evidence:
- Who the resolver is: a known public resolver, the same network as your exit, a cloud or hosting network, or what looks like your real ISP's access network. Google Public DNS is recognised from Google's published prefix list, not reverse DNS or ASN alone (Google's resolver egress doesn't look like 8.8.8.8, and the same ASN also hosts Google Cloud).
- Whether the ECS subnet contains your exit. Some resolvers write the client's subnet (EDNS Client Subnet) into the query itself. If that subnet does not contain your exit address, the lookup came from another network. The resolver wrote this itself, so nothing is inferred. In our measurements Google sends ECS; Cloudflare and Quad9 do not.
What the verdicts mean
| Verdict | Meaning |
|---|---|
| No observation | The test did not run (for example it was blocked). This is not "no leak". |
| Not anonymized | There is evidence you are connecting directly, so there is nothing to leak. |
| Consistent | Resolver and exit are on the same network, usually the VPN's own DNS. |
| Public resolver | A known public resolver, as expected. |
| Unclassified | A third-party resolver we cannot identify. Not the same as safe. |
| Leak suspected | The resolver looks like it belongs to your real ISP's access network. |
| Conditional leak | If you are on a VPN this is a leak, but we cannot confirm that you are anonymizing. |
How to fix a DNS leak
- Turn on "use VPN DNS" or "DNS leak protection" in your VPN client; in WireGuard, set
DNS =in the config. - On Windows, disable "smart multi-homed name resolution", or make sure the VPN adapter has the highest interface priority.
- Enable DNS over HTTPS in your browser with a resolver you trust or one that matches your exit.
- With proxy apps in TUN or fake-ip mode, make sure DNS also goes through the proxy instead of falling back to the system resolver.
- Then run the test again.
Privacy
Test observations live in an in-memory store and are deleted automatically after 15 minutes. The one-time subdomains are random and not tied to any identity. See about & privacy.