DNS — Core Concepts
The System That Makes the Internet Usable
The Domain Name System (DNS) was designed in 1983 by Paul Mockapetris to solve a problem that sounds trivial: humans are bad at remembering numbers. Before DNS, there was literally a text file called HOSTS.TXT maintained by one lab at Stanford, and every computer on the internet had to manually download it to know what name mapped to what address. That worked fine when the internet had 400 nodes. It was already collapsing by 1982.
DNS replaced that single file with a distributed database — a hierarchy of servers spread across the globe, each responsible for a small slice of the naming system.
How the Hierarchy Works
DNS is structured like an upside-down tree.
At the very top is the root zone — 13 root server clusters operated by different organizations worldwide (including NASA, Verisign, and ICANN). Below that are the TLD nameservers, one for each top-level domain like .com, .org, .uk. Below those are the authoritative nameservers — the servers actually responsible for individual domains like stripe.com or github.com.
When you register a domain, you’re adding a record to this tree.
The Resolution Process
Most people’s DNS experience goes through four actors:
1. DNS Resolver (your ISP or a third-party like 8.8.8.8 for Google, 1.1.1.1 for Cloudflare)
This is the workhorse. It accepts your query, runs the recursive lookup on your behalf, and caches the result.
2. Root Nameserver
The resolver asks the root: “Who handles .com?” The root doesn’t know where google.com lives — it only knows the address of the .com nameserver. It points the resolver there.
3. TLD Nameserver
The .com server knows which authoritative nameserver is responsible for google.com. Points the resolver there.
4. Authoritative Nameserver
This server has the actual answer — the IP address for google.com. It returns it, and the resolver caches it.
This full round-trip is called recursive resolution. For popular sites like Google, your resolver almost certainly has the answer cached already and skips steps 2-4 entirely.
DNS Record Types
Not everything stored in DNS is an IP address. DNS is a general-purpose lookup system with different record types:
| Record | Purpose | Example |
|---|---|---|
| A | Maps domain to IPv4 address | example.com → 93.184.216.34 |
| AAAA | Maps domain to IPv6 address | example.com → 2606:2800:220:1:248:1893:25c8:1946 |
| CNAME | Alias to another domain | www.example.com → example.com |
| MX | Mail server for a domain | example.com → mail.example.com |
| TXT | Arbitrary text, often for verification | SPF records, domain ownership proofs |
| NS | Nameserver for a domain | Points to authoritative servers |
| PTR | Reverse lookup (IP → name) | Used in email anti-spam checks |
| SOA | Start of authority — metadata about the zone | Serial number, TTL defaults |
MX records are why email routing works at all. When someone sends you an email, their mail server does a DNS lookup for your domain’s MX records to find where to deliver it.
TTL: The Expiry Problem
Every DNS record has a TTL (Time to Live) — a number in seconds that tells resolvers how long to cache the answer.
google.com A 300 means “this record is valid for 5 minutes.”
This is a real operational tradeoff. A long TTL (86,400 seconds = 1 day) means fast responses worldwide but slow rollout if you need to change an IP address. A short TTL (60 seconds) means changes propagate quickly but you hammer your nameservers with queries.
The standard playbook for migrations: lower your TTL to 60 seconds several days before the cutover, wait for the cache to flush, make the change, then raise it back up.
This is why “DNS propagation” takes up to 48 hours — some resolvers cached your old record with a long TTL and won’t re-check until it expires. You can’t force them to flush.
Common Misconception: DNS and the Internet Are the Same Thing
They’re not. The internet works on IP addresses. DNS is a convenience layer on top of it. If DNS goes down, IP addresses still work — you just can’t reach them by name anymore.
In October 2021, Facebook’s entire infrastructure disappeared for six hours. The root cause was an internal BGP configuration change that accidentally withdrew the routes to Facebook’s authoritative nameservers from the global routing table. DNS stopped working. Engineers couldn’t even get into the buildings to fix it because the door badge systems ran on the same infrastructure. The internet itself was fine — Facebook’s slice of it just became unreachable by name.
DNS Security: The Weak Spots
The original DNS protocol was designed with zero security. Responses aren’t authenticated, which led to a category of attack called DNS spoofing or cache poisoning — where an attacker tricks a resolver into caching a fake record. Your query for yourbank.com routes to their server instead.
DNSSEC (DNS Security Extensions) was developed in the 1990s to fix this by adding cryptographic signatures to DNS records. If a record is signed, resolvers can verify it wasn’t tampered with. Adoption has been slow — as of 2024, only about 30% of domains in .com are signed.
DNS over HTTPS (DoH) and DNS over TLS (DoT) are newer approaches that encrypt the DNS query itself, so your ISP (or anyone on the network) can’t see which domains you’re looking up.
One Thing to Remember
DNS is a globally distributed database mapping names to numbers. It’s what makes typing
reddit.comwork instead of memorizing IP addresses — and it’s fragile enough that a single misconfiguration can make an entire company vanish from the internet.