If any DNS leak occurs in a VPN service, it will cause the DNS queries. It could be made by the user’s browser or operating system to flow through the outside of the VPN tunnel, potentially revealing the web pages the user visited to an ISP, network admin, hotspot operator, or resolver provider.
The VPN privacy test should include the testing of DNS, IPv6, WebRTC, kill switch activation, and reconnection states.
The real proof comes from checking whether every request follows the tunnel while the VPN is active, while tools like Toggle.org can be useful for a broader comparison workflow.
This checklist and technical guide explain how to test VPN clients for hidden data leaks that may de-anonymize users even when the connection status says “protected.”
The phrase DNS leak in VPN service sounds narrow, but the issue often involves several layers: DNS routing, IPv6 handling, browser WebRTC behavior, split tunneling, and system fallback rules.
The problem of DNS leaks in a VPN service
A VPN changes the route that your internet traffic travels. Ideally, it should have a feature to control where DNS requests are sent. We call the process of converting (resolving) human-readable domain names into machine-readable IP addresses DNS.
Your device might still ask your internet service provider’s DNS resolver for domain names, making it a big privacy concern even if the VPN is encrypting the web traffic by itself.
A DNS leak in VPN service usually happens in one of four ways:
- The VPN app does not push its own DNS resolver correctly.
- The operating system keeps an old resolver from the local network.
- The browser uses a separate encrypted DNS setting.
- The tunnel drops, but DNS traffic keeps moving outside it.
DNS over HTTPS improves confidentiality by using TLS protected HTTPS for DNS queries, and the IETF has declared it to be a protocol for replacing DNS query-response pairs with HTTP exchanges over TLS. However, DoH does not necessarily mean that the traffic goes through the VPN tunnel. Changes the way the DNS query is transmitted.
Mini test: log in to another country’s VPN server, launch two DNS leak test tools, and compare the locations of the DNS resolvers. When your public IP is Germany and DNS resolvers are your home ISP in Poland, it means that the VPN tunnel is leaking DNS metadata.
IPv6 leaks: the VPN security issue many users never test
The problem of leaks occurs when the VPN manages to carry out IPv4 traffic, but not IPv6 traffic. This is an easy thing to overlook since most test pages are still geared around IPv4. A user might be alerted to the change of his IPv4 address and think that everything is OK, while his real IPv6 address is displayed.
| Leak type | What may be exposed | Common cause |
| DNS leak | Domains requested | Wrong resolver route |
| IPv6 leak | Real IPv6 address | VPN lacks IPv6 tunnel or block |
| WebRTC leak | Local or public IP data | Browser ICE candidate discovery |
In a VPN security problem, the possibility of a leak is even greater in IPv6 than in IPv4, as IPv6 addresses are more persistent and expected in some networks. If the VPN service doesn’t support IPv6, restrict use of it while connected to the VPN. If it is able to support IPv6, then it should route the IPv6 through the tunnel.
The safety test should include public IP checks and command line checks. To check for active adapters on Windows, run ipconfig /all. On Mac OS X / Linux, use ifconfig or ip addr. Next, before and after connecting to the VPN, check the dedicated IP address.
How to check your VPN service for critical security holes
Start with a clean baseline. Run the first test before turning on the VPN. Record your real public IP, IPv6 status, DNS resolver, browser, operating system, network type, and VPN protocol.
Then run this numbered test:
- Check public IP before VPN connection. Save IPv4 and IPv6 results.
- Connect to the VPN. Choose a server in a different region.
- Reload the IP test. Your visible IP should match the VPN exit location.
- Run a DNS leak test. No resolver should belong to your ISP or local network.
- Run an IPv6 test. Real IPv6 should be hidden, blocked, or replaced by VPN-routed IPv6.
- Run a VPN WebRTC DNS leak check. The browser should not expose your real public IP.
- Force a network change. Switch from Wi-Fi to mobile hotspot or briefly disable the connection.
- Check kill-switch behavior. Traffic should stop, not fall back to the normal route.
- Repeat in another browser. Chrome, Firefox, Edge, and Safari can behave differently.
- Document the result. Save screenshots, timestamps, VPN server, protocol, and device state.
The problem for WebRTC is that browsers collect network candidates to use in peer-to-peer connections. For instance, BrowserLeaks can test STUN/TURN servers, ICE candidates, and whether there is exposure of local or public IP.
What this means is that WebRTC allows the exposure of local IP addresses to certain origins, and this is a policy to be enforced in the browser, so it’s not a theoretical concern but an actual policy in the browser level.
Vulnerability research checklist for DNS, IPv6, and WebRTC leak testing
A strong VPN privacy leak audit should test normal use and failure states. Many weak clients pass a basic IP test but fail during reconnects, sleep mode, browser changes, or split tunneling.
Use this checklist:
- Test on at least two networks: home Wi-Fi and public or mobile hotspot.
- Test after sleep/wake on laptop.
- Test after switching VPN servers.
- Test with split tunneling off, then on.
- Test with browser DoH enabled and disabled.
- Test with IPv6 enabled at the system level.
- Test with the kill switch on and off.
- Test during brief VPN disconnect.
- Test on at least two browsers.
- Save evidence for every pass and fail state.
A DNS leak in VPN service may appear only during one condition. For example, the VPN may use safe DNS when first connected, then fall back to the router’s resolver after waking from sleep. That is why a single test page is not enough.
DNS and IPv6 leak protection: What a safe client should do
DNS and IPv6 leak protection should be visible in behavior, not just marketing copy. A VPN client should set DNS resolvers on connection, restore the previous configuration after disconnection, block unsafe fallback routes, and handle IPv6 consistently.
For WebRTC, modern browsers often use mDNS hostnames to hide local IP addresses. The relevant draft describes using dynamically generated mDNS names to conceal private IP addresses while still allowing ICE candidate discovery.
This reduces exposure, but it does not replace VPN-side testing because public IP, relay behavior, and browser settings can still vary.
A practical pass standard looks like this:
- DNS queries use VPN-controlled or privacy-safe resolvers.
- No ISP resolver appears during active VPN use.
- Real IPv6 address does not appear in test tools.
- WebRTC does not reveal the real public IP.
- Kill switch blocks traffic during tunnel failure.
- Split tunneling is documented and limited to approved apps.
This is how to detect VPN IP leaks becomes more than a browser test. A researcher should compare the route, resolver, protocol, and browser output. One green checkmark is weak evidence. Matching results across layers are stronger evidence.
What went wrong: common VPN security hole testing mistakes
Many leak tests fail because the tester checks the easiest condition and stops. A VPN can look safe during a calm desktop session and still fail on a mobile hotspot, hotel Wi-Fi, split tunneling profile, or reconnection event.
Common mistakes include:
- Testing only IPv4.
- Ignoring browser-level WebRTC output.
- Trusting the VPN app status icon.
- Forgetting browser DoH settings.
- Leaving IPv6 enabled without testing it.
- Testing one server and assuming all servers behave the same.
- Failing to test tunnel drops.
- Skipping mobile apps.
DNS leaks in VPN services are often found through repetition. A clean first result is useful, but it is not proof that the client is safe under pressure. The better method is to create small failure events and watch what escapes.
A simple lab note can look like this:
Device: Windows laptop
Network: home Wi-Fi
VPN protocol: WireGuard
Test 1: DNS clean
Test 2 after sleep/wake: ISP resolver appeared
Finding: DNS fallback after adapter reset
Risk: browsing metadata exposed during reconnect
That style of record helps developers reproduce the issue. It also helps users compare VPN clients without relying on vague claims.
Test beyond the VPN icon
A question to ask during a VPN privacy leak audit is if all sensitive requests go down the protected route whenever a VPN is activated, unstable, or reconnected. Even if the app indicates a connection status, a user could be de-anonymized if DNS, IPv6 or WebRTC data leaks.
The best practice for vulnerability research is to repeat tests. Verify DNS routing, IPv6 exposure, browser WebRTC behavior and kill-switch response. Record the setup. Retest following app updates. Compare results between networks and browsers.
