A DNS leak is when DNS queries bypass the intended secure path, such as a VPN or encrypted resolver, and go to an unintended DNS server. That exposes the domains a device is looking up, which can reveal browsing activity and network location even when other traffic is tunnelled.
How DNS Leaks Happen
A DNS leak occurs when name-resolution traffic escapes the intended secure route, usually because the device, VPN client, or resolver policy does not fully capture every DNS request. The result is that lookups are answered by an unintended server, even if the rest of the traffic remains tunnelled.
This matters because DNS is often more revealing than people assume. The queried domains can expose the sites, services, and applications a device is trying to reach, which can disclose browsing patterns, internal application names, and the network environment a user is on.
Why DNS Leaks Undermine Privacy and Segmentation
DNS leaks weaken the privacy boundary that a VPN, secure tunnel, or encrypted resolver is meant to create. If name resolution follows a different path from application traffic, an observer at the access network, upstream resolver, or local environment may still learn which destinations are being requested.
That can defeat a common security assumption, namely that “the tunnel hides my activity.” In practice, the tunnel only protects traffic that actually enters it. Any out-of-band resolver path reintroduces metadata exposure and can create a false sense of anonymity or separation.
For configurations that rely on full-tunnel behaviour, the issue is especially important. NHIMG’s VPN split tunnelling guide covers the routing and leak conditions that commonly create this failure mode.
Where DNS Leaks Come From
Common causes include split tunnelling rules that leave DNS outside the secure path, operating system resolver settings that override the VPN client, browser or application-level DNS features, and misconfigured network adapters or firewall rules. Some environments also leak when the VPN protects IP traffic but does not force DNS through the same interface.
In secure remote-access deployments, the problem is often not a single defect but a mismatch between routing, DNS policy, and endpoint behaviour. That is why leak prevention has to be treated as an end-to-end configuration problem, not just a VPN product setting.
NHIMG’s WireGuard Security Guide is useful here because it discusses leak prevention, full-tunnel behaviour, and peer configuration at a practical level.
Detection and Verification
The most reliable way to check for a DNS leak is to test the endpoint while the secure tunnel is active and confirm where DNS queries are actually going. Organisations should validate both the tunnel client and the underlying host, because leak behaviour can vary by platform, application, and network state.
It is also worth comparing vendor guidance with the observed traffic path. If the configuration claims to enforce protected DNS but packet captures, resolver logs, or external leak tests show otherwise, the endpoint is not behaving as intended.
For authoritative internet coordination and registry context around DNS infrastructure, IANA remains the canonical reference for protocol and naming registries, though it does not replace local validation of resolver behaviour.
Risk and Threat Considerations
DNS leaks create a metadata exposure problem even when content traffic is encrypted. That can reveal browsing habits, internal service names, or the presence of security tooling, and it can also help an adversary infer where a device is connecting from or which services are likely in use.
Failure mechanism: DNS resolution is sent outside the intended secure channel, often because routing, resolver selection, or endpoint policy does not fully bind name lookup to the tunnel or encrypted resolver.
Impact: An observer may learn the domains being requested, correlate activity with a user or device, and weaken the privacy, segmentation, or operational confidentiality that the secure path was supposed to provide.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | DNS leak prevention depends on controlling which network paths resolve names. |
| SC-7(7) — Split Tunneling | DNS leaks commonly arise when split tunnels allow resolver traffic to bypass the protected channel. | |
| CM-6 — Configuration Settings | Resolver and VPN settings must be configured consistently to prevent bypass paths. | |
| Recommendation — Apply boundary protections to force DNS traffic through the intended secure path. Restrict split tunneling so DNS resolution stays inside the protected tunnel. Harden endpoint configuration so DNS settings cannot silently bypass the secure route. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest Protection | DNS metadata exposure is a confidentiality issue tied to how traffic is protected in transit and at rest. |
| Recommendation — Protect sensitive network metadata by ensuring DNS traffic follows the intended security controls. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | DNS leak prevention is a network-path management problem requiring controlled egress and resolver routing. |
| Recommendation — Manage network infrastructure so resolver traffic cannot bypass the approved path. | ||
Practitioner Guidance
What to watch for: Treat DNS as part of the security boundary, not a separate convenience service. If a VPN, zero-trust client, or hardened endpoint is deployed, verify that DNS, not just application traffic, is forced through the intended trust path.
Governance implication: Ownership should sit with whoever controls endpoint policy and network egress together, because leak prevention usually fails at the boundary between those teams. Use vendor documentation, resolver logs, and live testing to confirm the design matches the observed behaviour.
Practitioner takeaway: A secure tunnel that does not capture DNS is only a partial control, and partial controls often fail in exactly the places users assume are covered.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org