Every time you open a site, your device asks a resolver to turn the domain name into an IP address. That question is a plain-text record of where you are about to go, and by default it goes to whichever resolver your network handed you — normally your internet provider's.
A DNS leak is when those queries go somewhere you did not intend. The usual case is a device configured to use a private or encrypted resolver that, for one of several structural reasons, keeps sending some or all lookups to the ISP anyway. Nothing visibly breaks, which is why leaks persist for years unnoticed.
What does DNS actually expose?
The domain, the timestamp, and the source — which is enough to reconstruct a browsing session.
Classic DNS runs unencrypted over port 53. Anyone positioned between you and the resolver can read the query, and the resolver itself sees every one of them attributed to your connection. It does not see the specific page, but the domain is usually the sensitive part.
Encryption changes who holds this record, not whether it exists:
| Transport | Encrypted? | Who sees the query |
|---|---|---|
| Plain DNS (port 53) | No | Your network, your ISP, the resolver |
| DNS over TLS (DoT, port 853) | Yes | The resolver you chose |
| DNS over HTTPS (DoH, port 443) | Yes | The resolver you chose; harder for the network to distinguish from web traffic |
| DNSSEC | No — it authenticates | Same as plain DNS; it proves answers are genuine, it does not hide them |
DNSSEC is the most commonly misunderstood entry. It signs responses so they cannot be forged. It provides no confidentiality whatsoever.
How do leaks actually happen?
Six structural causes cover nearly all of them.
| Cause | Mechanism |
|---|---|
| Split routing | Some traffic uses a tunnel, DNS goes over the default interface |
| IPv6 not carried | The tunnel handles IPv4 only, so IPv6 lookups take the ISP path |
| OS parallel resolution | Windows can query all interfaces at once and take the first answer |
| Browser-level DoH | The browser resolves independently of the system setting, in either direction |
| Router override | The router forces its own resolver via DHCP or intercepts port 53 |
| Captive portal | Hotel or airport networks hijack DNS to force their login page |
The browser case is worth spelling out, because it cuts both ways. A browser with its own DoH setting may bypass a carefully configured system resolver, and equally a correctly configured browser may hide the fact that everything outside that browser is still leaking. Checking one and assuming the other is the most common testing error.
How do you check?
Test at each layer separately, because they can disagree.
Operating system — which resolvers are configured:
| System | Command |
|---|---|
| macOS | scutil --dns | grep nameserver |
| Windows | Get-DnsClientServerAddress |
| Linux (systemd-resolved) | resolvectl status |
| Linux (generic) | cat /etc/resolv.conf |
Which resolver actually answered — configuration and behaviour differ:
dig +short whoami.akamai.net returns the IP address of the resolver that
performed the lookup on your behalf. Compare that against the resolver you
expected.
Browser level: open the browser's secure-DNS setting and note whether it is enabled and which provider is selected. Then load a DNS leak test page in that browser. If the page reports a different resolver than your command-line test, the browser is resolving independently.
IPv6: repeat the check with an IPv6-only query. A tunnel carrying IPv4 only is the single most common cause of a partial leak.
How do you read the result?
Compare the resolver's owner against your expectation, not against a list of "good" addresses.
| Observation | Interpretation |
|---|---|
| Resolver belongs to your ISP, and you configured another | Leak |
| Several resolvers, one of them your ISP | Partial leak — queries are split |
| IPv4 shows the expected resolver, IPv6 shows the ISP | IPv6 leak |
| Browser and system report different resolvers | Not necessarily a leak, but two independent paths to verify |
| Resolver is in an unexpected country | Often normal — anycast resolvers answer from the nearest site |
| Resolver is the router's private address | Inconclusive; the router forwards upstream, so check the router's own setting |
That last row traps people on home networks. A result of 192.168.1.1 tells you
only that your router answered. Where the router forwards to is a separate
question, answered in the router's WAN or DNS settings.
What are the limits of fixing this?
Fixing a DNS leak changes who learns which domains you looked up. It does not make the visit private, and overstating this is the main way the topic is misrepresented.
After the name resolves, your device opens a connection to that IP address. Any observer on the path sees the destination address, and in most TLS connections the server name is transmitted unencrypted in the handshake unless Encrypted Client Hello is in use at both ends. Both signals identify the site independently of DNS.
So the honest summary is narrow but real: encrypted DNS to a resolver of your choosing removes the plain-text list of every domain you visit from your local network and your ISP's logs, and transfers that list to the resolver operator instead. It moves trust rather than eliminating it — which makes who runs the resolver, and what they log, the question that actually matters.