A DNS leak happens when your device sends domain name lookups to a resolver outside the protected path you intended, such as your ISP's resolver instead of your VPN's. The traffic itself may be encrypted, but the list of sites you visit is still visible to whoever answers those queries.
Why are DNS queries sensitive at all?
RFC 7626, the IETF's analysis of DNS privacy, notes that almost all DNS traffic is currently sent in clear, with only a few cases of channel encryption, for instance inside an IPsec VPN between the stub resolver and the resolver. It also points out that DNS requests can happen without any explicit action. Reading a local HTML page, even without selecting links, may trigger lookups because of prefetching and autocomplete. The same document observes that source addresses travel with queries and form metadata about the client.
So a name lookup says who you are, roughly where you are, and what you are about to connect to. Encrypting the connection afterward does not undo that.
How does a leak occur?
The common cause is a mismatch between where traffic goes and where lookups go. Some examples, described in general terms:
- The VPN client routes application traffic through the tunnel, but the operating system keeps using the DNS server handed out by the local network.
- A device has more than one network interface, and the system queries resolvers on each of them.
- A browser has its own encrypted DNS setting that points to a third party, separate from the VPN's resolver.
- IPv6 lookups or traffic bypass a tunnel that was configured only for IPv4.
None of these needs an attacker. They are configuration gaps.
Does encrypted DNS fix it?
It addresses a different half of the problem. DNS over TLS (RFC 7858) provides privacy for DNS and removes opportunities for eavesdropping and on-path tampering on the network. DNS over HTTPS (RFC 8484) maps each query and response to an HTTP exchange. Both protect the lookup on the wire. Neither tells you who the resolver is. If you encrypt lookups to a resolver you did not mean to use, you have an encrypted DNS leak, and the resolver operator still sees the queries.
A constructed example
Priya works from a hotel with a corporate VPN. She wants lookups for internal names and for the public web to go through the company resolver. She runs a lookup tool and checks which server answered: it is the hotel's gateway address, not the company's. The VPN carries her traffic, but the system DNS setting never changed. The fix has two parts: the VPN profile pushes its own DNS server and makes the system prefer it, and the firewall rule on her laptop blocks outbound port 53 and port 853 to anything except the tunnel.
How to check or apply this
- Connect the VPN, then find out which resolver your system actually uses. On most systems the network settings or the resolver configuration will show the address.
- Use a lookup test that reports which resolver answered. Run it with the VPN off and on, and compare. They should differ.
- Test again on a different network, such as a phone hotspot, because leaks often depend on what the local network hands out.
- Check IPv6. If the tunnel is IPv4 only, disable IPv6 or tunnel it too.
- Review the browser's own DNS setting and set it to follow the system or to the resolver you chose.
- Block outbound DNS to anywhere but your chosen resolvers, using the host firewall or the VPN client's kill switch if it has one.
- Decide whether you want DoT or DoH, and to which resolver, and write that down as policy.
Quick check
Is a DNS leak the same as a data breach?
No. It exposes the names you look up, and the network metadata that goes with them, not the content of your traffic.
If I use DNS over HTTPS, can I still leak?
Yes. Encryption protects the lookup in transit, but if it goes to a resolver you did not choose, that resolver sees your queries.
Sources
- RFC 7626: DNS Privacy Considerations
- RFC 7858: Specification for DNS over Transport Layer Security (TLS)
- RFC 8484: DNS Queries over HTTPS (DoH)
Last reviewed: 18 October 2026.
