A DNS leak occurs when name lookups use a resolver outside the privacy route you expected, often while a VPN is connected. The term is sometimes used too broadly, so a useful test begins with a clear expectation about which resolver should receive requests.
The expected path
A full-tunnel VPN typically sends web traffic and DNS through the encrypted tunnel. The VPN may provide its own resolver or route queries to a protected third party. If the operating system continues using the local router or internet provider, observers there may see requested domain names.
Why leaks happen
Multiple network adapters, browser secure-DNS settings, split tunneling and stale resolver configuration can create different paths. IPv6 traffic may bypass a VPN that protects only IPv4. Corporate setups may intentionally send selected internal names to a company resolver.
Reading a leak test
Run the test before and after connecting, then compare resolver organizations and countries. Seeing more than one resolver is not automatically a leak; large providers use distributed infrastructure. The key question is whether an unexpected party receives queries that your setup promised to protect.
Fixing the cause
Update the VPN client, enable its DNS protection and confirm IPv6 support. Restart the connection to clear stale settings. Review browser secure-DNS choices and split-tunnel rules. If behavior remains inconsistent, collect results and ask the provider to explain the intended resolver path.
Practical checklist
- Record the baseline resolver before connecting.
- Test both IPv4 and IPv6 connectivity.
- Compare browser and operating-system DNS settings.
- Retest after reconnecting and after a device restart.
Keep the result in context
Network tools provide useful evidence, not a complete identity or security verdict. Record what you tested, compare results before and after a change, and use several independent signals when a decision matters.
Browse all 25 KiwiVPN guides or return to the public IP checker.