DNS translates domain names into IP addresses. It was built in 1987 with no privacy in mind, and by default it still has none. Here is how it works and why every privacy tool you use has to deal with it.
7 min read
DNS stands for Domain Name System. Its job is to translate human-readable domain names into the IP addresses that computers actually use to route traffic. When you type boycat.io into a browser, your device has no idea what IP address that maps to. It asks a DNS resolver, which looks up the answer and returns it. Only then does your browser make the actual connection.
The system was designed by Paul Mockapetris and published as RFC 1034 and RFC 1035 in November 1987.12 The internet at that time was a small network of universities and research institutions. The design goal was reliability and scalability. Privacy was not a consideration. There was no encryption. There was no authentication of responses. A query went out in plain text, an answer came back in plain text, and anyone watching the network could read both.
Nearly 40 years later, the underlying structure is unchanged. The protocol that handles the first step of almost every connection you make still sends your requests in plaintext by default, to a server you probably did not choose.
When your device needs to resolve a domain, the process works its way through a hierarchy of servers. Your device checks its local cache first. If the answer is not there, it asks a recursive resolver, which is typically operated by your ISP. The resolver works down the DNS hierarchy, from root servers to top-level domain servers to the authoritative server for the domain you requested, and returns the IP address.
Every one of these queries travels over UDP port 53 by default, in plaintext. When your device asks "what is the IP address for reddit.com," that question leaves your machine as readable text. Anyone who can observe the packet at any point in the network can see exactly what you asked and when you asked it.
The return path is equally visible. Timing attacks are possible: an observer who can see DNS queries but not the subsequent connections can still build a detailed profile of which services you use, when you use them, and how often.
The privacy risks of unencrypted DNS are documented formally in RFC 9076.5 The practical consequences are direct.
Your ISP operates your default DNS resolver. Every domain you look up goes through their infrastructure. They see your browsing history at the DNS level: which sites you visit, at what times, and how frequently. This is true even when the pages you visit use HTTPS, because the DNS query happens before the encrypted connection is established. The lookup reveals the destination before the session even begins.
This is why HTTPS alone is not enough to protect your browsing from ISP visibility. HTTPS encrypts the content of a connection, but the DNS lookup that preceded it already disclosed the destination. Your ISP knows you visited a particular site even if they cannot see what you did there.
The exposure extends beyond ISPs. Anyone who can observe your network traffic can read DNS queries: someone monitoring a public Wi-Fi network, a network administrator at a workplace or school, or national-level surveillance infrastructure in countries that operate it.
Two standards address the plaintext problem directly.
DNS over HTTPS (DoH) was published as RFC 8484 in 2018.3 It wraps DNS queries inside HTTPS, sending them over port 443, the same port used for ordinary web traffic. The query is encrypted and indistinguishable from regular HTTPS. Firefox, Chrome, and most modern browsers support it. Windows and macOS can enable it at the system level.
DNS over TLS (DoT), published as RFC 7858 in 2016,4 provides equivalent encryption but on a dedicated port: 853. Because DoT uses its own port, network administrators can see that encrypted DNS is being used, even if they cannot read it. With DoH on port 443, there is no way to distinguish DNS traffic from regular HTTPS without deep packet inspection. For personal privacy, DoH is generally harder to block or filter.
Both standards shift DNS trust away from your ISP, but they do not eliminate it. They replace the ISP as the DNS operator with whichever resolver you configure, typically a large provider like Cloudflare (1.1.1.1) or Google (8.8.8.8). Your queries are private from your ISP, but visible to the resolver. The no-logs policy of the resolver matters for the same reason it matters when choosing a VPN.
A VPN that handles DNS correctly routes all queries through the VPN tunnel to a resolver the provider controls. Your ISP sees traffic going to the VPN server and nothing else. They no longer handle your DNS queries, and cannot see the domains you look up.
The critical word is correctly. A VPN that does not intercept DNS traffic, or that falls back to the system resolver under load or during reconnects, will leak your DNS queries to your ISP even while appearing connected. This is a DNS leak, and it is more common in consumer VPN software than it should be. BuycatVPN routes all DNS through the tunnel with leak protection active on every platform by default.
The full picture of how leaks happen, how to test for one, and how to fix it is in the DNS leaks article. The short version: test with a dedicated tool while connected and confirm the resolver showing in results belongs to your VPN provider, not your ISP.
P. Mockapetris, IETF, November 1987. The foundational DNS specification.
P. Mockapetris, IETF, November 1987.
P. Hoffman & P. McManus, IETF, October 2018.
Z. Hu et al., IETF, May 2016.
T. Wicinski, IETF, July 2021. Documents the privacy risks of unencrypted DNS.
More in Foundations
