Every time you type a web address, something has to turn that human-readable name into a number
a computer can actually route traffic to. That something is DNS, and it runs quietly in the
background of basically everything you do online. Most people never think about it. That's part
of the problem: DNS was designed in the 1980s, before privacy was a design consideration for
internet protocols, and a lot of it still runs exactly the way it did back then.
This covers how DNS actually works, where it leaks information most people don't expect, and
what the current fixes do and don't solve, including one gap that's still open even after you've
done everything "right."
What is DNS?
DNS, the Domain Name System, translates domain names like example.com into IP addresses like 93.184.216.34, the actual numeric addresses computers use to route traffic across the internet. Domain names exist purely for humans. Nothing about the underlying network needs them; they're a memorable label sitting on top of a number.
It's a genuinely old system, dating back to 1983, replacing an earlier setup where every computer on the early internet kept a single shared text file (literally called HOSTS.TXT) that mapped names to addresses, manually updated and distributed. DNS made that decentralized and scalable. It also, as a side effect of decisions made decades before anyone worried about network surveillance, made every lookup broadcast in plain text by default, which is the thread running through most of the rest of this article.
How a DNS lookup actually happens
Typing a URL triggers a short chain of requests, most of which resolve from cache and never actually leave your device. Here's the full path when nothing is cached yet.
In practice this entire chain usually completes in well under 100 milliseconds, and caching at every layer means most day-to-day browsing barely touches steps 3 through 5 at all.
Common DNS record types
A domain's DNS records aren't just one address. They're a small set of different record types, each answering a different question.
| Record | What it does |
|---|---|
| A | Maps a domain to an IPv4 address |
| AAAA | Maps a domain to an IPv6 address |
| CNAME | Points one domain to another domain name, rather than an IP directly |
| MX | Specifies which mail servers handle email for the domain |
| TXT | Holds arbitrary text, commonly used for domain verification and email anti-spoofing (SPF, DKIM, DMARC) |
| NS | Declares which nameservers are authoritative for the domain |
| SOA | Holds administrative details: primary nameserver, refresh timing, contact info |
| CAA | Restricts which certificate authorities are allowed to issue TLS certificates for the domain |
The privacy problem: DNS is usually plaintext
Standard DNS runs over UDP on port 53, and by default, none of it is encrypted. Every query and response travels as plain, readable text across whatever network it crosses. This means anyone positioned on that path, most commonly your ISP, can see the exact domain of every site you look up, timestamped, even if the site itself is fully HTTPS-encrypted. HTTPS protects what you do on a page. Standard DNS never protected the fact that you visited it in the first place.
This is a bigger deal than it sounds. A list of every domain someone has queried over a few months, with timestamps, is a detailed behavioral profile: what they read, what they shop for, what health conditions they might be researching, which political or religious sites they visit. None of that requires seeing a single page's content. The domain alone is often enough.
DNS leaks and what they mean for VPN users
A VPN is supposed to route all of this through its own tunnel, including your DNS queries, so your ISP sees encrypted traffic to a VPN server and nothing more. A DNS leak is what happens when that promise doesn't hold: your browsing traffic goes through the VPN as expected, but your DNS queries slip out through your normal network path anyway, often because an operating system setting or a poorly built VPN client didn't force DNS resolution through the tunnel.
The practical result is quietly serious. Your VPN app shows connected, your IP address looks correctly masked to any site you visit, and your ISP can still see the exact domain of everything you're browsing, because the DNS half of the picture never actually left their view. It's one of the most common gaps between what people think a VPN is doing and what it's actually doing. You can check whether it's happening on your own connection right now with our DNS leak test. If you want to know which providers actually handle this correctly, our VPN reviews note it.
DNS over HTTPS and DNS over TLS
Two standards exist specifically to close the plaintext gap, and they take different approaches to the same problem.
Wraps DNS queries in TLS encryption on a dedicated port, 853. A network can tell DoT is happening, since it's clearly labeled by the port, even though it can't read the query itself. That also makes it straightforward for a network to block outright by blocking the port.
Sends the query as ordinary-looking HTTPS traffic on port 443, the same port every secure website uses. Far harder to selectively block without breaking normal web browsing along with it, which is exactly why it became more politically contentious than DoT ever did.
That controversy isn't hypothetical. In July 2019, the UK's Internet Services Providers' Association shortlisted Mozilla for its "Internet Villain" award over Firefox's rollout of DoH, arguing it would let users bypass UK content filtering and parental controls. The backlash was immediate and loud enough that ISPA withdrew both the nomination and the entire villain category within a week. The episode is a genuinely useful illustration of what's actually at stake with encrypted DNS: it's not just a technical toggle, it shifts who gets to see (and filter, and log) what domains you visit, away from your network provider and toward whichever resolver you choose instead.
DNSSEC isn't encryption
DNSSEC gets confused with encrypted DNS constantly, and it's worth being precise about the difference. DNSSEC adds a chain of cryptographic signatures to DNS records, so a resolver can verify that a response genuinely came from the domain's authoritative nameserver and wasn't forged or tampered with along the way. That's an integrity and authenticity check, aimed squarely at stopping the kind of spoofing attack covered in the next section.
It does nothing to hide the query from anyone watching the network. A DNSSEC-validated lookup for a sensitive domain is still broadcast in plain text unless it's also running over DoH or DoT. The two mechanisms solve entirely separate problems, verifying that an answer is genuine versus keeping the question private, and a fully privacy-conscious setup wants both, not either.
The gap encrypted DNS doesn't close
Here's the part almost every "how to protect your DNS privacy" guide leaves out entirely, and it's a meaningful gap. Switching to DoH or DoT hides the DNS lookup itself. It doesn't necessarily hide which site you connect to next, because of a separate leak sitting one layer up, inside the TLS handshake.
When your browser connects to an HTTPS site, it sends an initial message called a Client Hello, which historically included a field called SNI (Server Name Indication), in plain text, before any encryption kicks in. SNI exists because a single server can host thousands of different sites behind one IP address, and the server needs to know which site's certificate to present before the encrypted part of the connection even begins. The result: a network observer who can't read your (now encrypted) DNS query can very often still read the SNI field and learn exactly which site you just connected to, straight out of the TLS handshake itself.
The fix is a newer standard called Encrypted Client Hello (ECH), formally standardized as RFC 9849 in March 2026 after years as a draft. ECH splits the Client Hello into two layers: an outer message containing a generic, shared cover name (visible to the network), and an inner message containing the real SNI, encrypted so only the destination server can read it. The encryption key for this comes from a DNS record, which is why ECH only works properly if you're also using DoH or DoT, tying the two protections together by design.
Support is real but still uneven. Chrome, Firefox, and Safari all ship ECH support by default as of 2026, on the client side. Server-side is a different story: Cloudflare has supported it since 2023, and Fastly and Akamai followed, but broader adoption has been slow, with independent measurements putting ECH deployment at somewhere around 9% of the top million websites. In practice, that means ECH protects you on the sites that have turned it on, and does nothing on the (currently much larger) share of the web that hasn't. It's also worth being honest about what ECH doesn't do: it doesn't stop a network from fingerprinting your traffic through packet timing, TLS fingerprinting techniques like JA4, or plain IP-based analysis, the kind of traffic fingerprinting covered in our WireGuard vs OpenVPN comparison. It closes one specific leak, a real and long-standing one, not every way traffic can be analyzed.
Real-world DNS attacks worth knowing
DNS's age and design show up in its security history too, not just its privacy gaps.
The Kaminsky bug (2008). Security researcher Dan Kaminsky discovered a fundamental flaw in how DNS resolvers verified responses: transaction IDs and source ports were predictable enough that an attacker could forge a fake DNS response and get a resolver to accept it as genuine, effectively redirecting anyone using that resolver to a malicious server, all without touching the real authoritative nameserver. The flaw was serious enough that Kaminsky coordinated a rare, simultaneous multi-vendor patch across essentially every major DNS software vendor, announced in July 2008, weeks before he publicly detailed the exact mechanism at Black Hat that August. The fix, randomizing source ports on top of the existing transaction ID, is still standard practice in every DNS resolver today.
NXDOMAIN hijacking. When a domain doesn't exist, DNS is supposed to return an NXDOMAIN ("no such domain") response, which your browser turns into a straightforward error page. Some DNS providers, including several major ISPs over the years and DNS services like the early version of OpenDNS by default, have instead intercepted that response and silently redirected it to their own search page full of ads, monetizing typos and dead links instead of just reporting the error. It's a comparatively minor practice next to a cache-poisoning vulnerability, but it's a good, small example of how much trust sits in a system users rarely think to question.