A VPN can change the public IP address a website sees while still leaving DNS to take a different path. In practice, you can have a perfectly normal VPN egress IP while name resolution still prefers the physical Wi-Fi or Ethernet interface. The tunnel is up; the browser reaches the web through the VPN, but DNS uses a different policy.
That is the classic DNS leak scenario. The complication is that modern DNS no longer means only UDP port 53 to an ISP resolver. Traditional DNS can use UDP or TCP on port 53; browsers can use DNS over HTTPS; operating systems can keep per-interface DNS state; enterprise VPNs can apply split-DNS rules; and VPN providers can legitimately use third-party recursive resolvers.
So an unfamiliar resolver name is not enough to call a leak. The useful engineering question is whether the DNS resolution followed the route and policy you intended.
This guide is cluster #1 under the What Is a VPN Leak? pillar. If you want to check your own connection while reading, you can run a DNS leak test and compare the result against the baseline described below.
01 / Definition
What is a DNS leak?
A DNS leak occurs when DNS traffic that should follow a VPN-protected or otherwise intended DNS path instead uses an unintended interface, resolver, transport path, or fallback route.
A common example is a full-tunnel VPN that correctly carries web traffic while the operating system continues to send DNS queries to a resolver reachable through the physical adapter.
The VPN can still report “Connected,” and websites can still see the VPN server’s public address. The leak exists because DNS does not align with the policy intended to protect it. A standard IP checker cannot prove or disprove that.
02 / Quick answer
Quick answer
| Situation | Leak? | How to read it |
|---|---|---|
| ISP resolver is reached outside a VPN that is supposed to tunnel DNS | Usually yes | The DNS path is bypassing the intended tunnel. |
| VPN-provided resolver is reached through the VPN | Normally no | Resolver selection and path match the VPN policy. |
| Cloudflare, Google, Quad9, or another public resolver is reached through the VPN with DoH | Not automatically | The resolver is third-party, but the encrypted connection can still be routed inside the VPN. |
| Corporate names use VPN DNS while public names use another resolver by design | Not necessarily | This can be intentional split DNS. |
| DNS falls back to the normal interface during reconnect | Potentially | Protected DNS is failing open during a state transition. |
| The DNS test reports an unfamiliar resolver location | Not enough evidence | Resolver branding or geolocation does not prove the client-to-resolver route. |
The resolver’s identity and its DNS transport path are connected but not identical.
03 / Model
How DNS actually works
To reach a name like example.com, an application usually requests an answer from a local or stub resolver; this resolver is part of the operating system, the browser, or some other local service.
The recursive resolver can return a cached answer; if no usable cached answer is available, it performs the necessary resolution process, following delegations until it obtains an answer, a negative response, or another terminal result.
A recursive resolver and an authoritative server are different roles. The recursive side resolves names on behalf of clients; the authoritative side serves data for the zones it is authoritative for. RFC 9499 is the current IETF terminology reference for these roles.
Your device could be sending DNS requests to an ISP’s resolver, a VPN resolver, an enterprise resolver, a public service, or a home gateway functioning as a DNS proxy or forwarder. Choosing one of those options does not mean there is a leak. The policy determines what is acceptable.
04 / Model
What changes when you connect to a VPN?
A full-tunnel VPN generally alters more than the standard web route. Depending on the client and operating system, it may create a virtual interface, install IPv4 and IPv6 routes, assign DNS server addresses, apply name-resolution policy, or install firewall rules that prevent protected traffic from falling back to the physical interface.
DNS can therefore be designed in more than one valid way:
Both designs may be right. The second one is why “the DNS server does not belong to my VPN provider” is a weak leak detector: to detect a leak, you have to know how the connection reached that resolver.
05 / Distinction
Resolver identity vs. DNS transport path
When investigating a suspected DNS leak, separate two questions immediately:
- What resolver was used to handle the query?
- Which interface and which route carried the DNS exchange to that resolver?
Resolver identity does not prove the route. A familiar resolver can be reached through the wrong interface, and a third-party resolver can be reached correctly through the VPN.
Case 1: ISP DNS bypasses the tunnel
The VPN policy says DNS should be protected, but the host sends the query through the physical interface.
It is a true DNS routing leak if the policy in question is full-tunnel DNS.
Case 2: A public DoH resolver is reached through the VPN
A browser can use DNS over HTTPS (DoH) via Cloudflare, Google, Quad9, or another DoH service, while the HTTPS connection itself still goes through the VPN.
The resolver is third-party, and the route is still protected; it would be incorrect to describe this as a leak solely based on the resolver’s branding. Since RFC 8484 defines DoH as DNS carried over HTTPS, the usual route selection for that HTTPS connection remains relevant.
Case 3: Deliberate split DNS
Enterprise VPNs commonly direct different namespaces to different resolvers on purpose:
- Internal namespace — corp.example → VPN DNS / corporate resolver
- Public namespace — public.example → local or public resolver
This is known as split DNS, and it does not by itself constitute a leak. On Windows, name-resolution behavior can be affected by the Name Resolution Policy Table (NRPT), the DNS suffix policy, and the interface preference. The right test is whether the actual resolution path conforms to the configured namespace policy.
06 / Interpretation
What can a DNS leak reveal?
A DNS leak does not expose the same information as an IP leak.
The resolver or first-hop DNS service receiving your query can see the queried name and the source address of that client-to-resolver transport. If that transport bypasses the VPN, it may see an ISP-side source address or NAT/CGNAT egress rather than a VPN-side source. A DNS leak test’s authoritative server, however, usually sees the recursive resolver or forwarder that ultimately queried it, not your workstation directly.
DNS data can show when domain names are being resolved. It does not automatically make it possible to discover the full URL, the contents of pages, passwords, form data, or other activity that occurs after the connection is established. That kind of information belongs to other protocol layers.
That is still useful privacy information, but the claim that “a DNS leak exposes your entire browsing history” is an overstatement.
Can a DNS leak reveal your browsing history?
Not as a straightforward copy of your browser history. DNS can show the hostnames that your device asks to resolve, which can still be sensitive, but it does not reveal the complete URL or the contents of an HTTPS session.
Example: https://example.com/private/account?id=123
DNS normally resolves only example.com. The path, the query string, the page contents, the credentials, and the form data belong to other protocol layers. The privacy impact is genuine, but it should not be overstated.
07 / Comparison
DNS leak vs. IP leak
They can happen independently.
Example: public IPv4 is the VPN egress address, while the DNS path uses the normal ISP interface.
In that state, the IP check passes while DNS violates policy. The opposite is also possible: DNS looks correct, while another application, an IPv6 flow, or a browser path bypasses the tunnel.
An IP checker checks the source address associated with the request. A DNS leak test examines name-resolution behavior. An IPv6 test checks IPv6 reachability and routing. A WebRTC test looks at the browser-exposed ICE/network candidates — how to classify those is covered in What Is a WebRTC Leak? No single one of these tests can show by itself that the entire VPN is working correctly.
Related tool: IP Lookup — inspect the network, ASN and registration behind any resolver or egress address you observe.
08 / Interpretation
Reading the resolver name
Does seeing your ISP DNS mean you have a DNS leak?
If a full-tunnel VPN is supposed to carry DNS and your baseline ISP resolver remains active after the VPN is connected, that is strong evidence that something needs investigation.
Confirm the policy and the route before making the final decision. Names assigned to resolvers, anycast infrastructure, forwarding, and provider branding can all make a result look more obvious than it actually is.
The most appropriate way to compare is before and after: first note the resolver’s usual behavior, then connect the VPN, and finally check whether the baseline path on the ISP’s side is still present when it should not be.
Does seeing Cloudflare, Google, or Quad9 mean the VPN is leaking?
No. A public resolver can be intentional, browser-selected, enterprise-enforced, or used by the VPN provider itself.
The resolver owner tells you who handled the query. It does not tell you which interface your host used to reach that service. To prove a tunnel bypass, you need route evidence, not just a provider name.
Why a DNS resolver may appear in the “wrong” country
Resolver geolocation is a weak signal. Anycast, distributed resolver infrastructure, forwarding, registration data, and stale geolocation databases can all cause a resolver to appear in the wrong city or country on a test page.
Do not diagnose a DNS leak from a location label. Compare the resolver network and route to the baseline and to the VPN’s documented DNS design.
09 / Transport
DNS over HTTPS (DoH) and VPN leaks
DoH carries DNS messages inside HTTPS. RFC 8484 specifies the protocol and its TLS-based confidentiality and integrity properties.
Both DNS services are encrypted, but only the first one uses the VPN route. Encryption safeguards DNS transmission, while routing determines which interface carries it.
DoH also means a packet capture will not show ordinary UDP/53 queries from that browser. On the wire, it looks like HTTPS traffic to the DoH service.
10 / Transport
DNS over TLS (DoT) and VPNs
DNS over TLS protects DNS with TLS and, by default, uses TCP port 853. RFC 7858 focuses on protecting stub-to-recursive DNS traffic against passive observation and on-path tampering.
The VPN question remains: which route is used to reach the DoT resolver? An encrypted DNS session can still bypass the VPN, and a third-party DoT resolver can still be reached through the VPN.
11 / Transport
Browser secure DNS vs. VPN DNS
Modern browsers can choose DNS independently of the operating system. That is one of the first things to check when a browser leak test disagrees with the host DNS configuration.
For example, Windows may be using a VPN-provided resolver while the browser sends DoH to its own configured endpoint. A browser-based test will then report the browser’s resolver. That can be expected if the DoH connection itself follows the VPN route.
When troubleshooting, keep three separate variables in mind: resolver selection, transport security, and route selection. A single green or red badge cannot describe all three.
12 / Policy
What is split DNS?
Split DNS deliberately sends different namespaces to different resolvers. It is common in enterprise VPNs because internal names may only exist behind the corporate tunnel.
A split-DNS design becomes a leak only when actual resolution behavior violates the intended namespace policy. A local query is not automatically wrong just because a VPN is connected.
13 / Distinction
DNS leak vs. DNS hijacking
These are different failures. A DNS leak is mainly a path or policy problem: queries go somewhere they were not supposed to go. DNS hijacking is a redirection or answer-manipulation problem in which queries are intercepted, sent to an unauthorized resolver, or answered with altered data.
A system can experience one without the other. Keeping the terms separate makes troubleshooting much faster.
14 / Method
How to test for a DNS leak properly
Do not start with the VPN already connected. Establish a baseline first.
Step 1: Record the baseline
- Public IPv4 and public IPv6 connectivity.
- ISP or network owner / ASN.
- DNS resolver results.
- Browser Secure DNS / DoH setting.
- Whether the device is using Wi-Fi, Ethernet, cellular, or more than one active interface.
If your public address is dynamic, record the network owner / ASN and the exact IP address. That gives you a more stable comparison.
Test your DNS path
Run a DNS leak test now to record your baseline resolver behavior, then repeat it after connecting the VPN and compare.
Run DNS Leak TestStep 2: Connect the VPN you actually intend to use
Make sure the server, protocol, and mode are confirmed. Check whether the product is configured for full-tunnel, split-tunnel, browser-only, or custom DNS. Carrying out a leak test makes no sense if you do not know the policy you are testing.
Step 3: Repeat the DNS test
Compare actual resolver results rather than relying solely on a “safe” badge. Look for baseline ISP infrastructure that remains active unexpectedly, new resolvers that match the VPN design, and browser-level DoH that could explain a third-party result.
Step 4: Test the route, not just the resolver name
When the result is ambiguous, identify the resolver IP and determine which interface and source address the operating system would use to reach that destination. This separates resolver selection from the routing question.
Step 5: Test state changes
Repeat the test after reconnect, sleep/wake, or a safe network transition. DNS leaks often appear during state changes rather than during a stable tunnel.
15 / Scope
What a browser DNS leak test can and cannot tell you
A good DNS leak test typically triggers lookups for unique, cache-busting names within a domain controlled by the test. Its authoritative DNS infrastructure then observes which recursive resolver or forwarder ultimately asks for those names.
That is useful evidence, but it is not a packet capture of your workstation. The authoritative side sees the recursive infrastructure reaching it; it does not automatically see every hop between your browser and that resolver.
The results can be influenced by forwarders, caches, anycast, encrypted DNS, and multi-layer resolver designs. For a consumer test this is generally sufficient to detect obvious ISP leakage, but an engineering investigation needs to examine the host route and, if needed, capture the packets.
Why multiple DNS servers may appear
Seeing several resolver addresses in one test is not automatically suspicious. Multiple results can reflect resolver redundancy, multiple recursive egress nodes, browser DoH alongside system DNS, more than one active interface, VPN DNS pools, forwarding, or anycast infrastructure.
Compare the results with your baseline and the intended policy. In a supposed full-tunnel test, one expected VPN-side resolver plus a known baseline ISP resolver deserves investigation; several addresses belonging to the same expected resolver network usually do not.
16 / Causes
Common causes of DNS leaks
- The physical interface retains usable DNS servers and the resolver policy still selects them even though the VPN expects exclusive DNS handling.
- A missing or incorrect route to the intended resolver.
- The browser overrides the operating system’s resolver selection.
- Intentional or accidental split tunneling.
- IPv6 uses a different path from IPv4.
- Enterprise NRPT or namespace policy sends selected names elsewhere.
- Multiple active adapters or virtual interfaces have competing metrics.
- Another VPN, endpoint-security agent, DNS filter, proxy, or virtual-adapter policy changes DNS or routing behavior.
- Fail-open behavior during startup, reconnect, sleep/wake, or network switching.
A healthy tunnel does not mean a healthy DNS policy. “Connected” refers to the VPN session; it does not indicate that name resolution follows the route you wanted.
17 / Failure modes
DNS leaks during disconnects and reconnects
Steady-state testing is not enough. A VPN can route DNS correctly for hours and still fail open for a few seconds during a transition.
A kill switch or firewall policy is meant to prevent that fallback. The presence of a “Kill Switch” toggle is not proof; test the failure state.
18 / Fixes
How to fix a DNS leak
Start by identifying the layer that is wrong. Do not change several network settings at once.
- Confirm the VPN mode and whether DNS is expected to be full-tunnel, split by namespace, or application-specific.
- Check split-tunnel and application-exclusion rules.
- Verify the VPN DNS settings and the DNS servers assigned to each interface.
- Before considering a third-party resolver to be a leak, check the browser’s Secure DNS / DoH settings.
- Check IPv4 and IPv6 separately. Also look for another VPN, security agent, DNS filter, proxy, or virtual adapter that can change routing or DNS policy.
- If the leak occurs only during reconnects, check the fail-closed / kill-switch behavior.
- Change one variable, then test again.
That last step matters. Changing five things at once may make the symptom disappear, but you will not know what actually fixed the path.
19 / Engineering
How an engineer can verify the DNS path
If the result given by the browser does not make sense, check the host directly. The specific commands differ by platform, but the aim is the same: determine the configured resolver, the selected interface, the source address, and the route to the resolver.
Windows
Get-NetIPConfiguration
Get-DnsClientServerAddress
Get-DnsClientNrptPolicy -Effective
Find-NetRoute -RemoteIPAddress <resolver-ip>
Test-NetConnection <resolver-ip> -InformationLevel DetailedGet-DnsClientNrptPolicy -Effective is useful when namespace policy is involved. Find-NetRoute shows the best local address and route to a remote IP, which is exactly the question you need when checking whether a resolver is reached through the VPN interface or the physical adapter.
Windows VPN name resolution can also depend on NRPT matches, DNS suffix policy, and interface preference, so the DNS server shown on one adapter is not a complete description of every query on the system.
Linux
resolvectl status
resolvectl query example.com
ip route
ip -6 route
ip route get <resolver-ip>
ip -6 route get <resolver-ipv6>On systems that use systemd-resolved, resolvectl status displays the DNS servers and routing domains associated with each link. ip route get (or the IPv6 form) shows the route and source address that the kernel would choose for the resolver.
macOS
scutil --dns
netstat -rn
route -n get <resolver-ip>scutil --dns is especially useful because macOS can maintain scoped resolvers that are not obvious from a simple /etc/resolv.conf check.
For difficult cases, packet capture gives stronger evidence than a browser result. Traditional DNS may use UDP/TCP port 53; DoT commonly uses TCP port 853, while DoH uses HTTPS. Capture only traffic you are authorized to inspect.
20 / Interpretation
Does encrypted DNS or a kill switch prevent DNS leaks?
Does HTTPS prevent DNS leaks?
No. HTTPS protects the web session, not ordinary DNS resolution, which may occur before the TLS connection to the website is established. DoH is different because DNS itself is carried inside HTTPS, but DoH still does not decide whether that HTTPS connection uses the VPN. Routing does.
Does encrypted DNS prevent DNS leaks?
Encrypted DNS protects the DNS transport from certain forms of observation and tampering. It does not define the VPN route.
- Encrypted but outside VPN — DoH/DoT → physical interface → resolver
- Encrypted and inside VPN — DoH/DoT → VPN interface → resolver
- Traditional DNS inside VPN — UDP/TCP DNS → VPN interface → resolver
All three are different combinations of transport security and routing policy. Do not treat them as the same control.
Does a VPN kill switch prevent DNS leaks?
It can prevent one major type of leak: DNS falling back to the normal interface when the tunnel fails. It does not prove that DNS is configured correctly while the tunnel is healthy; test both the steady-state and failure-state behavior.
21 / Checklist
DNS leak testing checklist
Baseline and setup
- Baseline public IPv4 and, where available, IPv6 connectivity/address recorded before VPN use
- Baseline resolver / network recorded
- Expected VPN DNS policy understood
- Browser Secure DNS / DoH setting checked
- VPN connected to the intended server and mode
Comparison and verification
- DNS test repeated and compared with the baseline
- Resolver identity separated from the client-to-resolver route
- IPv4 and IPv6 checked separately where available
- Reconnect, sleep/wake, and network-transition behavior tested when failure-state behavior matters
- Ambiguous results verified at host-routing level rather than inferred from resolver branding
22 / FAQ
Frequently asked questions about DNS leaks
What is a DNS leak in simple terms?
A DNS leak happens when name-resolution traffic that should follow a protected VPN or DNS policy takes an unintended path. The classic example is web traffic using the VPN while DNS still leaves through the normal ISP interface.
How do I know if my VPN has a DNS leak?
First, run a DNS test without using the VPN. Then connect to the VPN, run the DNS test again, and compare how the resolver behaves. If the baseline ISP-side path is still active even though the VPN is supposed to handle DNS, look into the routing.
Is seeing my ISP DNS server proof of a leak?
In a full-tunnel setup this is strong evidence, particularly when it agrees with your baseline, but resolver branding alone is not conclusive proof. Verify the intended VPN policy and, if necessary, the route to the resolver.
Is Cloudflare DNS a VPN leak?
Not automatically. Cloudflare can be the selected resolver while the DoH or DNS connection itself still travels through the VPN. Resolver identity alone does not prove a tunnel bypass.
Is Google Public DNS a VPN leak?
Not on its own. It tells you which resolver was used to handle the query, but it does not prove which interface carried the connection.
Can DNS over HTTPS leak outside a VPN?
Yes. DoH uses an HTTPS connection; if the routing process selects the physical interface, the DNS transport can bypass the VPN even though it is encrypted.
Is split DNS a leak?
Not when it is intentional. Split DNS deliberately maps different namespaces to different resolvers. It becomes a leak when actual behavior violates the intended namespace policy.
Can a DNS leak reveal my real IP address?
The recursive resolver you contact can see the source address of that DNS transport. If the query bypasses the VPN, that may be an ISP-side address or NAT/CGNAT egress. A browser DNS leak test’s authoritative server usually sees the recursive resolver, not your workstation directly.
Why does a DNS leak test show several servers?
Resolver redundancy, multiple recursive egress nodes, browser DoH alongside system DNS, multiple interfaces, forwarding, VPN DNS pools, and anycast can all produce multiple results. Multiple resolver addresses alone do not prove a leak.
Why is my DNS server shown in another country?
Anycast, distributed resolver infrastructure, forwarding, registration data, and old geolocation databases can all cause a location mismatch. A city or country label alone does not let you diagnose a route leak.
Can DNS leaks happen only during VPN reconnects?
Yes. DNS can be correct in steady state and briefly fail open during startup, reconnection, sleep/wake, server handover, or a change to a network interface.
Does disabling IPv6 fix DNS leaks?
Not generally. If IPv6 is the path responsible for the bypass, investigate IPv6 routing and the VPN’s IPv6 design. Disabling IPv6 blindly can hide the underlying problem.
Is a DNS leak test enough to prove my whole VPN is secure?
No. DNS is one layer. IPv4, IPv6, WebRTC, application routing, split-tunnel policy, and disconnect behavior should be evaluated separately.
23 / Summary
The bottom line
A DNS leak is not simply “my VPN does not own the DNS server shown by the test.” That definition is too crude for a modern network.
Resolver selection, DNS transport, and route selection are three different parts of the problem. A third-party DoH resolver can be reached through a VPN. A familiar resolver can be reached through the wrong interface. A corporate VPN can intentionally use split DNS. And a VPN that behaves correctly while stable can still fail open during reconnect.
Start with the expected policy. Record a baseline. Connect the VPN. Compare what changed. If the result still looks wrong, do not stop at the resolver name — follow the path. That is usually where the real answer is.
To check your own connection, run a DNS leak test while disconnected, record the baseline, reconnect the VPN, and compare the results before concluding. For the wider picture, the VPN leak guide covers IPv4, IPv6, WebRTC and fail-open behavior alongside DNS.
24 / References
Technical references
- RFC 9499
- DNS Terminology
- RFC 8484
- DNS Queries over HTTPS (DoH)
- Microsoft Learn
- VPN name resolution
- Microsoft Learn
- Get-DnsClientNrptPolicy
- Microsoft Learn
- Find-NetRoute