DNS Leak Test: What It Is and Why It Matters for Your Privacy

A DNS leak happens when your DNS queries bypass your VPN or encrypted DNS resolver and go to your ISP's resolver instead. The result is straightforward and serious: every website you visit is exposed to your ISP in cleartext, even when you believe you are fully protected. You could be connected to the most reputable VPN on the market, routing all your TCP and UDP traffic through an encrypted tunnel, and still be leaking the one piece of metadata that reveals your entire browsing pattern: the DNS query.

This is not a theoretical problem. DNS leaks are among the most common privacy failures for VPN users because they are silent. No error message appears. No connection drops. Your browser loads pages normally. The only difference is that your ISP's recursive resolver, rather than your VPN provider's resolver, is answering your domain lookups. That means your ISP has a complete log of every domain you resolve, timestamped and tied to your IP address.

Understanding what causes DNS leaks, how to detect them, and how to fix them is essential for anyone who uses a VPN, configures DNS for an organization, or simply wants to know who can see their browsing activity. This guide covers all three.

How DNS Leaks Happen

DNS leaks are not caused by a single vulnerability. They emerge from the interaction between your operating system, your network configuration, and your VPN client. There are five primary mechanisms, and each one operates independently. You can be protected against four of them and still be leaking through the fifth.

1. OS-Level DNS Settings Override the VPN Tunnel

When you connect to a VPN, the client is supposed to reconfigure your system's DNS settings so that all queries go through the tunnel. But operating systems have their own ideas. On Windows, the DNS client service can send queries out on all available network interfaces simultaneously and use whichever answer arrives first. This is called smart multi-homed name resolution (SMHNR), and it was designed for performance, not privacy. If your physical adapter's DNS is still set to your ISP's resolver, that resolver receives the query even though the VPN tunnel is active. macOS has a similar behaviour through its scoped DNS system, where each network interface maintains its own resolver list and the system decides which one to use based on routing metrics.

2. IPv6 Queries Bypass an IPv4-Only VPN

Many VPNs only tunnel IPv4 traffic. If your system has IPv6 connectivity, which most modern networks provide by default, your DNS queries can travel over IPv6 directly to your ISP's resolver, completely outside the VPN tunnel. The VPN client does not even see these packets because they are on a different protocol stack. This is one of the most common leak vectors, and it is invisible to anyone who only tests with IPv4 tools.

3. WebRTC Leaking Your Local IP

WebRTC, the browser API used for real-time communication like video calls, can enumerate local network interfaces and expose your real IP address to JavaScript running in the page. While this is technically an IP leak rather than a DNS leak, it often leads to DNS exposure as well: once your real IP is known, an adversary can infer your ISP and correlate it with DNS traffic observed on that network. Browsers expose this functionality by default, and it operates outside the VPN tunnel unless explicitly disabled.

4. Split-Tunnel VPN Configurations

Split tunnelling is a VPN feature that routes only certain traffic through the tunnel, letting the rest go directly to the internet. This is common in corporate VPNs where only internal resources need tunnel access. The problem is that DNS queries for external domains often follow the direct path rather than the tunnel, reaching your ISP's resolver. Even when the VPN client is configured to force DNS through the tunnel, split-tunnel mode can create routing exceptions that bypass that rule.

5. DHCP-Assigned DNS After Network Changes

When you switch networks, say from home Wi-Fi to a coffee shop or mobile hotspot, your system receives a new DHCP lease that includes DNS server addresses. Some VPN clients do not re-assert their DNS configuration after a network change, meaning your system silently reverts to using whatever DNS server the local network provides. This is especially dangerous on public networks where the DNS server itself may be compromised or monitored.

What a DNS Leak Reveals About You

Even with HTTPS encrypting the content of your web traffic, DNS queries are cleartext by default. Every domain you visit requires a DNS lookup before the encrypted connection is established. That means anyone who can observe your DNS traffic, your ISP, a network operator, or anyone monitoring the path between you and the resolver, can see every domain you resolve.

This is not just metadata in the abstract. A DNS query log reveals which news sites you read, which health resources you consult, which financial services you use, which messaging platforms you connect to, and what time you do all of it. In jurisdictions where ISPs are required to retain browsing data, DNS logs are the primary data source. In environments with surveillance concerns, DNS traffic is the lowest-hanging fruit for monitoring because it is unencrypted, predictable in format, and trivial to log at the resolver level.

The privacy implication of a DNS leak is therefore not theoretical. If you are using a VPN specifically to prevent your ISP from seeing your browsing activity, a DNS leak renders that entire effort pointless. The encrypted tunnel protects the content of your connections, but the DNS leak hands your ISP a complete list of every server you connected to.

How to Test for DNS Leaks

Testing for DNS leaks is straightforward once you understand what to look for. The goal is to determine which DNS resolver is actually answering your queries. If you are connected to a VPN, the resolver should belong to your VPN provider. If you see your ISP's resolver instead, you have a leak.

1. Connect to your VPN as you normally would.
2. Open a terminal and run the diagnostic queries shown below.
3. Check which resolver responds. If the IP address belongs to your ISP rather than your VPN provider, your DNS queries are leaking.
4. Repeat the test on both IPv4 and IPv6 to catch protocol-specific leaks.
5. Test again after switching networks (Wi-Fi to mobile, etc.) to verify the VPN reasserts DNS correctly.

The following commands use public diagnostic endpoints to reveal which resolver is handling your DNS queries.

# Returns the IP of the resolver that queried Akamai on your behalf
dig +short whoami.akamai.net

# Returns the resolver identity via DNSCrypt's diagnostic endpoint
dig +short resolver.dnscrypt.info TXT

# Alternative: query Cloudflare's diagnostic endpoint
dig +short whoami.cloudflare CH TXT @1.1.1.1

# Check your resolver via Google's DNS diagnostic
dig +short o-o.myaddr.l.google.com TXT @8.8.8.8

The whoami.akamai.net query is particularly useful because it returns the IP address of the recursive resolver that contacted Akamai's authoritative server on your behalf. If that IP belongs to your ISP (you can check with a reverse IP lookup or WHOIS query), your DNS queries are not going through your VPN tunnel.

For a more thorough test, run these queries on both IPv4 and IPv6 explicitly.

# Force IPv4 resolution
dig -4 +short whoami.akamai.net

# Force IPv6 resolution - if this returns your ISP's resolver,
# you have an IPv6 DNS leak even if IPv4 is tunneled
dig -6 +short whoami.akamai.net

# Check if IPv6 is active on your system
ip -6 addr show  # Linux
ifconfig | grep inet6  # macOS

If the IPv4 query returns your VPN's resolver but the IPv6 query returns your ISP's resolver, you have a classic IPv6 DNS leak. This is one of the most common leak types and one of the easiest to miss.

DNS-over-HTTPS and DNS-over-TLS: The Encryption Fix

Traditional DNS sends queries and responses as unencrypted UDP packets on port 53. Anyone on the network path can read them. Two protocols were designed to fix this: DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT).

DNS-over-TLS (DoT), defined in RFC 7858, wraps DNS queries in a TLS connection on port 853. This encrypts the content of your queries so that network observers cannot read them. The limitation is that port 853 traffic is distinctive: a network administrator or firewall can identify and block DoT traffic specifically because nothing else commonly uses that port.

DNS-over-HTTPS (DoH), defined in RFC 8484, sends DNS queries as HTTPS requests on port 443, the same port used by all regular web traffic. This makes DoH queries indistinguishable from normal HTTPS traffic at the network level, which means they cannot be selectively blocked without blocking all HTTPS traffic. For privacy, this is the stronger option in restrictive network environments.

Both protocols prevent DNS leaks at the protocol level. Even if a query somehow escapes the VPN tunnel, it is encrypted and cannot be read by the ISP's network equipment. The resolver still sees the query, but the path between you and the resolver is protected.

Browser-Level DoH Support

Firefox, Chrome, Brave, and Edge all support built-in DoH. Firefox has shipped with DoH enabled by default in the US since 2020, using Cloudflare's 1.1.1.1 resolver. Chrome and Edge use DoH opportunistically: if your configured DNS provider supports DoH, the browser upgrades to it automatically. Brave offers DoH configuration in its privacy settings. For more detail on Cloudflare's implementation, see the Cloudflare encrypted DNS documentation.

Browser-level DoH protects queries made by the browser itself. It does not protect queries made by other applications on your system, including system services, email clients, chat applications, or command-line tools. For system-wide protection, you need OS-level DoH or DoT configuration.

Fixing DNS Leaks

Fixing a DNS leak requires addressing the specific mechanism that is causing it. In most cases, more than one fix is needed because multiple leak vectors can be active simultaneously.

1. Use a VPN that forces all DNS through the tunnel. The VPN client should override your system's DNS settings when connected and block DNS traffic on all interfaces except the tunnel. Check your VPN provider's documentation for a "DNS leak protection" or "kill switch" feature.
2. Configure DoH or DoT at the OS level. On Windows 11, you can enable DNS-over-HTTPS in Settings > Network & Internet > your adapter > DNS. On macOS, use a DNS profile or a local proxy like dnscrypt-proxy. On Linux, systemd-resolved supports DoT natively via the DNSOverTLS=yes directive.
3. Disable IPv6 if your VPN does not tunnel it. This eliminates IPv6 DNS leaks entirely. On Linux: `sysctl -w net.ipv6.conf.all.disable_ipv6=1`. On macOS: `networksetup -setv6off Wi-Fi`. On Windows: uncheck IPv6 in your adapter properties. Re-enable it when not using the VPN.
4. Disable WebRTC in your browser. In Firefox, set `media.peerconnection.enabled` to `false` in about:config. In Chrome and Brave, use an extension like WebRTC Leak Prevent. This stops browsers from exposing local IPs through the WebRTC API.
5. Disable Windows smart multi-homed name resolution. Use Group Policy or a registry edit to disable SMHNR, which prevents Windows from querying DNS on all interfaces simultaneously. The policy is under Computer Configuration > Administrative Templates > Network > DNS Client > Turn off smart mul...
6. Test after every OS update, VPN update, or network change. Leak conditions can reappear silently after updates change network configuration defaults. Make DNS leak testing part of your post-update verification routine.

DNS Leaks vs IP Leaks vs WebRTC Leaks

These three leak types are often confused because they all compromise privacy, but they expose different information through different mechanisms.

• DNS leak: Your DNS queries reach a resolver outside the VPN tunnel, revealing which domains you visit. Detected by checking which resolver handles your queries.
• IP leak: Your real IP address is exposed to the destination server, typically through routing failures, IPv6 fallback, or misconfigured proxies. Detected by checking your visible IP from the server side.
• WebRTC leak: Your browser's WebRTC API exposes local and public IP addresses to JavaScript, bypassing VPN tunnel routing entirely. Detected by querying STUN servers from within the browser.

A DNS leak is the most common of the three because DNS resolution is a constant background activity that happens before every connection, and most VPN implementations have historically treated it as an afterthought. IP leaks and WebRTC leaks tend to be more visible in testing because they directly expose your address. DNS leaks are silent: your connection works normally, and only the resolver sees the difference.

All three should be tested independently. Passing one test does not guarantee the others. Tools like the DomScan DNS Lookup can help verify which resolvers are responding to your queries, and the Domain Health checker provides a broader view of DNS, SSL, and email posture for any domain you control.

DNS Leak Testing for Enterprise and Ops Teams

DNS leak testing is not only a personal privacy concern. For enterprise and operations teams, it is a policy enforcement question. Organizations deploy internal DNS resolvers, DNS filtering, and split-horizon DNS for legitimate reasons: compliance, security policy, data loss prevention, and network segmentation. A DNS leak on a corporate endpoint means that device is bypassing all of those controls.

If an employee's laptop resolves domains through a public resolver instead of the corporate one, DNS-based security filtering is not applied, internal-only domains may fail to resolve, and DNS logs used for incident response will have gaps. For compliance-sensitive environments, this is not a minor configuration issue. It is a control failure that auditors will flag.

Enterprise teams should include DNS leak checks in endpoint compliance policies, run periodic audits to verify that DNS traffic from managed devices actually reaches the intended resolver, and monitor for anomalous DNS traffic patterns that suggest resolver bypass. The DNS Lookup API can be integrated into automated compliance checks, and SSL certificate inspection helps verify that encrypted DNS connections are terminating at the expected resolver.

Building a DNS Leak Test Into Your Workflow

A one-time DNS leak test tells you the current state. A repeatable test built into your workflow tells you when conditions change. The simplest approach is a script that runs the diagnostic queries on VPN connect and alerts you if the resolver does not match the expected value.

#!/bin/bash
# Run after VPN connects. Exit 1 if leak detected.
EXPECTED_RESOLVER="10.8.0.1"  # Your VPN's DNS resolver

ACTUAL=$(dig +short +time=3 whoami.akamai.net 2>/dev/null)

if [ -z "$ACTUAL" ]; then
  echo "[WARN] DNS diagnostic query failed"
  exit 1
elif [ "$ACTUAL" != "$EXPECTED_RESOLVER" ]; then
  echo "[LEAK] DNS resolver is $ACTUAL, expected $EXPECTED_RESOLVER"
  exit 1
else
  echo "[OK] DNS resolver matches VPN: $ACTUAL"
  exit 0
fi

Many VPN clients support post-connect scripts or hooks where this kind of check can run automatically. OpenVPN supports the `--up` flag for running scripts after tunnel establishment. WireGuard's `PostUp` directive serves the same purpose. Integrating a DNS leak check at this point catches configuration regressions immediately rather than leaving them undetected for days or weeks.

For a broader view of your domain's DNS configuration, the DNS Glossary provides a reference for understanding resolver behaviour, record types, and the resolution chain that determines where your queries ultimately land.