How DNS leaks expose traffic behind a VPN
A virtual private network is often described as a tunnel between your device and a remote VPN server. That description is useful, but incomplete. The tunnel usually protects the connection between your device and the VPN provider; it does not automatically control every network request made by your operating system, browser, or installed applications.
This distinction explains why your ISP can still see your traffic even with a VPN in some situations. Your provider may not be able to read the contents of encrypted web pages, yet it can still observe DNS lookups, connection attempts, timing patterns, or traffic that accidentally bypasses the tunnel. A DNS leak is one of the clearest examples of this gap between apparent privacy and actual privacy.
The issue matters because domain names can reveal a great deal. A DNS request for a medical service, political organization, news site, or private forum may expose the general subject of your activity even when the page itself uses HTTPS. Understanding where name resolution happens is therefore as important as choosing a VPN with strong encryption.
A VPN changes the route, not every request
Without a VPN, your device typically sends traffic to your router, then through your ISP, and onward to the internet. Your ISP often provides the DNS resolver as part of that service. When you type a website address, your device asks a resolver for the corresponding IP address, and the ISP may be able to record that request.
A properly configured VPN changes this arrangement. It encrypts traffic from your device to the VPN server, then sends internet requests through the VPN provider’s network. Ideally, DNS queries travel through the same encrypted tunnel and are handled by the VPN’s resolver or another resolver selected by the VPN application.
That “ideally” matters. A VPN client may protect ordinary browser traffic while leaving another connection outside the tunnel. An incorrect operating-system setting, a browser’s separate DNS feature, IPv6 behavior, or split tunneling can create a second route. The VPN icon can remain visible while some requests continue to reach the ISP directly.
This is why a VPN should be treated as a routing system rather than a universal privacy switch. Its protection depends on how the tunnel is implemented, which traffic it captures, and whether the device continues to use network services supplied by the ISP.
DNS turns names into revealing signals
DNS, or the Domain Name System, translates human-readable addresses such as example.com into numerical IP addresses. It is an essential background service, but traditional DNS is usually unencrypted. Anyone operating the network path between your device and the resolver may be able to observe the query.
A DNS leak occurs when a device connected to a VPN sends those lookups outside the VPN tunnel. The ISP may then see the requested domain names even though the subsequent web connection travels through the VPN. In some cases, the ISP sees both the DNS request and a connection to the resulting IP address. In others, it sees only the lookup while the VPN hides the rest.
HTTPS limits what can be read after a connection is established. It generally prevents the ISP from viewing page text, passwords, forms, and specific content. However, DNS can disclose the domain being requested, and other metadata can add context. Encrypted traffic still has destinations, timestamps, sizes, and frequency patterns.
Modern browsers sometimes use DNS over HTTPS or DNS over TLS. These technologies encrypt the query between the browser or device and a selected resolver. They can prevent the local ISP from reading traditional DNS traffic, but they do not solve every VPN problem. If the browser sends encrypted DNS directly to a resolver outside the VPN, the ISP may not see the domain, yet the request may still bypass the VPN’s intended privacy controls. The resolver itself can see the query, and the VPN provider may have less control over leak protection.
For readers interested in practical privacy habits beyond network configuration, this privacy checklist offers a useful reminder that digital privacy is built from several layers rather than one product.
Common paths around the tunnel
The most common leak comes from the operating system retaining the ISP’s DNS server after the VPN connects. This can happen because the VPN application fails to update the system resolver, because another network interface has priority, or because a router continues to advertise its own DNS settings. The device then sends lookups through the normal connection while other traffic uses the VPN.
IPv6 is another frequent source of confusion. A VPN may handle IPv4 correctly but fail to route IPv6 traffic through the tunnel. If the ISP supplies IPv6 connectivity, some applications can use that path directly. The result is an IP leak or DNS leak that may not appear in a basic test designed only for IPv4.
Split tunneling creates a deliberate version of the same behavior. This feature lets users send selected apps or websites outside the VPN, often to improve speed or access local services. It can be useful, but excluded applications may use the ISP’s DNS resolver and public IP address. A browser extension or a second VPN can produce similar conflicts.
Browsers also deserve separate attention. WebRTC, used for real-time audio and video, has historically exposed local or public network information in certain configurations. Browser-based DNS settings can send queries along a separate encrypted path. Mobile applications may use their own networking libraries, ignore system proxy settings, or switch between Wi-Fi and cellular networks while the VPN reconnects.
A temporary interruption can matter too. If the VPN disconnects for a moment and has no kill switch, applications may continue communicating through the ISP. A leak is not always a permanent configuration error; it can be a brief failure during startup, reconnection, or network changes.
What different setups reveal
The table below separates the parties involved and the information they may receive. Actual visibility depends on encryption, software settings, legal requirements, logging policies, and whether a request bypasses the VPN.
| Connection setup | What the ISP may see | What the VPN provider may see | Main privacy concern |
|---|---|---|---|
| No VPN, traditional DNS | DNS queries, destination IPs, timing, volume, and encrypted traffic metadata | Nothing beyond normal internet intermediaries | The ISP can associate browsing activity with the subscriber |
| VPN with protected DNS | VPN server connection, timing, volume, and possibly packet patterns | Destination connections and DNS queries, depending on its resolver | Trust moves from the ISP to the VPN provider |
| VPN with a DNS leak | DNS domains, VPN connection, timing, and volume | Some traffic destinations, but possibly not leaked queries | The ISP can infer visited services from domain lookups |
| VPN with split tunneling | Traffic and DNS for excluded apps or routes, plus VPN metadata | Traffic sent through the tunnel | Selected activity remains exposed to the ISP |
| Browser DNS outside the VPN | Usually encrypted DNS connection metadata, not necessarily domain names | VPN-routed traffic, but not necessarily browser DNS | The external resolver receives queries outside the VPN policy |
| VPN with IPv6 leakage | IPv6 destinations and possibly related DNS activity | IPv4 traffic or only the portion captured by the tunnel | The ISP can identify traffic that escaped over IPv6 |
The table also shows why “the ISP cannot see my traffic” is too broad a claim. In the best case, the ISP sees that a VPN server is being used and can measure when and how much data crosses the connection. It may not know which websites were visited. In a weaker configuration, DNS requests and uncaptured connections provide a readable outline of activity.
A VPN provider is not invisible in this model. It can often see the destinations your connection reaches, even when it promises not to retain that information. The service’s logging policy, ownership, jurisdiction, payment records, and technical design deserve the same scrutiny as its encryption claims. Privacy is a redistribution of visibility unless the entire system is designed carefully.
Test the connection without false confidence
A DNS leak test is a useful diagnostic, but it is not a complete privacy audit. Run a test once with the VPN disconnected to establish the normal result, then connect to the VPN and repeat it. The reported DNS servers should generally belong to the VPN provider or to a resolver you intentionally selected, rather than to your ISP.
Run tests from more than one network if possible. Wi-Fi at home, workplace networks, public hotspots, and mobile data can provide different IPv4, IPv6, and DNS behavior. Test after changing VPN servers, enabling split tunneling, switching protocols, and reconnecting from sleep mode. A configuration that works on one network may fail on another.
Check the public IP address as well as DNS servers. If the test shows your household or mobile IP instead of the VPN address, traffic is escaping or the service is not working as expected. Look for IPv6 results specifically, since some tests display an apparently clean IPv4 result while separately revealing an uncovered IPv6 address.
It is also worth checking the device itself. Review the VPN application’s leak protection, kill switch, DNS policy, IPv6 handling, and startup behavior. On a computer, inspect active network adapters and resolver settings. On a phone, verify that the VPN is configured as an always-on connection if that option is available. Testing one browser does not prove that every application follows the same route.
A broader review of personal safeguards can help place these technical checks in context; this privacy security review considers how everyday choices affect the strength of a privacy setup.
Practical steps for a quieter connection
Start with a reputable VPN application that explicitly documents DNS leak protection, IPv6 support, and a kill switch. A provider should explain whether its own resolvers are used, how requests are handled during reconnection, and what happens when the tunnel cannot be established. Vague promises about “military-grade encryption” say less than clear documentation about routing.
Keep the operating system, browser, and VPN client updated. Disable or configure split tunneling unless there is a specific reason to use it, and investigate browser features that select an independent DNS resolver. If you need local-network access, understand exactly which routes are being excluded rather than assuming the VPN protects everything.
Useful checks include:
- Confirm that DNS servers shown during a VPN session are not supplied by your ISP.
- Test IPv4 and IPv6 separately, including after the device wakes or changes networks.
- Enable the VPN kill switch and verify that internet access stops when the tunnel is interrupted.
- Review split-tunnel, browser DNS, WebRTC, and per-application network settings.
- Repeat leak tests after major updates, router changes, or VPN configuration changes.
No test can guarantee perfect anonymity. A resolver may use shared infrastructure that makes ownership difficult to identify, and a website can still collect browser fingerprints, account identifiers, cookies, and behavioral data. The goal is more precise: prevent routine DNS and routing leaks from handing your ISP an easy record of the services you use.
Your ISP may still know that you connect to a VPN, when the connection is active, and how much data it carries. Traffic analysis can sometimes reveal patterns even when contents and destinations are obscured. A VPN reduces exposure; it does not erase the metadata inherent in communicating across a network.
Review your own setup now rather than waiting for a sensitive search or private session to expose the weakness. Connect to the VPN, check the public IP, run DNS and IPv6 tests, interrupt the tunnel, and inspect which applications continue communicating. Those few checks turn a reassuring VPN symbol into evidence that the protection is actually working.