What Is DNS Leakage? (VPN Security Flaw)
DNS leakage occurs when a device sends domain-name lookups outside the VPN tunnel, even while other traffic uses the VPN. Those queries can reveal resolver and browsing metadata to a network operator or internet provider. Preventing leaks means routing or blocking every DNS path, including IPv6, split-tunnel apps, and browser-managed encrypted DNS.
Plan the DNS Privacy Policy
A DNS privacy policy states which resolver may receive your lookups and which network path those lookups must use. Before changing settings, identify the VPN, operating system, active network interfaces, and apps in scope. The goal is simple: route or block every DNS request outside the tunnel.
DNS, or the Domain Name System, translates names such as example.com into network addresses. A DNS query may disclose the domain being requested, though it does not by itself show the full page URL or prove what content you viewed. A VPN is meant to carry traffic through an encrypted tunnel, but its protection depends on the routes and rules actually in force.
I use the least-bypass principle: allow DNS through the VPN’s intended resolver, and block DNS from escaping by any other route. DNS standards describe how DNS works; they do not certify that a VPN prevents leaks. A “connected” label is not proof that every app follows the same route.
Conventional DNS commonly uses UDP port 53. TCP port 53 is also part of DNS operation, including cases where a response is truncated or a larger response is needed. DNS over TLS (DoT) uses TCP port 853 by default. DNS over HTTPS (DoH) carries DNS messages over HTTPS; port 443 is typical, but not a DNS-specific requirement.
| DNS method | Common transport and port | What to check |
|---|---|---|
| Conventional DNS | UDP and TCP, port 53 | Whether either protocol leaves on the physical interface |
| DoT | TCP, port 853 by default | Whether the connection uses the VPN route |
| DoH | HTTPS, often port 443 | Which app selected the resolver and how that app is routed |
Encryption and VPN routing are separate questions. A DoH query can be encrypted yet still bypass the VPN. Likewise, changing a system DNS address does not prove that the new resolver is reached through the tunnel. Next step: write down which resolver and apps your policy permits.
Check IPv4, IPv6, and Application Routing
Start by surveying the device while the VPN is connected. Record the VPN client and version, operating system, active IPv4 and IPv6 interfaces, configured system resolvers, and any split-tunnel rules. Note which apps are excluded from the tunnel. Repeat the survey after changing networks or VPN settings, since routes and resolvers can vary by connection.
On Linux, ip route lists IPv4 routes and ip -6 route lists IPv6 routes. resolvectl status may show resolver configuration on systems using systemd-resolved. On Windows, PowerShell’s Get-DnsClientServerAddress displays DNS server addresses, while Get-NetRoute lists routes. On macOS, scutil --dns shows resolver configuration; netstat -rn lists routing information.
These commands describe configuration; they do not, on their own, prove where a query traveled. A listed public resolver may still be reached through the VPN, and a listed VPN resolver does not prove that every app uses it. Compare the routes with the VPN provider’s documented behavior and check the actual network traffic.
Pay special attention to browser-managed DoH. A browser may send DNS requests to its own chosen resolver instead of using the operating system’s resolver. That can bypass the system-level DNS path while keeping the query encrypted. A conventional leak-test site may therefore show the expected resolver but still miss a browser policy bypass. Check the browser’s secure-DNS setting and the network path used by that browser.
Split tunneling creates another possible bypass. An excluded app may send its DNS request outside the tunnel, even if other apps use the VPN. Next step: list each active route and DNS-capable app, then decide whether it must use the tunnel or be blocked when the tunnel is down.
Configure the VPN and Resolver
Configure the VPN to use its documented DNS resolver or another resolver deliberately selected for use through the tunnel. Then close alternate paths: account for IPv6, excluded apps, and browser DoH. A kill switch or firewall rule should block traffic when the tunnel fails, rather than silently allowing DNS onto the ordinary connection.
First, set the VPN client’s DNS option according to its documentation. If you choose a separate resolver, confirm that it is reachable through the tunnel and that the VPN’s routing rules cover it. Avoid assuming that manually entering a DNS address changes the route taken to reach it.
Decide what to do with IPv6. If the VPN supports IPv6, confirm that IPv6 traffic and DNS use the tunnel. If it does not, follow the provider’s documented guidance for preventing an outside IPv6 route; do not assume that IPv4 protection covers it. Avoid disabling IPv6 system-wide without understanding the effect on your network and apps.
Finally, set browser DoH to follow your chosen policy. Depending on the browser and VPN, that may mean disabling browser-managed DoH so the system resolver is used, or configuring the browser’s resolver and ensuring its traffic stays inside the tunnel. Encrypted DNS alone is not evidence of VPN protection. Next step: test the normal connected state and the tunnel-loss state separately.
Verify for Leaks and Fail-Closed Behavior
Verification checks the route taken by real DNS traffic, not just the settings shown in an app. Test while connected, then test what happens when the tunnel drops. Look at IPv4, IPv6, and relevant applications, and use more than one method because a single website may not detect every bypass.
A leak test website can provide a useful check, but treat it as one signal. Results can be affected by caching, browser DoH, IPv6, and split tunneling. A test may show a resolver associated with the VPN while another application uses a different path. Repeat tests in the browser and apps that matter to your policy.
For a stronger check, inspect traffic on both the physical network interface and the VPN interface. On Linux, first identify interfaces with ip link, then capture on the physical interface using:
sudo tcpdump -ni <physical-interface> '(udp port 53 or tcp port 53 or tcp port 853)'
Replace the placeholder with the actual interface name. A matching DNS packet on the physical interface is a warning that conventional DNS or DoT may be leaving outside the tunnel. Capture on the VPN interface as well to compare. Do not treat the absence of those ports as proof that no DNS escaped: DoH commonly uses HTTPS, often port 443, and is not reliably identified by a simple port filter.
Wireshark can help inspect captures with the display filter dns || tcp.port == 853. That filter can identify many conventional DNS packets and DoT connections, but it will not reliably identify DoH among ordinary HTTPS traffic. For DoH, check the browser’s selected resolver and whether the browser’s connection follows the VPN route. Encrypted payloads may prevent a packet capture from showing the queried domain.
Repeat the check with the VPN connected and after a controlled disconnect. Confirm that the kill switch blocks outside DNS and other traffic as intended; do not rely only on an icon or status message. Test both IPv4 and IPv6, and test excluded apps separately. The practical pass condition is that no DNS request uses an unapproved path, and that tunnel loss does not open an outside route.
Illustrative case: IPv6 takes a different route
A laptop’s VPN protects IPv4, but its network also has active IPv6. The user checks a DNS test in one browser and sees the VPN resolver, yet an IPv6 request from another app may still use the regular network. The remedy is to verify IPv6 routing and DNS traffic, then configure the VPN or network policy to cover or block that path.
Illustrative case: Browser DoH bypasses system DNS
A user sets the operating system to the VPN’s resolver, but the browser has DoH enabled with a separate provider. The browser’s DNS request can avoid the system resolver while remaining encrypted. The user must check the browser’s resolver and whether its HTTPS connection follows the VPN route, rather than relying on a conventional DNS test alone.
Conclusion and FAQ
A DNS leak is a routing or policy failure: a query takes a path outside the VPN’s intended protection. The durable fix is not simply a new resolver address or encrypted DNS setting. Survey interfaces and apps, define the permitted route, configure fail-closed behavior, and verify actual traffic for IPv4, IPv6, and browser DNS.
What does DNS leakage mean with a VPN?
DNS leakage means a device sends DNS queries outside the VPN’s intended tunnel or resolver path. This can expose DNS-related metadata to the network handling that outside traffic. It does not automatically reveal every page or action, but it means DNS is not following the privacy policy you expected.
Does encrypted DNS prevent a VPN leak?
No. DoH and DoT encrypt DNS messages between a device and resolver, but encryption does not prove that the connection uses the VPN tunnel. An encrypted query can still travel over the ordinary network route, so verify both the resolver and the network path.
Which ports should I check for DNS traffic?
Conventional DNS uses UDP port 53, and TCP port 53 is also used for DNS operations. DoT uses TCP port 853 by default. DoH travels over HTTPS, often on port 443, but that port is not specific to DNS and cannot identify DoH by itself.
Can IPv6 cause a DNS leak?
Yes. If a VPN’s protections cover IPv4 but an active IPv6 route remains outside the tunnel, IPv6 traffic can bypass the intended policy. Check IPv6 routes and DNS behavior separately, then follow the VPN provider’s guidance for covering or blocking that path.
Can a browser cause a DNS leak?
Yes. A browser with its own DoH setting may use a resolver separate from the operating system’s resolver. That request can bypass the system DNS policy while remaining encrypted. Check the browser’s resolver choice and whether its network connection follows the VPN route.
Is one DNS leak-test website enough?
No. A website is a useful check, not a complete audit. Caching, browser-managed DoH, IPv6, and split tunneling can affect what it sees. Combine a leak test with route inspection, settings review, and traffic checks on the physical and VPN interfaces.
What should happen when the VPN disconnects?
If your policy requires all traffic to use the VPN, a kill switch or firewall rule should block outside DNS and other traffic when the tunnel drops. Test this behavior deliberately, and confirm it for IPv4, IPv6, and any apps excluded from the tunnel.
Does changing my DNS server fix a leak?
Not by itself. Changing the configured resolver changes where a query is directed, but it does not prove that the route to that resolver passes through the VPN. Confirm the VPN’s DNS policy and inspect the actual path taken by queries.
(This article was written by one of our staff writers, Garrett Vance. Visit our Meet the Team page.)
