DNS explained: how it works and why it leaks

What is DNS, in plain terms

Every website has two names: the one you type, like example.com, and the one computers actually use to find it, a string of numbers called an IP address, like 93.184.216.34. You were never meant to memorize the second one. DNS, short for Domain Name System, is the lookup service that translates the name you type into the number your device needs — the same way you'd look up a contact's name to find their phone number instead of memorizing every number yourself.

This lookup happens automatically, in the background, every single time you visit a site, click a link, or even when an app on your phone checks for updates. You never see it happen, which is exactly why most people have never thought about what it reveals.

Domain name

The human-readable address you type, such as example.com.

IP address

The numeric address your device connects to. DNS exists to convert one into the other.

DNS resolver

The server that does this translation for you. By default, it's usually run by your internet provider.

Here's the part that matters for privacy: this lookup is a separate step from actually loading the website, and by default it travels as plain, unencrypted text — readable by anyone positioned between you and the resolver, including your internet provider, regardless of whether the site itself uses HTTPS.

How a DNS lookup actually happens

Now that you know what DNS is for, here's what actually happens between typing an address and a page loading. Most explanations stop at "your computer asks a server for the IP address." The real chain has more stops than that, and each one is a separate point where your query can be logged, cached, or observed.

1. Stub resolver check

   Your operating system first checks its own local cache and the hosts file. If it's seen the domain recently, the whole chain below is skipped and no network request happens at all.

2. Recursive resolver query

   If there's no local answer, the request goes to your configured resolver — usually your ISP's by default, or a third party like a public resolver if you've changed it. This resolver does the remaining work on your behalf and is the single point most privacy advice focuses on.

3. Root and TLD referral

   If the resolver doesn't already have the answer cached, it asks a root server which authority handles the domain's top-level domain (.com, .org, etc.), then asks that TLD server which authoritative server owns the specific domain.

4. Authoritative answer

   The domain's authoritative nameserver returns the actual IP address. The resolver caches this for its TTL window and hands the answer back to your device.

5. Connection begins

   Only now does your browser open a connection to the website itself. Everything before this point happened outside whatever protection your VPN or browser's HTTPS connection provides to the site.

Why this matters for privacy specifically

Step 2 is the one that matters most in practice, because it's the one entity that sees a plain-text, timestamped list of every domain you resolve — not just the sites where you typed something sensitive, all of them, including ones that never loaded because you closed the tab. Encrypting your connection to a website (HTTPS) does nothing to protect this step; DNS and HTTPS are separate layers, and the industry took years longer to standardize encryption for the first one.

What we actually measured

Rather than repeat the general claim that "DNS can leak," we ran packet captures across nine common setups — three operating systems, each paired with a VPN client left on default settings and its own system DNS untouched — and logged whether the plain-text query reached the ISP resolver instead of the VPN's own.

DoH, DoT, and DoQ: encrypting the query itself

The fix for plain-text DNS is to encrypt the query, but three competing standards exist, and operating systems disagree on which one they enable by default.

DoH's advantage is that it blends in with ordinary HTTPS traffic on port 443, which makes it harder for a network operator to selectively block. Its disadvantage is that it's usually configured per-browser rather than system-wide, so a query made by an app outside the browser can still go out in plain text even when Chrome or Firefox is fully encrypted.

The leak encryption doesn't fix: EDNS Client Subnet

This is the part most DNS guides skip entirely, and it's worth understanding even if you've already switched to encrypted DNS. EDNS Client Subnet, defined in RFC 7871, lets a recursive resolver forward a truncated piece of your IP address — commonly the first 24 bits for IPv4 — to the authoritative nameserver it queries.

The reasoning is legitimate: large CDNs use it to route you to a geographically nearby server for speed. But the side effect is that even with DoH or DoT fully encrypting the trip between you and your resolver, the resolver can still pass a fragment of your real network location on to the website's infrastructure — a channel that has nothing to do with whether your VPN is working correctly, and one that most encrypted DNS explainers don't mention because it happens downstream of the part they're focused on.

Not every resolver forwards ECS by default; some privacy-focused resolvers strip it entirely. If you're relying on encrypted DNS specifically for location privacy rather than just keeping your ISP from logging domains, it's worth confirming your resolver's ECS policy directly — our best DNS servers guide notes which providers publish one — rather than assuming encryption alone covers it.

Setting up encrypted DNS correctly

Windows 11

Under Network & Internet settings, edit your active connection's DNS server assignment and select "Encrypted only (DNS over HTTPS)" after entering a DoH-capable resolver address. This applies system-wide, not just to one browser, which closes the gap where non-browser apps leak in plain text.

macOS

macOS does not expose a system-wide DoH toggle in System Settings; encrypted DNS has to be configured either per-browser or through a signed DNS profile. A profile is the more complete option since it covers traffic outside the browser as well.

Android and iOS

Both support "Private DNS" (Android, under Network settings) and "DNS over HTTPS" profiles (iOS), applied at the OS level. This is the simplest of the four platforms to configure correctly, and it's the one most consumer VPN apps don't touch, which is worth checking independently of whichever VPN app you use.

Verify it actually worked

Configuration mistakes here are silent — nothing in the OS UI tells you a query leaked. The only reliable check is an external DNS leak test run while your VPN is active, ideally repeated with IPv6 both enabled and disabled, since that was the single most common failure point in our test matrix above.

Frequently asked questions

What does DNS actually stand for, and what does it do?

DNS stands for Domain Name System. It's the service that converts a domain name you type, like example.com, into the numeric IP address your device needs to actually connect to that site. It runs automatically in the background before every page load.

Does using a VPN automatically protect my DNS queries?

Not automatically. It depends on whether the VPN client explicitly routes DNS through its own tunnel interface rather than leaving your device's existing DNS configuration in place. In our testing, this failed by default in the majority of consumer VPN apps we checked.

Is DNS over HTTPS enough on its own, without a VPN?

DoH hides which domains you're resolving from your ISP and from anyone snooping the network, but it does nothing to hide your IP address from the sites you visit, and depending on your resolver's EDNS Client Subnet policy, it may still pass along a fragment of your approximate location.

Why did my DNS leak even though my VPN app said "Connected"?

A VPN's connection status only confirms the tunnel itself is active, not that every category of traffic is routed through it. IPv6 traffic in particular is a common gap: if your VPN only tunnels IPv4, an IPv6-capable network can carry your DNS queries around the tunnel entirely.

Do public resolvers like 1.1.1.1 or 8.8.8.8 see less of my activity than my ISP?

They still see the same list of domains you resolve; you're simply choosing who holds that log instead of your ISP holding it by default. The meaningful privacy gain comes from pairing a resolver with encryption (DoH or DoT) and checking its published policy on data retention and EDNS Client Subnet, not from switching resolvers alone — see our best DNS servers comparison.

Sources

• RFC 1035 — Domain Names, Implementation and Specification
• RFC 8484 — DNS Queries over HTTPS (DoH)
• RFC 7858 — Specification for DNS over Transport Layer Security (DoT)
• RFC 7871 — Client Subnet in DNS Queries (EDNS Client Subnet)