Kill Switches and DNS Leaks: What Actually Fails When a VPN Drops
A VPN is usually discussed as a steady state: connected, encrypted, done. The interesting moment is the one where that state ends. Tunnels drop on sleep, on network changes, when a server restarts, or when a provider pushes a configuration update. What happens in the seconds before the client notices determines whether traffic continues outside the tunnel. This guide is about that window and about the lookups that quietly bypass the tunnel even while it is up.
Table of contents
- The failure window
- What a kill switch actually does
- Why DNS leaks are a separate problem
- IPv6 and WebRTC: the paths people forget
- How to check without guessing
- Where a kill switch cannot help
- FAQ
- Bottom line
The failure window
When a tunnel drops, applications with open connections do not politely wait. They retry, and on most operating systems the retry goes out over whatever route is currently available. If the VPN client has not yet blocked that route, the request leaves through the ordinary network interface with your normal address.
This is not usually a dramatic exposure of everything you do. It is a short burst of reconnection attempts, background sync, and DNS lookups. But those are exactly the records that reveal which services you use and when, and they happen repeatedly on mobile devices that change networks many times a day.
What a kill switch actually does
A kill switch is a client-side rule that blocks outbound traffic unless the tunnel interface is active. It is not a feature of the protocol and not something the server can enforce; it lives in the application and in the firewall rules that application installs.
That distinction explains most of the variation between products. A system-level rule blocks all outbound traffic until the tunnel returns, which is protective but can leave you without connectivity if the client crashes. An application-level rule closes or pauses selected applications, which is gentler but only as good as the application list. Some clients offer both, and some use the phrase for a setting that merely reconnects faster.
- Check whether the switch is on by default and whether it survives a reboot.
- Check what happens at login, before the VPN client has started; that is a common gap.
- Check whether it covers IPv6, not just IPv4.
- Check the documented behaviour when the client itself is terminated rather than the tunnel.
Why DNS leaks are a separate problem
A tunnel can be up and still not carry your DNS lookups. Domain resolution is handled by the operating system's resolver, and that resolver may continue to use the DNS servers handed out by your local network or by your ISP, particularly when the VPN client only changes the default route without updating resolver configuration.
The result is specific and easy to misread: your web traffic is inside the tunnel, but the local network or ISP can still see the list of domains you looked up. Encrypted DNS does not automatically fix this, because the question is which resolver receives the query, not whether the query is encrypted on the way.
Modern clients normally push their own resolver addresses as part of the configuration. Problems arise with split tunnelling, with manually configured DNS, with browsers that enable their own encrypted DNS resolver, and after a network change where the operating system restores the local resolver. Each of these is a configuration race rather than a protocol defect.
IPv6 and WebRTC: the paths people forget
Many tunnel configurations were designed around IPv4. If a client routes only IPv4 into the tunnel but the device also has a working IPv6 connection, traffic to dual-stack destinations may prefer IPv6 and go outside. Providers handle this either by carrying IPv6 properly or by disabling it while the tunnel is active; a client that does neither leaves a gap.
WebRTC is a different case. Browser-based real-time features can enumerate local network addresses to establish a peer connection, and in some configurations those addresses appear to a page even while a VPN is active. This is a browser behaviour, not a tunnel failure, and it is addressed with browser settings or an extension rather than with a VPN toggle.
How to check without guessing
The only trustworthy check is to observe what your own device sends. Public test pages show you the address and the resolver that a request arrived from; a leak is visible as your ISP-assigned address, your ISP's resolver, or a local-network address appearing where you expected the tunnel's.
- Compare the address and resolver shown with the tunnel on and off; they should differ.
- Repeat after a network switch (Wi-Fi to mobile data) and after the device wakes from sleep, since that is where the failure window appears.
- Repeat with the kill switch deliberately triggered by disconnecting the server from within the client, if the client offers that option.
- If your browser has an encrypted-DNS setting, note whether it bypasses the resolver the VPN configured, and decide deliberately which one you want.
We are describing what these checks reveal, not reporting results from a test run. The outcome depends on your client, operating system, and network, which is why the check is worth doing on the device you actually use.
Where a kill switch cannot help
A kill switch manages network routes. It does nothing about a compromised device, a phishing page where you type credentials, an account you are logged into, or a browser that identifies you through cookies. It also does not make a provider's logging policy irrelevant: the tunnel operator still sits at the other end.
There is also a usability trade-off worth naming. A strict always-on rule can leave a machine with no connectivity until the client is restarted, and users who hit that repeatedly tend to switch the feature off. A rule you leave enabled is worth more than a stricter one you disable after the first inconvenience. Choose the strictest setting you will actually keep on.
FAQ
Does a kill switch protect me if the VPN app crashes?
It depends on how the rule was installed. A firewall rule that persists independently of the app will keep blocking; a rule managed only by the app's process may disappear with it. This is one of the few concrete differences between clients, and it is worth looking for in the provider's documentation.
Is a DNS leak still a problem if I use encrypted DNS?
Potentially yes. Encrypting the query hides it from the local network, but if the query goes to your ISP's resolver, that resolver still sees the domains. What matters is which resolver receives it, and whether that resolver is reached through the tunnel.
Should I just disable IPv6?
Carrying IPv6 through the tunnel is the better outcome where the provider supports it. Disabling it is a legitimate and simple fallback where it is not supported. Leaving it enabled with no tunnel route is the configuration to avoid.
How often do I need to recheck this?
After a client update, an operating system upgrade, or a change to split-tunnelling or browser DNS settings. Those are the events that commonly reset resolver and route configuration.
Bottom line
The steady state is the easy part. What separates a well-built client from a merely functional one is behaviour at the edges: when the tunnel drops, when the device wakes, when the network changes, and when a browser insists on its own resolver. A kill switch addresses the first of those, and only as well as the firewall rule behind it. DNS, IPv6, and WebRTC are separate paths that need separate checks. If you do one thing after reading this, make it the repeat check after a network switch or a sleep cycle, on the device you actually use — that is where the difference shows up, and it is not something a provider's feature list can answer for you.
If you want to compare current plans in this category, the link below goes to our own product page.