How DNS Works

The Domain Name System (DNS) is often casually summarized as the "phonebook of the internet." However, this massive oversimplification entirely ignores the staggering complexity, distributed architecture, and hyper-optimized caching hierarchy required to resolve billions of domain queries per second with sub-10ms global latency.

---

Part 1: The Protocol and the Transport Layer (UDP vs TCP)

DNS predates the modern web. Specifically designed in 1983 by Paul Mockapetris as RFC 882 and 883, it was built for a much smaller internet. To achieve extreme speed, DNS was originally engineered to operate almost entirely over User Datagram Protocol (UDP) on Port 53.

Why UDP? The Need for Speed

Establishing a TCP connection requires a 3-way handshake. If every single DNS lookup (often multiple per webpage) required a TCP handshake, web browsing would be cripplingly slow. UDP is "fire and forget" – the client sends a query packet, and the server sends an answer packet. There is no connection overhead.

Part 2: The Distributed Hierarchical Tree

There is no single "DNS Server" that knows every domain. The system is a massively distributed inverted tree, designed to delegate authority downwards. If you query `www.example.com.`, the system actually reads it from right to left, starting with the hidden "dot" at the very end.

1. The Root Servers (.): The starting point of all recursive resolution. There are logically 13 root server IP addresses (named A through M). However, thanks to Anycast routing, there are actually thousands of physical servers backing these 13 IPs worldwide. The Root Servers don't know the IP of your website; they only know which servers manage Top-Level Domains (TLDs).
2. The TLD Servers (.com, .org, .uk): Managed by organizations called Registries (e.g., Verisign manages .com). When asked for `example.com`, the `.com` TLD server responds with the Nameservers (NS records) specific to that exact domain.
3. The Authoritative Nameservers: This is the bottom of the tree, usually provided by your domain registrar (Namecheap, GoDaddy) or a cloud provider (AWS Route53, Cloudflare). These servers hold the actual Zone File for your domain—the definitive mapping of A records, CNAMEs, TXT records, and MX records.

Part 3: The Art of Caching and Time-to-Live (TTL)

If every webpage load required querying the Root, TLD, and Authoritative servers, the internet core would instantaneously collapse under petabytes of traffic. DNS survives strictly through aggressive, multi-layered caching.

Every DNS record has a Time-to-Live (TTL) expressed in seconds. This is a contractual promise: "This answer is valid for exactly X seconds. Do not ask me again until this timer expires."

• Browser Cache: Your operating system dictates browser caching. Chrome has its own internal resolver cache (`chrome://net-internals/#dns`).
• OS Cache: Windows, macOS, and Linux all run background services (like `systemd-resolved`) that cache lookups for all local applications.
• ISP / Recursive Resolver Cache: When your device misses locally, it asks the local network's router, which asks the ISP's Recursive Resolver (or Google's 8.8.8.8 / Cloudflare's 1.1.1.1). These public resolvers pool caching among millions of users. If a user in New York looks up `example.com`, the resolver caches the answer. When you request the same domain a second later, the resolver answers instantly from memory without traversing the DNS hierarchy.

When migrating a website to a new server, IT administrators must lower the TTL (e.g., from 86400 seconds / 24 hours down to 300 seconds) days in advance. If they don't, ISPs globally will blindly route traffic to the dead, cached IP address for an entire day, entirely ignoring updates made at the authoritative server.

Part 4: Anycast Network Routing

How does `8.8.8.8` respond from Tokyo in 2ms to a Japanese user, and from London in 2ms to a British user? The answer is not DNS, but BGP (Border Gateway Protocol) manipulating IP routing via a technique called Anycast.

Unlike standard Unicast (one IP = one physical server), Anycast allows hundreds of different servers globally to broadcast the exact same IP address. When your router tries to reach `8.8.8.8`, the BGP internet routing tables automatically direct your packets to the physically nearest data center announcing that path. This is how the 13 logical Root Servers scale to thousands of physical instances, providing massive DDoS resilience and microsecond latency globally.

Part 5: The Evolution of DNS Security

Because DNS was built in 1983 over unencrypted UDP, it is inherently insecure. An attacker on the same Starbucks local network (or a state-level ISP) can easily intercept UDP port 53 traffic, observe exactly what websites you visit, or inject forged IP responses to redirect you to a phishing server (DNS Spoofing / Cache Poisoning).

1. DNSSEC (DNS Security Extensions)

DNSSEC solves the forgery problem. It adds cryptographic, verifiable signatures to DNS records at the authoritative layer. When a resolver fetches an A record, it also fetches an RRSIG (Resource Record Signature). By verifying signatures up a "Chain of Trust" to the Root Zone, the resolver can mathematically guarantee that the IP address wasn't maliciously altered in transit. While this prevents tampering, it does not encrypt the traffic.

2. DNS over TLS (DoT) and DNS over HTTPS (DoH)

To solve the privacy problem, modern protocols encapsulate DNS queries within encrypted tunnels.

• DoT (RFC 7858): Operates on dedicated TCP port 853. It wraps standard DNS queries in a TLS connection. It's fast and distinct, but easily blockable by restrictive firewalls since port 853 is obvious.
• DoH (RFC 8484): Wraps the DNS query inside an HTTP/2 protocol stream over standard TCP port 443 (HTTPS). From the outside, a DNS lookup is entirely indistinguishable from normal web browsing. This makes it virtually impossible for network administrators to monitor or block specific DNS queries, shifting power from the network provider to the end-user's browser.

Conclusion: The Unseen Machinery

The Domain Name System is a triumph of engineering. It is a hierarchical, heavily cached, aggressively optimized distributed database that has seamlessly scaled from a few thousand academic servers to billions of devices. It survives through a delicate balance of UDP efficiency, multi-tiered caching economics, and modern cryptographic retrofits, ensuring that the human-readable web remains instantly accessible across the globe.