HotShard
Absolute basics

DNS Resolution

How a name like example.com becomes an IP address before any request is sent.

The browser never starts with an address. It starts with a name you typed, like example.com. Routers only move packets to numeric IP addresses. So before the very first request, something has to turn the name into a number. That lookup is DNS, the phone book of the internet. This page shows how the lookup works, why it's fast, and what an interviewer will ask about it.

~5 min read

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

TL;DRthe 30-second version
  • You type a name like example.com. The network routes to a number like 93.184.216.34. DNS turns the name into the number before any request is sent.
  • A recursive resolver does the lookup for you. It asks the root, then the .com server, then the domain's own nameserver. Only that last one returns the IP.
  • Caching makes it fast. Each answer is kept for its TTL, so the next lookup of the same name is a single hop.
  • Caching also makes changes slow to show up. Old answers linger until their TTL expires.

You remember example.com or your bank's website. Humans are good at names and bad at numbers. The network is the opposite. Routers only understand numeric IP addresses, like 93.184.216.34 for IPv4 or 2606:2800:220:1:248:1893:25c8:1946 for IPv6. You can't send a packet to the word example.com.

So before the first byte of a request can go anywhere, the name has to become an address. That translation is DNS, the Domain Name System. Think of a phone book. You know the name, you look it up, and you get the number to dial. DNS is that phone book for billions of names that change all the time.

Why not just one giant list?In the early internet there was one file, HOSTS.TXT, copied to every machine. That broke as soon as the network grew. One file can't be edited by everyone, can't stay fresh, and can't hold billions of names. DNS replaced it with a delegated hierarchy where no single machine has to know everything.

The resolver walks a hierarchy#

Your machine doesn't know the IP. It asks a recursive resolver to find out, usually one run by your ISP or a public one like Cloudflare's 1.1.1.1 or Google's 8.8.8.8. The resolver walks the hierarchy from the top. It asks a root nameserver who runs .com. The root points it to the .com TLD (top-level domain) nameserver. The TLD points it to the domain's authoritative nameserver. That last server owns the records, and it's the only one that answers with the IP address (the A record).

Youthe stub resolver
“www.example.com?”
Recursive resolvere.g. 1.1.1.1
“who runs .com?”“ask the .com TLD server”
Root nameserverknows the TLDs
“who has example.com?”“ask the authoritative ns”
.com TLD nameserverknows the domains
“www.example.com?”“A record = 93.184.216.34”
Authoritative nameserverowns example.com

The IP flows back to you and is cached for the TTL. The next lookup of the same name is a single hop.

Resolving www.example.com on a cold cache
Each level only knows the next level downNo single server holds the whole internet. The root knows the TLDs. The TLD knows its domains. The authoritative server knows its own records. That delegation is what lets DNS scale to billions of names. It also lets the owner of example.com change their records without asking anyone above them.
PredictOn a completely cold cache, how many query round-trips does the resolver make before it can answer you?

Hint: Count one ask per level of the hierarchy.

Three. Root (who runs .com?), TLD (who is authoritative for example.com?), and the authoritative server (what's the A record?). Your own request to the resolver is a fourth hop on top. After that the answer is cached, so the next lookup of the same name is a single hop straight from the resolver's cache.

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 the record's TTL (time-to-live), a number of seconds set by the domain owner. The next lookup of the same name, from you or from anyone else using that resolver, is a single hop from cache.

  • Cold lookup (nothing cached): about 3 referral round-trips, then the answer. Tens to hundreds of milliseconds.
  • Warm lookup (cached and unexpired): 1 hop to the resolver, answered 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 a short-lived copy.
  • TTL bounds staleness. Low TTL means fresher answers but more lookups. High TTL means fewer lookups but slower changes.
A bad name fails hereIf no authoritative server has the record, the answer is NXDOMAIN, meaning 'no such name'. You get it for typos, expired domains, or names that were never created. The lookup fails before any connection is attempted. Once the IP is known, the normal client-server round-trip takes over.

If this comes up in an interview#

The one-linerDNS turns a name into an IP address before any request is sent. A recursive resolver asks the root, then the TLD, then the authoritative server, and caches the answer for its TTL.
Why does a DNS change take time to 'propagate'?

Nothing is pushed out. Resolvers all over the world cached the old answer, and each keeps serving it until that copy's TTL expires. Propagation is really just caches timing out one by one. Lowering the TTL at the moment of the change doesn't help, because the copies already cached still carry the old, longer TTL. Lower it a day before a planned change so the old answers drain quickly.

Recursive resolver vs authoritative server. What's the difference?

A recursive resolver asks on your behalf. It walks the hierarchy and caches what it learns, but it owns no records. An authoritative server is the source of truth for one domain's records and answers only for that domain. Examples: 1.1.1.1 and 8.8.8.8 are resolvers; Route 53 hosts authoritative records.

What is a TTL?

Time-to-live. A number of seconds, set by the domain owner on each record, that tells resolvers how long they may cache the answer before looking it up again. It's the dial that trades freshness (low TTL, fast changes) against load (high TTL, fewer lookups).

How can a DNS answer be faked, and what stops it?

Classic DNS is unauthenticated UDP. An attacker who forges a reply faster than the real one can plant a wrong IP in a resolver's cache, silently sending users to a malicious server. That's cache poisoning. DNSSEC (RFC 4033) signs records, so a forged answer is rejected.

What happens when a domain's authoritative servers go down?

That domain disappears, even though its web servers are fine. In October 2016 a DDoS from the Mirai botnet overwhelmed Dyn, a major managed-DNS provider. Twitter, GitHub, Reddit, Netflix, and Spotify were all up, but nobody could resolve their names. That's why serious operators spread authoritative DNS across more than one provider.

The trade-offs
  • 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. Lower the TTL before a planned change so old answers drain faster. Raise it afterward to cut lookup load.
  • A delegated hierarchy buys scale but concentrates trust. Billions of names get managed independently with no central bottleneck. But each domain depends on its TLD and authoritative servers being reachable, and on the resolver it asks being honest. A problem high in the tree has a wide blast radius.
  • UDP buys speed but limits size and security. A query and its answer fit in one packet with no handshake. But UDP is easy to spoof, and answers must stay small. That pushed DNSSEC (signing) and encrypted transports (DoH and DoT) on top.
The TTL dialThere is no universally correct TTL. Stable records, like a corporate homepage, use long TTLs of hours or a day to minimize lookups. Records that may need to fail over quickly, like a load-balanced endpoint, use short TTLs of seconds to minutes. That keeps propagation delay small at the price of more lookup traffic.
TransportPortEncrypted?Note
UDP53NoDefault; fast, small answers
TCP53NoFallback for big answers / zone transfer
DoT853YesDNS in a TLS tunnel (RFC 7858)
DoH443YesDNS as HTTPS, blends in (RFC 8484)
Record types and modern DNS

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 is an alias: 'www.example.com is really example.com, go look that up instead'.
  • MX says which server receives email for this domain.
  • NS says which nameservers are authoritative for this domain (the delegation glue).
  • TXT holds arbitrary text, used for domain verification and email anti-spoofing (SPF, DKIM).

Recursive vs iterative: your query to the resolver is recursive ('give me the final answer, do whatever it takes'). The resolver's queries to root and TLD servers are iterative ('answer, or tell me who to ask next'). Those upper servers only refer, which is what keeps them cheap.

Anycast: the root and the big public resolvers announce the same IP address from hundreds of locations using BGP anycast, so your packet is routed to the nearest one. That's how the 13 root server systems (labeled a through m, run by twelve organizations) actually run on well over a thousand machines, and how 1.1.1.1 stays fast everywhere.

GeoDNS: the authoritative server chooses what to answer, so it can return a different IP depending on where the query came from. CDNs like Akamai, Cloudflare, and Fastly use this to send each user to a nearby edge. Managed DNS like AWS Route 53 adds health checks and latency-based routing on top. The catch is that the authoritative server sees the resolver's location, not yours, so a far-away resolver can route you to a far-away server.

Encrypted DNS: classic DNS is plaintext on UDP port 53, so anyone on the path, like your ISP or a coffee-shop network, can see and tamper with every name you look up. DoT (RFC 7858) and DoH (RFC 8484) wrap the queries in TLS or HTTPS. The price is that resolution now depends on whichever resolver you chose to trust.

References & further reading
References
Up nextTCP vs UDP
RelatedClient ↔ ServerLRU / LFU Cache← Back to the learning path

Feedback on this topic →