Q07 — How does DNS work — what actually happens between typing a URL and a response arriving?

Why does DNS need to exist at all?

Computers on the internet find each other using IP addresses — numbers like 142.250.80.46. But humans don't use numbers. When you want to visit Google, you type google.com, not 142.250.80.46.

There has to be a system that translates human-readable names into machine-usable IP addresses. That system is DNS — the Domain Name System.

The naive solution would be a single global file that maps every domain name to its IP address. In the early internet, this actually existed: a file called HOSTS.TXT maintained by Stanford Research Institute, downloaded periodically by every machine. As the internet grew to hundreds and then thousands of machines, this approach broke down. The file became too large, updates were too slow to propagate, and one organization maintaining all names didn't scale.

DNS replaced the flat file with a distributed, hierarchical, cached system that scales to billions of domains.

What is the hierarchy?

DNS is organized as a tree. At the root is the root zone, managed by a set of 13 root name server clusters distributed globally. Below the root are top-level domains (TLDs): .com, .org, .net, .io, country codes like .uk and .jp. Below each TLD are second-level domains: google.com, github.com. Below those can be subdomains: mail.google.com, api.github.com.

Each level of this tree is managed by different organizations. ICANN oversees the root. Verisign manages .com. You, as a domain owner, manage your own subdomain records. No single entity needs to know everything — each entity only needs to know the next level down.

What happens when you type `google.com` and press enter?

Step 1: Check local caches

Your browser first checks its own DNS cache — it may have looked up google.com recently and still has the answer. If not, it asks the operating system, which checks the OS-level DNS cache. Most lookups end here, because you've visited these sites before and the result is cached.

If neither cache has the answer, the OS asks a recursive resolver — typically a DNS server provided by your ISP, or a public one like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare). This is the resolver configured in your network settings.

Step 2: The recursive resolver asks the root

The recursive resolver is named "recursive" because it does the legwork for you. It may also have google.com cached from a recent query by another user. If not, it starts from the top.

It contacts one of the 13 root name server clusters: "I'm looking for google.com. Can you help?" The root doesn't know the IP address for google.com — it only knows who's responsible for .com. It responds: "I don't know, but here's the address of the .com TLD name server."

Step 3: Ask the TLD name server

The recursive resolver contacts the .com TLD name server: "I'm looking for google.com." The .com server doesn't know Google's IP address either — but it knows who's responsible for google.com. It responds: "Here are Google's authoritative name servers — ns1.google.com, ns2.google.com."

Step 4: Ask the authoritative name server

The recursive resolver contacts Google's authoritative name server: "What is the IP address for google.com?" This server actually knows the answer — it's the source of truth for google.com's DNS records. It responds: "The IP address is 142.250.80.46."

Step 5: The answer flows back

The recursive resolver returns the IP address to your OS, which passes it to your browser. Your browser now has an IP address and can open a TCP connection.

Total time for an uncached lookup: typically 10–100 milliseconds, involving 3–4 round trips.

Why does DNS use caching everywhere?

Without caching, every request to google.com would require the full 4-step process above, contacting 3 different servers. With billions of users making billions of requests, the root name servers would be crushed.

DNS solves this with TTL — Time To Live. Every DNS record carries a TTL value (set by the domain owner) that tells caches how long to store the answer. A common TTL for google.com might be 300 seconds (5 minutes). During those 5 minutes, anyone whose resolver has already looked up google.com reuses the cached answer without touching the root or TLD servers at all.

This means the root name servers, despite serving the entire internet, actually handle a tiny fraction of DNS queries — because the recursive resolvers cache everything. The root is consulted only when a resolver sees a TLD for the first time, which is rare once its cache warms up.

Why is DNS fast even though it involves multiple hops?

Two reasons: caching (most lookups hit a cache and skip the hierarchy entirely) and UDP (DNS uses UDP for queries — no handshake, tiny packets, single round trip per hop).

DNS queries and responses usually fit in a single UDP packet (historically limited to 512 bytes; the EDNS(0) extension allows larger, and resolvers today typically cap it around 1232 bytes to avoid IP fragmentation). The request and response are each one packet. If an answer is too big, the server sets a "truncated" flag and the client retries the query over TCP — so DNS uses TCP too, just rarely. No connection setup. This makes each hop in the resolution chain extremely fast — just a network round trip.

If a DNS response is too large for UDP, the resolver falls back to TCP — but this is rare and usually only happens for large zone transfers between servers.

What happens when a domain's IP address changes?

The domain owner updates their authoritative name server records. But the old IP address is cached everywhere — at recursive resolvers, at ISPs, in browsers and operating systems — for however long the TTL specifies.

This is why DNS changes propagate slowly. If example.com had a TTL of 3600 seconds (1 hour) and you change its IP, it takes up to an hour for all caches to expire and refetch the new record. Domain owners preparing for a migration typically lower the TTL (to 60–300 seconds) days in advance, then make the IP change, then raise the TTL again after the change propagates.

This is also why "DNS propagation" takes time — it's not one server updating, it's thousands of caches around the world independently expiring and refreshing.

What are the different types of DNS records?

DNS isn't just for mapping names to IP addresses. Records serve different purposes:

A record: maps a domain to an IPv4 address (google.com → 142.250.80.46)
AAAA record: maps a domain to an IPv6 address
CNAME record: maps a domain to another domain name (an alias). www.example.com → example.com, then resolve example.com to an IP
MX record: identifies the mail server for a domain — where to deliver email sent to @example.com
TXT record: arbitrary text, commonly used for domain ownership verification and email authentication (SPF, DKIM)
NS record: identifies the authoritative name servers for a domain

The mental model

code

You type: google.com

Browser cache? → hit → done
OS cache?      → hit → done
Recursive resolver cache? → hit → done
                ↓ (miss at all levels)
Resolver → Root: "who handles .com?"
Root → Resolver: "here are .com TLD servers"
Resolver → .com TLD: "who handles google.com?"
TLD → Resolver: "here are google.com's authoritative servers"
Resolver → Google NS: "what's the IP for google.com?"
Google NS → Resolver: "142.250.80.46, TTL=300"
Resolver → OS → Browser: 142.250.80.46

Browser opens TCP connection to 142.250.80.46

DNS is a distributed database where no single machine knows everything, caching makes it fast, TTL controls how long cached answers are trusted, and the hierarchy ensures that each organization only manages its own piece of the namespace.