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.
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.
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.
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.
