Home/DNS Leak Test
[ P.5 — DNS LEAK ]

DNS Leak Test

Check whether your DNS queries are going through the same provider as your IP. Compares your connection ASN against what public DoH resolvers see when they answer for you.

Last reviewed: May 2026

// Probes run in your browser. We log nothing.
// run the test
Hits /api/dns-leak/test for your client baseline (IP / ASN / VPN classification), then calls /api/dns-leak/whoami to query o-o.myaddr.l.google.com via Google DoH from the edge. The resolver IP that comes back is compared against your connection's ASN.

What is a DNS leak?

When you connect to a VPN, the expectation is that everything — HTTP traffic, DNS queries, the lot — goes through the encrypted tunnel. Your ISP shouldn't see which sites you're visiting, because the ISP's only view is the encrypted bytes going to the VPN's exit server.

A DNS leak happens when DNS queries quietly bypass that tunnel. Your web traffic still gets routed through the VPN, but the lookups that preceded the connection — "what's the IP for instagram.com?" — went to your ISP's resolver in plain sight. The ISP now has the metadata it wanted in the first place, even though the page-load bytes are hidden. From a privacy standpoint, the VPN is partially neutered.

Why DNS leaks happen

  • VPN client doesn't override system DNS. The OS still resolves through whatever is set in network preferences, which usually defaults to the ISP or DHCP-provided resolver.
  • Split-tunnel routing. Some apps are routed through the VPN and some aren't; DNS may fall on the wrong side.
  • IPv6 leakage. A VPN handling IPv4 cleanly may not touch IPv6 at all, and IPv6 DNS queries bypass the tunnel entirely.
  • Browser DoH overrides. Modern Firefox and Chrome can be set to do DNS-over-HTTPS to Cloudflare or NextDNS regardless of system settings. That isn't a leak per se — it's just a different resolver — but it can confuse this kind of test.
  • OS-level caching. Cached entries served from before the VPN connected can still be honoured for their TTL.

How this test works (and doesn't)

The classic DNS-leak technique embeds unique random subdomains on a domain whose authoritative nameserver you control, then asks the browser to resolve them and watches your auth NS for which recursive resolver IP shows up. That approach requires wildcard DNS pointed at a Worker logging endpoint — a Cloudflare DNS dashboard change we haven't made yet.

The version that runs today is the cheaper-but-honest one. We measure two things:

  • Your client posture — the IP, ASN, and geo Cloudflare sees when you hit our edge. If your ASN is a known cloud / hosting / VPN provider, we flag you as "likely on a VPN." If it's a residential ISP ASN, we flag you as "probably not."
  • A server-side resolver probe via o-o.myaddr.l.google.com over Google DoH. The IP that comes back is the recursive resolver that answered our worker's query.

The verdict is anchored by the client posture. The resolver probe adds context but it's not the primary signal — and on this point we want to be explicit:

An honest limitation

The DoH whoami probe runs from our Cloudflare edge worker, not from your browser. The resolver IP we see is the one Google DoH used to answer the worker — which is always going to be on Google's or Cloudflare's network because that's where our compute lives. It is not your laptop's or phone's system resolver.

We used to also probe whoami.cloudflare, but that record returns NXDOMAIN when queried from inside Cloudflare's own network (which is where Workers run), so it was architecturally impossible to use. We've dropped it.

What this does tell you reliably:

  • VPN detection. The client-posture half of the test uses cf-connecting-ip + a known-VPN ASN list. This is rock-solid and is the primary value of the tool.
  • Public DoH identification. If the returned resolver IP matches a known public DoH operator (Google, Cloudflare, Quad9, etc.), we surface that — useful as a sanity signal.

What it doesn't tell you:

  • Whether your operating-system DNS resolver is leaking when non-browser apps do lookups. For that, a full wildcard-DNS version of the test is the right tool — a future v2.
  • Whether your browser's own DoH setting is bypassing your VPN. The probe runs from our edge, not from your browser, so we can't observe browser-resolver behaviour directly.

DNS leak vs WebRTC leak

Different problems, both VPN-bypass categories. A DNS leak exposes your browsing history to your ISP (they see the lookups, even if the traffic is tunnelled). A WebRTC leak exposes your real local or public IP to any website you visit (via the browser's ICE candidate gathering). Either one is enough to undermine a VPN's value. The WebRTC leak test handles the second category.