ABOUTVPNS / FIELD NOTE 06
DNS, IPv6 and VPN Leak Claims
Understand what a leak test can show, what it cannot prove, and how to check the intended traffic path.
Start by defining the boundary
A leak means traffic takes a path that the intended VPN policy should have prevented. Without a stated policy, a test result can be misleading. A business split tunnel may intentionally send ordinary internet traffic directly while protecting internal resources. A personal full tunnel may instead be expected to cover both internet traffic and DNS. Write down which behavior you expect before judging the result.
DNS is a separate part of the story
DNS translates names into addresses. A resolver can learn the names it receives, even though that does not expose every page or action within an HTTPS session. A browser may use encrypted DNS differently from the operating system. A test page that reports a resolver identifies an observation from that test, not necessarily the path used by every application.
Check both address families
Many networks support IPv4 and IPv6 together. If a VPN routes only one family, the other can behave differently. RFC 7359 describes this class of tunnel leakage. The appropriate outcome might be carrying both families through the tunnel or deliberately blocking unsupported traffic. Do not disable IPv6 across a managed environment as a blanket fix without understanding dependencies and the approved design.
Run controlled checks, not a trust ceremony
Note the network, device, client version and tunnel settings. Compare an expected public-address result and name-resolution behavior before and after connection, then repeat after sleep or a network switch. Use only approved diagnostic tools and harmless test traffic. A third-party test website also receives your connection information. Do not upload a VPN profile or secret key to get a result.
What a clean result does not prove
A test cannot certify a provider's logging policy, the security of its servers, or how every application behaves during a failure. Browser real-time communication, background applications and configured exceptions may need separate evaluation. Treat an unexpected result as a reason to investigate the exact route and resolver, not as an automatic endorsement or accusation about a provider.
Sources and Further Reading
Sources support the technical concepts. Examples and checklists are our educational synthesis, not a provider review or a substitute for current deployment guidance.