Port 53: DNS — The Internet's Memory

Every name you have ever typed into a browser was translated through port 53.

When you enter "google.com" and arrive at a website, something has to turn that human-readable name into a machine-readable IP address. That something is the Domain Name System, and it speaks through port 53.

DNS is the largest distributed database on Earth. It handles over 7 trillion queries per day.¹ It runs on a protocol designed in 1983 for a network of a few hundred computers. And it still works.

What DNS Does

The Domain Name System translates domain names into IP addresses. When you type "example.com," your computer sends a query through port 53 asking, "What is the IP address for this name?" A DNS server responds with the answer, and your browser connects.

This translation happens constantly, invisibly, for every website you visit, every email you send, every app that phones home. Without DNS, the Internet would require you to memorize sequences of numbers. With DNS, you can remember words.

Port 53 carries both UDP and TCP traffic. Most queries use UDP because it is fast and connectionless. TCP is used for zone transfers between DNS servers and for responses larger than 512 bytes.² When a UDP response is too large, the server sets a truncation flag, and the client retries over TCP.

How DNS Resolution Works

When you type a domain name, your computer does not know the answer. It asks a recursive resolver, typically operated by your ISP or a public service like Cloudflare or Google.

The resolver then performs a series of iterative queries. It asks a root server, "Who handles .com?" The root server points to the TLD (Top-Level Domain) servers for .com. The resolver asks the TLD server, "Who handles example.com?" The TLD server points to the authoritative nameserver for that domain. Finally, the resolver asks the authoritative server for the IP address and returns it to you.³

This entire process happens in milliseconds. The answer is then cached at multiple levels so future queries are even faster.

The History

Before DNS, the Internet used a file called HOSTS.TXT.

Elizabeth Feinler led the Network Information Center at SRI International, which maintained this file. When you wanted to add a new computer to the network, you emailed HOSTSMASTER@SRI-NIC.ARPA. Feinler's team would update the file, and everyone on the network would download the new version. By hand. Once or twice a week.⁴

This worked when the ARPANET had a few hundred hosts. It could not scale.

By 1983, Jon Postel at USC's Information Sciences Institute knew something had to change. Five competing proposals existed for a new naming system. Postel assigned a young researcher named Paul Mockapetris to find a compromise between them.

Mockapetris did not find a compromise. He designed something entirely new.⁵

The Domain Name System he created in 1983 was distributed, hierarchical, and automatic. Instead of a single file on a single computer, DNS spread the work across thousands of servers worldwide. Each server only needed to know about its own piece of the namespace. The system scaled automatically as the network grew.

RFC 882 and RFC 883 defined the initial protocol in November 1983.⁶ Mockapetris refined the specification over the following years, publishing RFC 1034 and RFC 1035 in November 1987. These RFCs remain the foundation of DNS today, updated but never replaced.⁷

The original six top-level domains were .com, .edu, .gov, .mil, .org, and .net. Feinler's team at SRI helped define this structure.⁸ The system that replaced her phonebook carried forward her organizational thinking.

The 2008 Kaminsky Vulnerability

DNS was designed for a trusting network. Security was an afterthought.

In 2008, security researcher Dan Kaminsky discovered a fundamental flaw in the DNS protocol. The attack exploited the fact that DNS transaction IDs only had 65,536 possible values, a number small enough to guess. Previous researchers had noted this weakness, but DNS's time-to-live (TTL) caching limited attackers to only a few guesses per day.

Kaminsky found a way around this. Instead of targeting "www.example.com" directly, he would query for random subdomains like "83.example.com." Each query was new, bypassing the cache and giving the attacker another chance to guess the transaction ID. A successful guess would let the attacker poison the DNS cache, redirecting all traffic for that domain to a malicious server.⁹

Kaminsky coordinated with over 80 technology vendors to patch the vulnerability before going public. On July 8, 2008, they released patches implementing Source Port Randomization, which added another layer of unpredictability to DNS transactions. The details leaked prematurely on July 21, but most systems had already been patched.¹⁰

At Black Hat that year, Kaminsky gave his presentation wearing a suit and rollerskates. His work led directly to the adoption of DNSSEC, which adds cryptographic signatures to DNS responses to prevent spoofing. The root zone was signed for DNSSEC in July 2010.¹¹

Security Considerations

Port 53 is one of the most attacked ports on the Internet. The September 2025 DDoS Analysis Report found that 26.48% of all DDoS attacks targeted DNS.¹²

DNS Amplification Attacks exploit the fact that small queries can generate large responses. An attacker spoofs the victim's IP address and sends queries to open DNS resolvers. The resolvers send their large responses to the victim, overwhelming them with traffic they never requested.

Cache Poisoning injects false records into DNS caches, redirecting traffic to malicious servers. DNSSEC was designed to prevent this by cryptographically signing DNS data, but adoption remains incomplete.

DNS Tunneling uses DNS queries to exfiltrate data or establish command-and-control channels for malware. Because port 53 traffic is rarely blocked, attackers encode data in DNS requests and responses. Over 90% of malware uses DNS at some stage of its operation.¹³

Zone Transfer Exploitation occurs when DNS servers are misconfigured to allow anyone to download their entire zone file. This reveals internal network structure to attackers.

Organizations often leave port 53 open on firewalls without inspection because blocking it breaks everything. This makes DNS an attractive vector for attacks that want to hide in legitimate traffic.

The Evolution: Encrypted DNS

Traditional DNS sends queries in plaintext. Anyone on the network path can see what domains you are resolving. This is a privacy problem.

Two protocols now address this:

DNS over TLS (DoT) encrypts DNS traffic using TLS on port 853. It was standardized in RFC 7858 in 2016. Network administrators can still see that DNS traffic is occurring because it uses a dedicated port.¹⁴

DNS over HTTPS (DoH) sends DNS queries over HTTPS on port 443, the same port used for regular web traffic. Standardized in RFC 8484 in 2018, it makes DNS queries indistinguishable from other encrypted web traffic.¹⁵

DoT is better for enterprise networks that need visibility. DoH is better for privacy because it blends in. Both protect against eavesdropping.

Related Ports