DNS, WebRTC, and IPv6 Leaks: What They Are + How to Test/Fix

A VPN should hide your real public IP address. But privacy can fail if parts of your network stack take a different path than you expect. That’s what people mean by DNS leaks, WebRTC leaks, and IPv6 leaks—signals that can reveal your real network even while a VPN is “connected.”

What is a DNS leak?

DNS is how your device translates names like example.com into IP addresses. A DNS leak occurs when DNS queries go to your ISP (or another resolver) instead of going through your VPN’s DNS. Even if your web traffic is encrypted, DNS can reveal where you’re browsing.

Typical causes

• VPN app isn’t enforcing VPN DNS
• Custom DNS settings override the VPN
• Split tunneling excludes the browser

Fixes that work

• Enable “Use VPN DNS” (or similar) in the VPN app
• Disable “smart DNS” features unless you know why you need them
• Restart the VPN after changing DNS settings

What is an IPv6 leak?

Many networks provide IPv6 alongside IPv4. An IPv6 leak happens when your VPN tunnels IPv4, but your device still uses IPv6 directly to the internet, exposing your real IPv6 address.

Fixes that work

• Use a VPN provider that supports IPv6 properly
• Disable IPv6 temporarily if your VPN provider recommends it
• Re-check after every change

Background (and why this is common): IPv4 vs IPv6.

What is a WebRTC leak?

WebRTC enables real-time voice/video and peer-to-peer connections in browsers. In some configurations, WebRTC can reveal local or route-related IPs. Modern browsers have improved leak protections, but misconfigurations and extensions can still cause surprises.

Fixes that work

• Disable WebRTC (or limit it) in browser settings, if available
• Use a separate browser profile for privacy-sensitive sessions
• Remove conflicting network/privacy extensions temporarily to test

A safe, repeatable “leak test” process

1. Disconnect VPN → visit Check My IP → note ISP/location.
2. Connect VPN → run VPN Detection → confirm VPN IP/ASN.
3. Run DNS Lookup → confirm DNS resolver changes as expected.
4. If results are inconsistent, change one variable at a time (protocol, DNS setting, server).

DNS Technical Deep-Dive: DoH, DoT, DNSSEC, and Split-Horizon

Standard DNS queries travel in plaintext over UDP port 53. Your ISP, network administrator, or anyone on the path between you and the resolver can see exactly which domains you're looking up—even if you're using a VPN for all other traffic, if your DNS leaks outside the tunnel.

DNS-over-HTTPS (DoH)

DoH sends DNS queries inside HTTPS connections (port 443), making them indistinguishable from regular web traffic. Browsers like Firefox and Chrome have built-in DoH support. The benefit: your ISP can't easily read your DNS queries. The limitation: DoH only encrypts the query in transit—it doesn't prevent a DNS leak if the queries go to the wrong resolver. If your browser uses DoH to your ISP's own DoH endpoint, your ISP still sees everything.

DNS-over-TLS (DoT)

DoT encrypts DNS using TLS on a dedicated port (853). It's typically configured at the OS or router level rather than per-browser. Some VPN clients automatically use DoT to their own resolvers, providing end-to-end encrypted DNS that's also properly tunneled. The downside: port 853 is easily blocked by firewalls, which can trigger fallback to plaintext DNS.

DNSSEC

DNSSEC adds cryptographic signatures to DNS records, so you can verify that a response actually came from the authoritative server and wasn't tampered with. DNSSEC prevents DNS spoofing (someone injecting fake records) but it does not encrypt your queries—queries are still visible to observers. It's about integrity, not privacy.

Split-Horizon DNS

Split-horizon (also called split-brain) DNS is a configuration where different DNS responses are returned depending on where the query comes from. Corporate VPNs often use this: internal domain names (like intranet.company.com) resolve to internal IPs when queried through the VPN tunnel, while the same name returns nothing or a different address from outside. This is legitimate and intentional—but it can cause confusion when diagnosing leaks, because DNS behavior changes based on which resolver you reach.

How to check your DNS resolver manually

You can verify which DNS resolver your system is actually using without relying on a web tool:

• Windows: nslookup whoami.akamai.net — the "Server:" line shows your resolver's IP
• macOS/Linux: dig +short whoami.akamai.net or dig TXT o-o.myaddr.l.google.com @ns1.google.com
• Cross-check: Run our DNS Lookup tool and compare which server is resolving queries

If the resolver IP belongs to your ISP's ASN rather than your VPN provider's ASN, you have a DNS leak. Use our IP Lookup tool to check the ASN of any resolver IP.

WebRTC Technical Deep-Dive: STUN, TURN, ICE, and mDNS

WebRTC (Web Real-Time Communication) is a browser API enabling peer-to-peer audio, video, and data channels directly between browsers—without a central relay server. It's used in Google Meet, Discord, Zoom web client, and countless other applications.

How WebRTC discovers your IP (STUN/TURN/ICE)

To establish a peer-to-peer connection, WebRTC uses a protocol called ICE (Interactive Connectivity Establishment) which tries multiple connection paths in order:

1. Host candidates: The browser collects all local IP addresses (including local network IPs like 192.168.x.x) as potential connection points.
2. STUN candidates: The browser contacts a STUN (Session Traversal Utilities for NAT) server—typically at stun.l.google.com:19302—which tells the browser its public IP as seen from the outside. This is how your real public IP can leak even through a VPN: the STUN request may bypass the VPN tunnel.
3. TURN candidates: If direct connection fails, traffic is relayed through a TURN server. TURN requires authentication and is always proxied, so it doesn't expose your IP directly.

mDNS obfuscation

Modern browsers (Chrome 74+, Firefox 75+) now replace local IP addresses in WebRTC host candidates with an mDNS (multicast DNS) hostname like a1b2c3d4-xxxx.local. This prevents websites from learning your local network IP. However, your public IP via STUN is still potentially exposed if STUN requests bypass the VPN. Always test with our VPN Detection tool after connecting to your VPN.

Browser-specific WebRTC settings

• Firefox (about:config): Set media.peerconnection.enabled to false to fully disable WebRTC. Alternatively, set media.peerconnection.ice.default_address_only to true to restrict which IP is used for STUN candidates (less disruptive).
• Chrome / Edge: No built-in WebRTC disable option. Install the "WebRTC Leak Prevent" extension or use the flag --force-webrtc-ip-handling-policy=disable_non_proxied_udp. Note: Chrome extensions for WebRTC control may themselves pose a privacy risk—only install from trusted publishers.
• Brave Browser: Settings → Privacy and Security → WebRTC IP Handling Policy → select "Disable Non-Proxied UDP." This is the most user-friendly option and fully prevents public IP exposure via STUN without breaking all WebRTC functionality.
• Safari: WebRTC is disabled by default in the desktop version for non-HTTPS sites; the iOS version has additional restrictions. Generally the least leak-prone major browser.

How ISP DNS Reveals Your Location Even with a VPN

Here's a scenario that catches many users by surprise: you connect to a VPN, your public IP changes to a VPN server in another country—but a DNS leak test shows your ISP's DNS resolver is still being queried. This happens because:

• The VPN client pushes a new DNS server address to your OS, but your system ignores it (common on Windows with certain VPN protocols).
• A browser with DoH enabled continues querying the ISP's own DoH endpoint.
• An app bypasses system DNS entirely and has its own hardcoded resolver.

Even if your HTTP/HTTPS traffic is encrypted and routed through the VPN, every domain lookup going to your ISP's resolver tells them exactly which sites you're visiting. ISP resolvers are geographically placed—if your resolver is in Manchester, any geolocation service that checks DNS resolver location can infer you're in the UK, regardless of where your VPN IP is located.

VPN-Specific Leak Protection Settings

ProtonVPN

• Enable "DNS leak prevention" in Settings → Connection. ProtonVPN routes all DNS through its own resolvers inside the tunnel.
• Enable "IPv6 leak prevention" to block IPv6 outside the tunnel.
• The kill switch ("Always-on VPN") blocks all traffic if the tunnel drops, preventing brief IP exposure on reconnect.

Mullvad VPN

• Mullvad blocks all DNS except through its own servers by default—DNS leaks are essentially impossible when using the Mullvad app.
• IPv6 is supported through the tunnel natively; no special configuration needed.
• The "Lockdown Mode" (equivalent to kill switch) blocks internet access when VPN is disconnected.

ExpressVPN

• Uses its own "Lightway" protocol by default, which includes DNS leak prevention.
• IPv6 traffic is blocked (not tunneled) by default—this prevents leaks but means IPv6-only services won't work.
• The Network Lock kill switch covers both IPv4 and IPv6.

Step-by-Step Guide: Testing Each Leak Type

Testing DNS leaks

1. Connect to your VPN.
2. Open our DNS Lookup tool and look up a domain.
3. Check which server responded—it should belong to your VPN provider's ASN, not your ISP.
4. Additionally, run nslookup google.com in your command line—the "Server:" line should show the VPN's DNS resolver IP.

Testing WebRTC leaks

1. Connect to your VPN.
2. Visit our VPN Detection tool and check whether any local or public IPs appear that don't belong to the VPN.
3. If you see your real public IP in WebRTC results, apply the browser settings described above.
4. Retest after each change to confirm the fix worked.

Testing IPv6 leaks

1. Connect to your VPN.
2. Visit our IP check page—if an IPv6 address appears that belongs to your ISP (not the VPN provider), you have an IPv6 leak.
3. Use our IP Lookup tool to check the ASN of the IPv6 address shown.
4. Fix by enabling IPv6 protection in your VPN app or disabling IPv6 on the OS.

Frequently Asked Questions

Does incognito mode prevent DNS or WebRTC leaks?

No. Incognito/private browsing mode deletes your local browsing history and cookies after the session—it does nothing to change how your device sends DNS queries or handles WebRTC. Your DNS requests still go to whatever resolver your OS or browser is configured to use, and WebRTC still uses your real network interfaces. Incognito provides no protection against leaks.

Does DNS-over-HTTPS prevent DNS leaks?

Not reliably. DoH encrypts the DNS query in transit, but it doesn't prevent the query from going to the wrong resolver. If your browser's DoH is configured to use your ISP's DoH endpoint, the ISP still sees every lookup. And if the DoH query bypasses your VPN tunnel entirely—which it can, if the browser treats DoH as a system-bypass mechanism—then it's still a DNS leak. True DNS leak prevention requires that all DNS queries, regardless of protocol, are routed through the VPN tunnel to the VPN provider's resolver.

Related reading

• Public vs Private IP
• Why is my IP location wrong?