DNS requests can leak the websites you visit. Learn about DNS leak mechanics and how to protect your privacy with DNS over HTTPS.
A DNS leak happens when your device sends domain-name lookups to a resolver outside the protected path you expect — usually your ISP's resolver instead of your VPN's — exposing every website you visit even when the rest of your traffic is encrypted. To prevent it, route DNS through your VPN tunnel (or an encrypted resolver using DNS over HTTPS or DNS over TLS), disable plain-text fallback, and close IPv6 and WebRTC side channels. The fastest way to confirm you are protected is to run a DNS leak test and check which resolver IPs appear.
What DNS Resolution Is and Why It Is Privacy-Sensitive
Every time you open a website, your browser needs to translate a human-readable name like browserinsight.net into a numeric IP address. That translation is done by the Domain Name System (DNS). Your device asks a DNS resolver — typically operated by your ISP unless you've changed it — and the resolver returns the address so the connection can be made.
The privacy problem is simple: whoever runs that resolver sees a log of every domain you look up, with timestamps. Even if the page loads over HTTPS and its contents are encrypted, the name of the site you wanted is revealed at the DNS step. By default, classic DNS queries travel in plain text over UDP port 53, so they're also visible to anyone on the network path, not just the resolver operator.
Think of DNS as the address book of the internet. Encrypting the letter inside the envelope (HTTPS) doesn't help much if you're shouting the recipient's name out loud every time you mail one.
What a DNS Leak Is
A DNS leak is when your DNS queries escape the private or encrypted channel you believe they're using. The most common scenario: you connect to a VPN expecting all traffic to go through the tunnel, but your operating system keeps sending DNS lookups straight to your ISP's resolver. Your data packets are encrypted and routed through the VPN, yet your ISP still receives a complete, timestamped list of the domains you visit. That defeats much of the point of the VPN.
The leak is "silent" because nothing visibly breaks — pages still load normally. You only discover it by testing.
Common Causes of DNS Leaks
- OS resolver bypassing the tunnel. Operating systems sometimes hold onto their previously configured DNS servers, or use a "fastest responder" strategy that races your VPN's resolver against the ISP's and may pick the wrong one.
- Split tunneling. If you route only some apps or subnets through the VPN, DNS for the excluded traffic — and sometimes for all traffic — may go out directly.
- IPv6 leakage. Many VPN configs only tunnel IPv4. If your network has IPv6 connectivity and the VPN ignores it, IPv6 DNS lookups slip out unprotected.
- Misconfigured or lightweight clients. Some VPN apps don't enforce their own DNS, or fail to restore protection after the device sleeps, switches networks, or reconnects.
- Transparent DNS hijacking. Some ISPs intercept all port-53 traffic and answer it themselves regardless of which resolver you configured, forcing leaks unless your DNS is encrypted.
Why It Matters Even With a VPN
People often assume a VPN makes them anonymous. A VPN encrypts your traffic and hides your IP from destination servers, but it only protects DNS if the client is configured to capture and tunnel those queries. When DNS leaks, your ISP — and any government or advertiser it shares data with — can reconstruct your browsing history by domain even though it can't read page contents. The same logic applies to WebRTC, which can expose your real IP from inside the browser entirely separately from DNS; see our guide on stopping WebRTC IP leaks for that side channel.
If you want to verify what your real IP and resolver look like to the outside world, BrowserInsight's IP intelligence check shows the address servers actually see, and the VPN/proxy detection tool flags whether your connection looks like a VPN, proxy, or your bare ISP line.
Encrypted DNS: DoH, DoT, and DNSCrypt
The structural fix for plain-text DNS is to encrypt the queries themselves so neither the network path nor an interfering ISP can read or hijack them. Three approaches dominate:
- DNS over HTTPS (DoH) sends DNS queries inside ordinary HTTPS traffic on port 443. Because it looks like normal web traffic, it's hard to single out or block, and it's built directly into modern browsers (Chrome, Firefox, Edge) as "Secure DNS."
- DNS over TLS (DoT) wraps DNS in a TLS session on a dedicated port (853). It's clean and easy to monitor at the network level, which makes it popular for OS-wide and router configurations — but the dedicated port is easier for a hostile network to block.
- DNSCrypt is an older protocol that authenticates and encrypts queries between you and supporting resolvers. It's less common today but still used by some privacy tools.
Plain DNS vs DoH vs DoT vs VPN-tunneled DNS
| Method | Transport / Port | Encrypted | Hides queries from ISP | Notes |
|---|---|---|---|---|
| Plain DNS | UDP/TCP 53 | No | No | Default; visible to ISP and on-path observers |
| DNS over HTTPS (DoH) | HTTPS 443 | Yes | Yes | Blends with web traffic; per-app or per-browser |
| DNS over TLS (DoT) | TLS 853 | Yes | Yes | Easy to deploy OS/router-wide; port can be blocked |
| DNSCrypt | UDP/TCP, custom | Yes | Yes | Niche; authenticates the resolver |
| VPN-tunneled DNS | Inside VPN tunnel | Yes (via tunnel) | Yes (from ISP) | ISP sees nothing; you trust the VPN's resolver |
Encrypted DNS hides your queries from the network, but the resolver you choose still sees them. Pick a resolver you actually trust — moving from "my ISP sees everything" to "a logging third party sees everything" is not an upgrade. For help evaluating providers, see our comparison of privacy tools.
Encryption Isn't the Same as Trust: DNS Answer Integrity
Everything above protects DNS confidentiality — keeping the network and your ISP from seeing which names you look up. It says nothing about whether the answer you get back is genuine. A resolver, or anyone able to inject packets on the path to it, can return a forged IP address for a domain, and DoH/DoT encryption won't catch that: the forged answer just arrives over an encrypted channel instead of a plaintext one. Verifying that the answer itself hasn't been tampered with is a separate job, handled by DNSSEC (DNS Security Extensions), which lets a resolver cryptographically confirm a response really came from the domain's authoritative name servers and wasn't altered in transit.
The .al Incident: What Happens When DNSSEC Breaks
In July 2026, Albania's .al top-level domain went dark for DNSSEC-validating resolvers. The registry published a new signing key, but the root zone's DS record — the pointer that tells validators which key to trust — still referenced the old one. That mismatch broke the chain of trust for every .al domain at once: a validating resolver treats a signed answer it can't verify as a failure rather than silently accepting it, so lookups for .al sites started failing outright. The registry then removed the new key entirely, leaving no valid key at all, and the DS record was ultimately pulled from the root zone, leaving .al unsigned. Cloudflare has the full timeline in its writeup of the incident.
Negative Trust Anchors: Trading Validation for Availability
Faced with an entire ccTLD becoming unresolvable, Cloudflare applied a negative trust anchor (NTA) to .al on 1.1.1.1 within about three hours. An NTA is an emergency, resolver-side override that tells the validator to stop checking DNSSEC signatures for a specific broken zone so users can keep reaching those sites — deliberately trading away protection against a spoofed answer in order to restore availability. It's a last resort: applying one means a resolver operator has decided a working-but-unverified zone beats a correctly-verified outage, until the zone's operator fixes its signing.
Extended DNS Error 33: Seeing the Trade-off
The catch with an NTA is that its effect was historically invisible — an answer served under one looked identical to a fully DNSSEC-validated answer. RFC 8914 (Extended DNS Errors) closes that gap by defining machine-readable error codes a resolver can attach to a response. 1.1.1.1 now returns EDE code 33 ("RRSIGs Missing") on answers covered by a negative trust anchor, meaning: this is the real, first-party answer, but it was not DNSSEC-validated. Tools and resolvers that read EDE codes can tell those two situations apart instead of treating both as an equally trustworthy result.
How a Trustworthy VPN Should Route DNS
A well-built VPN doesn't just encrypt your data — it owns DNS end to end. Specifically, it should:
- Run its own DNS resolvers inside the tunnel, so queries never touch your ISP.
- Force all DNS through the tunnel, overriding the OS's configured servers, with no "fastest responder" races leaking to port 53.
- Handle or disable IPv6 so IPv6 lookups can't escape an IPv4-only tunnel.
- Include a kill switch that blocks all traffic — including DNS — if the tunnel drops, instead of failing open to your ISP's resolver.
If a VPN client offers none of these guarantees, treat it as leak-prone until you've tested it yourself.
How to Test for a DNS Leak
Testing takes a minute and is the only way to be sure. Connect your VPN (or enable encrypted DNS), then check which resolver IPs answer your queries. If you see your ISP's resolver or an address geolocated to your home region instead of your VPN's, you have a leak. How precisely that resolver IP actually pins down your location is a separate question — see how accurate IP geolocation really is.
On the command line you can inspect resolution directly:
# Which resolver does a single lookup go to and return?
nslookup browserinsight.net
# Linux (systemd-resolved): show the DNS servers actually in use per link
resolvectl status
# Linux/macOS: see the resolver returned for a query (look at SERVER:)
dig browserinsight.net
Look at the Server: / SERVER: line: it should be your VPN's resolver or your chosen encrypted-DNS provider, never your ISP's box. For a browser-side picture of how the outside world sees you, run BrowserInsight's IP check before and after connecting — the IP and its detected network should change. The VPN/proxy check helps confirm your traffic is exiting where you expect.
That confirms which resolver answered, but not whether it validated the answer. To check that too, run dig +dnssec browserinsight.net and look for the ad (Authenticated Data) flag in the response header — its presence means the resolver validated DNSSEC for that answer. If your resolver surfaces Extended DNS Errors, an EDE code in the response (like code 33 discussed above) tells you it deliberately skipped validation for a broken zone, rather than validation simply being unsupported.
Concrete Prevention Steps
Operating System
- Set a trusted resolver system-wide. On Windows 11, Settings → Network → DNS server assignment lets you enable encrypted DNS (DoH). On macOS, install a DNS profile or use a client that enforces DoH/DoT. On Linux, configure
systemd-resolvedwithDNSOverTLS=yesand an explicitDNS=entry. - Disable IPv6 if your VPN doesn't tunnel it, or use a VPN that explicitly handles IPv6, so you don't leak through the v6 stack.
- Enable the VPN kill switch so a dropped tunnel can't fall back to plain DNS.
Browser
- Turn on Secure DNS / DNS over HTTPS in your browser settings (Chrome: Privacy and security → Security → Use secure DNS; Firefox: Settings → Privacy & Security → DNS over HTTPS).
- Disable WebRTC or use an extension that prevents WebRTC from exposing local and public IPs — a separate leak from DNS but just as revealing.
- Avoid extensions that silently change your DNS or proxy settings.
Router
- Configuring encrypted DNS at the router level protects every device on the network at once, including those that can't run their own clients. This is also the most reliable defense against ISP transparent DNS hijacking, since queries leave your network already encrypted.
Frequently Asked Questions
Does using a VPN automatically prevent DNS leaks?
No. A VPN only prevents DNS leaks if its client forces DNS through the tunnel and handles IPv6. Many leaks happen while a VPN is connected because the OS quietly keeps using the ISP's resolver. Always test rather than assume.
Is encrypted DNS (DoH/DoT) the same as a VPN?
No. Encrypted DNS only protects the lookup of domain names; it hides which sites you query from the network but does not encrypt the rest of your traffic or hide your IP from the sites you visit. A VPN does the latter. The two are complementary, not interchangeable.
Can my ISP still see my browsing if I use DoH?
Your ISP can no longer read your DNS queries once they're encrypted with DoH, so it can't log the domains that way. However, it can still infer some destinations from the IP addresses you connect to and from the server name (SNI) sent during the TLS handshake. DoH closes the DNS channel specifically.
How do I know which resolver I'm actually using?
Run nslookup or dig and read the Server: line, or use resolvectl status on Linux. For an at-a-glance external view, BrowserInsight's IP check shows the IP and network the outside world sees, which should match your VPN — not your home ISP — when you're connected.
Does encrypted DNS mean the answer is trustworthy?
No — encryption (DoH/DoT) and validation (DNSSEC) solve different problems. Encrypted DNS hides which domains you're looking up from the network; DNSSEC verifies that the answer you received actually came from the domain's real name servers and wasn't forged or tampered with in transit. You can have one without the other: a DoH query can return a fully validated answer, an unvalidated one, or — as happened during the July 2026 .al DNSSEC failure — an answer served under a resolver's negative trust anchor, which is genuine but explicitly unverified. A resolver that supports Extended DNS Errors can flag that trade-off (e.g. EDE code 33) instead of leaving it invisible.
A DNS leak exposes your own queries to the wrong resolver, but DNS resolution can also be turned around and used against you: site owners can alias a subdomain to a tracker's servers with a CNAME record so the tracker's responses look first-party. See CNAME cloaking: trackers disguised as first-party for how that works and which browsers now catch it.
DNS is usually the biggest single leak once you've moved to HTTPS everywhere, but it isn't the only piece of metadata still exposed on an encrypted connection — see what your ISP can still see when you use HTTPS for how DNS fits alongside destination IPs, SNI, and traffic timing.
