Does encrypted DNS hide which sites I visit?

It hides the lookup, not the connection. After resolving a name your device still connects to that server's IP address, and the server name is usually visible in the TLS handshake, so a network observer can often still identify the site.

Why do different leak test pages give different answers?

Because they measure different things. Some report the resolver that reached them, some report every resolver in a rotation, and browser-level encrypted DNS can produce a different result from a command-line check on the same machine.

Is having several resolvers listed automatically a leak?

No. Multiple entries are normal on multi-homed machines. It becomes a leak when one of them belongs to a network you meant to exclude, because queries are commonly sent to whichever answers first.

DNS Leaks: What They Are and How to Check

A DNS leak occurs when your device sends domain name lookups to a resolver you did not intend to use, usually your internet provider's, revealing every site you are about to visit. Checking means confirming which resolver actually answers your queries, at the operating system, browser and network level.

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.