DNS

In 1983, the ARPANET had grown to a few hundred computers. Each computer knew its own IP address, and if you wanted to talk to another one, you looked up its name in a single file called HOSTS.TXT. The file lived at SRI International in California and was manually updated as new hosts joined. Every computer on the ARPANET downloaded a copy periodically. As the network grew past a few hundred hosts, this stopped scaling — imagine editing a shared text file every time someone added a new server.

Paul Mockapetris at USC/ISI proposed a solution: replace the single flat file with a hierarchical, distributed database where each organization managed its own portion. He published RFC 882 and RFC 883 in 1983, then refined the design in RFC 1034 and RFC 1035 in 1987. The result was the Domain Name System — DNS. Today DNS serves an estimated ~5 trillion queries per day globally. Every time you type a URL, click a link, open an app, send an email, or your phone syncs your calendar, DNS resolves at least one name to an IP.

DNS is officially a Layer 7 (Application) protocol, running mostly over UDP (Layer 4) on port 53. But its role is foundational: without DNS, you'd need to memorize 142.250.80.46 to reach Google. Every protocol above IP implicitly depends on DNS to be usable. It's also the internet's biggest attack surface — DDoS amplifiers, cache poisoning, hijacking, censorship. And it's a load balancer: change the DNS response and you route traffic differently.

The hierarchy — how names are organized

DNS is a tree. The root is the empty string (called "the dot"). Below the root are top-level domains (TLDs): .com, .org, .net, .io, .co.uk, and 1500+ others. Below each TLD are second-level domains: google.com, github.io, bbc.co.uk. Below those are subdomains: mail.google.com, api. github.com. The tree can be arbitrarily deep.

Each level of the tree is served by a different authoritative name server. The 13 root name servers (named a.root-servers.net through m.root-servers.net) know where all the TLD servers are. Verisign runs the .com and .net TLD servers. GoDaddy is the biggest registrar for buying second-level domains. Once you own google.com, you can point it at whichever authoritative name servers you want (Cloudflare, AWS Route 53, or your own bind9 install).

Recursive resolution — the animated walkthrough

You type google.com into your browser. What happens? A recursive resolver (usually your ISP's or one you configured like 1.1.1.1) walks the hierarchy on your behalf.

The full recursion involves up to 4 round-trips (root → TLD → authoritative → response), but caching drops that to typically 1 round-trip in steady state. Every hop that answers stores its answer with a TTL (Time-To-Live) — how long other resolvers may cache the answer before asking again. Popular sites like google.com are cached almost everywhere with sub-millisecond access.

TTL — the caching knob that runs the internet

TTL is the single most important operational knob in DNS. Long TTL (e.g., 1 day) means resolvers cache aggressively — fewer queries hit your authoritative servers, less load, less cost — but if you change the record, the change won't propagate for up to a day. Short TTL (e.g., 60 seconds) means fast propagation but more queries and more load.

Rule of thumb: long TTL for stable records (your MX servers rarely change) and short TTL for volatile records (health-checked A records that swap during a failover). Before a planned migration, drop the TTL a day early so resolvers refresh frequently by cutover time.

Record types — the alphabet soup

DNS carries many types of records, not just A records (hostname → IPv4). Each record type serves a specific purpose:

DNS as a load balancer

Here's a design trick: because DNS resolvers cache and every resolver can get a different answer, DNS itself can act as the first tier of load balancing. Four common techniques:

DNS security — the underbelly

DNS was designed in 1983 with zero security assumptions. UDP is stateless — you send a query, an answer comes back, and you have no way to verify the answer wasn't forged. This has led to decades of attacks and slow migrations toward secure DNS.

• Cache poisoning (Kaminsky 2008): attacker floods the resolver with fake responses matching a spoofed query ID, hoping one lands before the real answer. Fixed partially by source-port randomization and DNSSEC.
• DNS amplification: attacker sends a small DNS query with a spoofed source IP (the victim). The huge response floods the victim. Classic DDoS vector.
• DNS hijacking: attacker changes NS or A records at a registrar to point domains at their servers. Cryptocurrency exchanges are common targets.
• ISP censorship: ISPs return NXDOMAIN or redirects for blocked sites. Users route around this via third-party resolvers (1.1.1.1, 8.8.8.8) or DoH.
• DNSSEC (2005) — every zone signs its records with a private key; resolvers verify against a chain of trust rooted at the root zone.
• DoT (2016) & DoH (2018) — DNS queries encrypted so ISPs can't see or modify them.

Applied in real systems — lots of examples

Key takeaways

• DNS is a hierarchical distributed database from 1983. Root → TLD → authoritative → subdomain. Layer 7, port 53, mostly UDP.
• Recursive resolution walks the hierarchy on your behalf. Cold: up to 4 round-trips. Warm: 1 round-trip. Caching is what makes DNS fast in practice.
• TTL is the caching-vs-agility knob. Long TTL = fewer queries, slower propagation. Short TTL = fast changes, more load.
• Record types matter. A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), TXT (arbitrary), NS (nameserver), SRV (service), SOA (zone metadata).
• DNS is a load balancer: round-robin, weighted, latency-based, GeoDNS, and health-check-driven failover all work at the DNS layer.
• DNS security: DNSSEC signs responses, DoT/DoH encrypt them. Cache poisoning, amplification, and hijacking are the classic attacks.
• Every serious system depends on DNS as a hidden dependency. When DNS fails, everything fails. Design for it: fallback resolvers, aggressive local caching, monitor query success rates.

References

• Mockapetris (1983, 1987) — RFCs 882, 883, 1034, 1035. The DNS design.
• Kaminsky (2008) — Black Hat presentation on the cache-poisoning attack that forced worldwide patching.
• RFCs 4033-4035 (2005) — DNSSEC.
• RFC 7858 (2016) — DNS over TLS.
• RFC 8484 (2018) — DNS over HTTPS.
• Cloudflare Learning Center — DNS docs at cloudflare.com/learning/dns/