DNS Resolution

The big picture#

Everything below expands on these points. Read the core sections top to bottom for the full picture; the collapsible "Go deeper" boxes hold the advanced bits (query modes, record types, encrypted DNS, anycast) you can skip on a first pass and return to later.

Start here: names are for humans, numbers are for routers#

You remember example.com, wikipedia.org, your bank's website. Humans are good at names and terrible at numbers. The network is the opposite: routers and packets only understand numeric IP addresses, like 93.184.216.34 (IPv4) or 2606:2800:220:1:248:1893:25c8:1946 (IPv6). There is no way to send a packet to the word "example.com" — the address has to be a number.

So before the very first byte of a request can travel anywhere, something must translate the name you typed into an address the network can route to. That translation is DNS — the Domain Name System. The classic metaphor is a phone book: you know a person's name, you look it up, and you get the number you actually dial. DNS is that phone book for the entire internet, and it has to work for billions of names that change constantly.

The resolver walks a hierarchy#

Your machine doesn't know the IP, so it asks a recursive resolver (usually run by your ISP or a service like Cloudflare's 1.1.1.1 or Google's 8.8.8.8) to do the work. The resolver walks a hierarchy from the top down: it asks a root nameserver who runs '.com', the root refers it to the .com TLD nameserver, the TLD refers it to the domain's authoritative nameserver, and only that last server — the one that actually owns the records — returns the IP address.

• Root nameserver: knows who runs each top-level domain (.com, .org, …) — refers, doesn't answer.
• TLD nameserver: knows who is authoritative for each domain under it — refers, doesn't answer.
• Authoritative nameserver: owns the actual records for the domain — answers with the IP (the A record).
• Recursive resolver: does this whole walk on your behalf and hands you the final answer.

Caching and TTL make it fast#

Walking the hierarchy every time would be slow — a cold lookup is three serial round-trips to servers that may be far away. So the resolver caches each answer for a duration set by the record's TTL (time-to-live), a number of seconds chosen by the domain owner. The next lookup of the same name — from you or anyone else using that resolver — is a single hop straight back from cache. This is the same cache-vs-store trade-off you'll see everywhere later, applied to name lookups.

• Cold lookup (nothing cached): ~3 referral round-trips down the hierarchy, then the answer — tens to hundreds of milliseconds.
• Warm lookup (cached and unexpired): 1 hop to the resolver, which answers from memory — often under a millisecond on the same network.
• Caching happens at many layers: the browser, the operating system, the resolver, and sometimes the home router each keep their own short-lived copy.
• TTL bounds staleness: a record's TTL is the longest time a cached copy may be served before it must be looked up again. Low TTL = fresher but more lookups; high TTL = fewer lookups but slower to change.

Query modes, record types, and modern DNS#

The core idea — name in, address out — has a few important variations. The most common is the kind of query, and the kind of record you ask for. A DNS answer isn't always an IP: the same system stores several kinds of records, and you ask for the type you need.

• A — maps a name to an IPv4 address. AAAA — maps a name to an IPv6 address.
• CNAME — an alias: 'www.example.com is really example.com, go look that up instead'.
• MX — mail exchange: which server receives email for this domain.
• NS — which nameservers are authoritative for this domain (the delegation glue).
• TXT — arbitrary text, used for domain verification and email anti-spoofing (SPF, DKIM).

The trade-offs#

DNS makes two big bets, and each one has a cost you feel in practice.

• Caching buys speed but costs freshness. A warm lookup is nearly free, but after you change a record, every cached copy keeps serving the old answer until its TTL expires — this is propagation delay. Lower the TTL before a planned change and old answers drain out faster; raise it afterward to cut lookup load.
• A delegated hierarchy buys scale but concentrates trust. Delegation lets billions of names be managed independently without any central bottleneck. But each domain depends on its TLD and authoritative servers being reachable, and on the resolver it asks being honest — so a problem high in the tree, or a compromised resolver, has wide blast radius.
• UDP buys speed but limits size and security. DNS uses connectionless UDP for its tiny query/answer so there's no handshake — but UDP is easy to spoof and answers must be small, which pushed the design toward DNSSEC (signing) and encrypted transports (DoH/DoT) layered on top.

How DNS fails#

• NXDOMAIN — the name doesn't exist. A typo, an expired domain, or a record that was never created: the authoritative server says 'no such name' and the lookup fails before any connection.
• Stale cache after a change — you updated a record but users still hit the old IP. They're being served a cached answer whose TTL hasn't expired yet; nothing is broken, you just have to wait it out (or you forgot to lower the TTL beforehand).
• Cache poisoning / spoofing — because classic DNS is unauthenticated UDP, an attacker who can forge a reply faster than the real one can plant a wrong IP in a resolver's cache, silently sending users to a malicious server. DNSSEC (RFC 4033) defends against this by cryptographically signing records so forged answers are rejected.
• Resolver or authoritative outage — if your resolver is down you can't look up anything; if a domain's authoritative servers are unreachable, that domain effectively disappears even though its web servers are fine.

How the pieces compare#

DNS in the wild#

• The root is run as 13 named server systems (labeled a through m), operated by twelve organizations. Each 'server' is really hundreds of machines worldwide sharing one address via anycast, so the root is far more resilient than '13 boxes' suggests.
• Public recursive resolvers: Cloudflare's 1.1.1.1 and Google's 8.8.8.8 are anycast resolvers anyone can use, often faster and more private than an ISP's default.
• Managed authoritative DNS: AWS Route 53, Cloudflare, and NS1 host the authoritative records for huge numbers of domains, adding health checks and latency-based routing.
• CDNs use DNS as a steering layer: by returning a different IP per region (GeoDNS), providers like Akamai, Cloudflare, and Fastly send each user to a nearby edge — DNS doing load balancing, not just lookup.
• The 2016 Dyn outage showed the flip side: knock out the authoritative DNS and the sites behind it become unreachable even while perfectly healthy.

Common questions & gotchas#

In an interview#

Lead with the one-liner: DNS turns a human-readable name into a routable IP address before any request is sent, and it does it through a delegated hierarchy plus caching. Then trace the walk: the recursive resolver asks root → TLD → authoritative, where each level only knows the next, and the authoritative server returns the A record.

Show you understand the trade-off: caching with TTL makes warm lookups a single hop, but the price is propagation delay when records change. Name the dial (TTL), the failure modes (NXDOMAIN, stale cache, spoofing → DNSSEC), and the real systems (1.1.1.1, 8.8.8.8, Route 53, the anycast root). If the question is about fast failover or geo-routing, mention low TTLs and GeoDNS; if it's about availability, cite Dyn 2016 and multi-provider authoritative DNS.

Then open the simulator: watch a cold lookup walk root → TLD → authoritative, see the answer get cached, then run the same lookup again and watch it return in a single hop.

References & further reading#