Direct answer

A DNS leak happens when DNS queries intended to be handled through your VPN are resolved outside the VPN tunnel (for example by your local router, ISP DNS, or the device’s default resolver). Use the checklist below to (1) define what “leak-free” means for your setup, (2) diagnose common reasons DNS may not go through the VPN, and (3) verify with multiple independent checks.

Important limitation: a VPN cannot guarantee anonymity, safety, or uninterrupted access in every circumstance, and test outcomes can vary by device, network, location, provider, and time.

How it works

When you request a website (e.g., via a browser), your device must first convert the domain name into an IP address. That name resolution typically uses a DNS resolver. In a VPN setup, you generally want DNS queries to be sent through the encrypted tunnel so that the resolver your device uses is reachable (and intended) within that VPN path.

Leaks or “misroutes” can occur when DNS resolution is still performed by a non-VPN component, such as:

  • The device’s configured DNS server remaining active after connecting.
  • “Split tunneling” routing traffic so only some traffic traverses the VPN while other traffic (potentially including DNS) does not.
  • Network features like ad-blocking, security suites, or custom DNS-over-HTTPS/DNS-over-TLS settings changing how DNS queries are handled.
  • IPv6 behavior differing from IPv4 (some tests may show issues only for one IP family).

Practical context: checklist for problems and verification

Use this checklist in order. Stop when you have a clear explanation for what you are seeing.

1) Preconditions: confirm what should happen

  • Ensure you are actually connected to the VPN before running any verification test.
  • Decide whether you are testing IPv4 only, IPv6 only, or both; inconsistent results may reflect one stack only.
  • Note whether you use split tunneling or allow local network access. These can affect whether DNS traffic follows the same path.

2) Quick configuration sanity checks (device-side)

  • Check the device’s DNS settings while the VPN is active: if the system still shows ISP/router DNS servers, you have a strong reason to investigate.
  • If your device or browser uses a custom DNS service (including DNS-over-HTTPS/TLS), confirm whether that feature is enabled and whether it can bypass the VPN tunnel.
  • If you run multiple VPN-related apps or security tools, ensure there is no competing DNS feature that overrides the VPN’s DNS handling.

3) External verification checks (test-side)

  • Run at least one external DNS-leak verification test while connected to the VPN.
  • Record the reported resolver details (or the resolver identity indicators the test provides).
  • Repeat the test with the VPN disconnected, and compare results. If both states show the same resolver path, suspect a leak or a DNS override.

4) Controlled troubleshooting: change one variable at a time

  • Switch networks (e.g., from Wi‑Fi to mobile data) and repeat. If the behavior changes, the issue may be route-dependent.
  • Test on another device on the same network. If only one device leaks, the cause is likely device configuration.
  • Temporarily disable DNS-over-HTTPS/TLS features (if present) to see whether results stabilize. If disabling fixes it, the “leak” may be a DNS transport bypass rather than the VPN failing.

5) Look for “signal patterns” that commonly explain results

  • Same DNS resolver with VPN on and off: indicates DNS is not being redirected as expected.
  • Only IPv6 looks problematic: focus on IPv6 DNS routing and resolver configuration.
  • Results vary between tests: indicates timing, caching, DNS prefetching, or partial routing. Clear the signal by retesting after restarting the VPN connection.

Limitations you should account for

  • VPNs do not inherently guarantee anonymity or security in all scenarios; DNS handling is only one part of overall network behavior.
  • Performance and availability vary with device, network conditions, location, provider choices, and time.
  • Verification tests can be affected by caching, DNS preloading, browser settings, and how different test pages detect resolvers; therefore, “a single test” is rarely enough.
  • Some configuration choices (split tunneling, local network access, custom DNS transport like DoH/DoT) can legitimately change where DNS is resolved, so the question is whether that matches your privacy and security expectations.

When is the control checklist complete?

You can consider the verification “complete” when you can match your observations to a configuration cause with high confidence, such as:

  • Your device’s DNS settings and resolver behavior while connected clearly follow the intended VPN path.
  • Tests consistently show a different resolver path with VPN connected versus disconnected.
  • Any remaining inconsistencies have a reasonable explanation (e.g., IPv6-only behavior, caching effects, or an intentional DNS transport mode).

If you cannot reach that level of confidence, treat it as unresolved and gather more evidence (new device/network test, repeat after reconnect, document resolver indicators).

Avoidable mistakes

  • Running tests before the VPN fully establishes, then concluding prematurely.
  • Comparing results without separating IPv4 vs IPv6 behavior.
  • Trusting only one test page without repeating across connect/disconnect states.
  • Forgetting that browsers may cache or pre-resolve DNS, masking the immediate effect of changes.
  • Ignoring DNS-over-HTTPS/TLS or other DNS features that can change the path independently of the VPN.

Verification steps (a minimal, repeatable routine)

  1. Connect to the VPN and wait until the connection is established.
  2. Clear/refresh DNS-dependent state (or restart the browser) to reduce cached DNS influence.
  3. Run a DNS leak verification test and record resolver indicators.
  4. Disconnect the VPN and rerun the same test to compare.
  5. If results differ, reconnect and confirm consistency (repeat at least once). If they do not differ, inspect device DNS settings and DNS-over-HTTPS/TLS behavior.
  6. If still unclear, repeat on another network or another device to isolate whether the cause is device-specific or network-specific.

Final note on uncertainty

Because DNS behavior depends on your device, network environment, and DNS transport choices, treat verification results as evidence rather than a guarantee. When outcomes conflict, use controlled changes (one variable at a time) to narrow down where DNS queries are actually being resolved.