DNS leak, in plain terms

A DNS leak is when your device sends DNS requests (queries to turn a domain name into an IP address) through a network path you did not intend. In practice, that can mean DNS queries reach a resolver outside the protection you expected, which may expose information about the domains you are trying to reach.

It’s helpful to distinguish “DNS leak” from “DNS over HTTPS/TLS” outcomes. A leak is about where queries are sent and resolved, not simply about whether browsing traffic is encrypted. If DNS queries go to an unintended resolver, they can be observed even when other traffic is protected.

How DNS resolution works (and where it can go wrong)

When you visit a website, your device usually performs steps like:

  • It requests a domain name resolution (for example, example.com → an IP address).
  • The DNS query is sent to a configured resolver (either directly or via a local network component).
  • The resolver returns the IP address.
  • Then your connection to the resolved IP proceeds.

A DNS leak typically arises because the resolver used for DNS queries is not the one you expected to be used. This can happen when DNS configuration and network routing are not aligned—so DNS traffic follows a different path than the rest of your connections.

Common ways this shows up:

  • Your browser uses one resolver path, while DNS requests are actually sent elsewhere.
  • Your system’s DNS settings point to a default resolver provided by your network.
  • DNS is resolved through a local component that doesn’t inherit the same protection.

Differences and limitations: what a “leak check” can and can’t prove

DNS leak checks often rely on indirect signals, so results can be ambiguous.

Key limits to keep in mind:

  • You may confirm that DNS queries appear to reach an unexpected resolver, but that doesn’t automatically reveal what any party can see.
  • Some checks show resolver identity (or inferred behavior) rather than full query visibility.
  • Network conditions (Wi‑Fi vs. mobile data, captive portals, router settings, browser caching) can change behavior between tests.

Also, “no leak observed” is not the same as “perfect leak-free behavior in all circumstances.” DNS can be influenced by caching, multiple resolvers, and per-application settings, so a single test run may not capture every case.

Practical checks you can run

Here are practical, non-technical ways to look for DNS leaks or inconsistent resolver behavior:

  1. Compare resolver behavior before and after changing protection
  • Before enabling your intended protection, note which resolver your system appears to use.
  • After enabling it, check again using an online DNS/resolver test.
  • If the resolver identity doesn’t match what you expected, that’s a potential sign of leakage.
  1. Use more than one test method
  • Relying on one website or one kind of test can be misleading.
  • Combine an online “what resolver am I using” check with a separate test that reflects connection/DNS behavior.
  1. Repeat tests after clearing caches
  • Browser and OS DNS caching can cause you to “miss” behavior.
  • If the test results don’t change after a domain change, try a fresh domain (or ensure caching is not masking the behavior).
  1. Look for resolver IP changes that don’t align with your expectations
  • While exact expected values depend on your setup, consistency is the point.
  • If DNS appears to use different resolvers across domains or sessions, investigate DNS settings and local network DNS configuration.
  • DNS privacy vs. DNS routing: You can have encrypted traffic while DNS still goes to a resolver outside your expected path.
  • Split routing: Different traffic classes follow different routes, which can include DNS differently than web traffic.
  • Browser vs. system DNS: Some configurations can cause the browser (or extensions) to behave differently from the operating system.
  • DNS caching: Cached results can delay or hide changes, making tests inconsistent unless you account for cache.

If you are diagnosing a suspected DNS leak, focus on whether DNS resolution is handled by the expected resolver path consistently for new domains under the same network conditions.