DNS - The Complete Guide

A STANDALONE REFERENCE  ·  HOW A NAME BECOMES A CONNECTION
A computer only knows how to route to a number - an IP address. Every other layer of the internet, starting with the address bar in your browser, is built to spare a human from ever having to remember one. That's DNS: not a single lookup, but a distributed, cached, hierarchical system built to answer one question, correctly, at a scale of trillions of times a day, without a single company ever having to own the whole answer.
1. First Principles - Why DNS Has to Be Distributed
"Names are easier to remember than numbers" is true, but it's not the whole reason DNS looks the way it does
  • Your contact list maps "Shailesh" → a phone number - DNS maps a domain name → an IP address, for exactly the same reason: names are what humans remember
  • That much explains why translation exists. It doesn't explain why one giant lookup table couldn't just do it
  • The real constraints: nobody owns the whole internet's naming, the answer has to survive any single company's outage, and it has to serve trillions of lookups a day without melting
  • The solution to all three at once: split ownership by domain (nobody's in charge of everything), spread the load hierarchically (root → TLD → authoritative), and cache aggressively at every layer so most lookups never travel far at all
2. The Full Resolution Chain
The part almost everyone leaves out: caching is checked at every layer, before anyone asks the root anything (looping)
  • Browser cache, then OS cache - checked first, every time; most lookups end right here and never leave the machine
  • Only on a full miss does the request reach a recursive resolver (your ISP's, or a public one like 8.8.8.8) - the client asks it one question and expects one final answer
  • The resolver then does the legwork itself: root server → ".com, ask this TLD server" → TLD server → "google.com, ask this authoritative server" → authoritative server → the actual IP
  • The resolver caches the answer before handing it back, so the next request for google.com - from anyone using that resolver - skips straight to the fast path
📇 Your original instinct was right that DNS is like a contact list - it's actually a contact list with a manager (the resolver) who checks their own notes first, and only calls the phone company (root → TLD → authoritative) when they genuinely don't already know the number.
3. DNS Record Types - the Actual "Components"
The authoritative server doesn't hand back just one kind of answer
A / AAAA
The core mapping: a domain to an IPv4 (A) or IPv6 (AAAA) address - the record your original walkthrough was describing.
CNAME
An alias - "this name is really just another name," which then gets resolved again. Chains of these are common, and each hop costs a little latency.
MX
Where email for this domain should actually be delivered - a separate destination from the website entirely.
NS
Which servers are authoritative for this domain - literally what the TLD server hands back to point the resolver onward.
TXT
Arbitrary text - used for domain ownership verification, and heavily for email anti-spoofing (SPF, DKIM, DMARC).
SOA
Start of Authority - the zone's own admin metadata: who's responsible, and how long other resolvers should cache its answers.
4. Recursive vs Iterative Resolution
Two different contracts, inside the same overall lookup
Recursive (client ↔ resolver)
  • The client asks exactly one question - "what's the IP for google.com?"
  • It expects a final answer, not a pointer to ask someone else
  • All the actual work happens on the resolver's side, invisibly
VS
Iterative (resolver ↔ root/TLD/authoritative)
  • Each server gives its best answer, or a referral - never a final one
  • The resolver has to follow each referral itself, one hop at a time
  • Root and TLD servers are never asked to do the whole job - just point one step closer
☎️ Analogy: asking the resolver is like calling one directory-assistance number and getting a final phone number back. What the resolver does internally is more like calling the area's operator, being told which local exchange to call, calling that, and being told which specific line to try - nobody in that chain just hands you the final number except the last one.
5. Caching & TTL - Why the Root Almost Never Gets Asked
The same domain, looked up twice - the second time never leaves the resolver (looping)
  • Every DNS record carries a TTL (time-to-live) set by the domain's own authoritative server - a number of seconds the answer is allowed to be reused
  • Short TTL: changes propagate fast, but every resolver re-asks far more often - more load, everywhere
  • Long TTL: barely any repeat traffic reaches the authoritative server, but a change (like moving to a new IP) takes that long to be seen by everyone
  • This is the exact same trade-off as topic 5 of the caching guide - DNS TTL is a cache expiry, with all the same consequences
6. Real-World Architecture
Who actually runs the servers behind each hop
Public Resolvers
(Google 8.8.8.8, Cloudflare 1.1.1.1)
Root Servers
(13 letters, anycast)
Authoritative DNS
(Route 53, Cloudflare)
Anycast Routing
  • There are only 13 root server "letters" (a through m), but each one is anycast - the same IP address answered by hundreds of physical machines worldwide; your query reaches whichever is network-closest
  • Route 53, Cloudflare DNS, NS1, Google Cloud DNS - the authoritative side most companies actually use, rather than running their own
  • Anycast is exactly what keeps 13 logical root servers from ever being a real bottleneck for the whole internet
7. DNS-Based Load Balancing & GeoDNS
The lookup itself can be the routing decision
  • An authoritative server doesn't have to return the same IP to everyone - it can answer based on the resolver's location, current server load, or a health check
  • GeoDNS: a user in Mumbai and a user in Berlin asking for the exact same domain get back two different IPs - each pointed at the nearest CDN edge or data center
  • This is a real, load-bearing part of how CDNs (topic 08 of the main series) and multi-region systems actually route traffic - before a single HTTP request is even sent
🌍 Real-World Example: a global streaming service resolves the same hostname to different IPs per region, so "the server" a user connects to is already the nearest one - no application-level redirect required, because DNS made the decision first.
8. Failure Scenarios & Edge Cases
What actually goes wrong, and why it's rarely the DNS servers themselves that are broken
  • Propagation delay: you change a record, but anyone whose resolver already cached the old value keeps getting it until that TTL expires - "I changed my DNS and nothing happened" is almost always this, not a broken change
  • DNS cache poisoning / spoofing: an attacker sneaks a fake record into a resolver's cache, silently redirecting a real domain to a malicious IP for every user of that resolver until the entry expires
  • The 2016 Dyn attack: a DDoS against one major authoritative DNS provider took down Twitter, Netflix, Spotify, and others - not because those services broke, but because nobody could resolve their names anymore. The lesson: DNS is a dependency your uptime inherits, whether or not you host it yourself
  • Split-horizon DNS: an internal resolver deliberately returns a different (private) IP for the same domain than the public internet sees - useful, but a frequent source of "works on the office network, not from home" bugs
⚠️ Common Misconception: "DNS just resolves names, it's not really part of the security surface." DNSSEC exists specifically because resolution itself can be spoofed - cache poisoning doesn't touch your server at all, it just convinces resolvers to send your users somewhere else entirely.
9. Scale & Numbers
The math behind why the root servers aren't drowning
🌐 Why caching is load-bearing, not optional
Roughly 5 billion people are online, each generating on the rough order of 100+ DNS lookups a day just from normal browsing - that's 500+ billion lookups a day, globally, at the client level. If even 95% of those are answered from a browser, OS, or resolver cache without ever leaving that machine or ISP, the number that actually reaches the root/TLD layer drops to roughly 25 billion a day - and thanks to anycast spreading that across hundreds of physical root instances worldwide, no single machine ever sees more than a sliver of it. Remove caching from this picture, and the root system doesn't scale at any price.
10. Trade-offs at a Glance
Every decision above, on one page
DecisionOptionWhat you getWhat it costs you
TTL LengthShortChanges propagate quicklyFar more repeat traffic to the authoritative server
LongMinimal repeat load, cheap to serveA change can take a long time to fully propagate
Resolution StyleRecursive (client-facing)Simple client contract - ask once, get an answerAll the real work is hidden, harder to debug from the client side
Iterative (resolver-facing)No single server does the whole jobMore round trips per cold lookup
DNS-Based RoutingGeoDNS / anycastRoutes users to the nearest server before the first requestCaching can send some users to a stale, farther region briefly
Single fixed IPSimple, predictableNo geographic or load-aware routing at all
11. Interview Framing
The questions that actually get asked, and the sharpest honest answer to each
Q: Walk me through what happens when you type a URL into the browser.
Browser cache checked, then OS cache - most requests end there. On a miss, the recursive resolver takes over and iteratively queries root → TLD → authoritative, caches the result, and returns the IP. Only then does the browser open a TCP/TLS connection and send the actual HTTP request.
Q: What's the difference between recursive and iterative DNS resolution?
Recursive is the contract between the client and its resolver - one question, one final answer. Iterative is what the resolver does internally against root, TLD, and authoritative servers - each gives a referral, never the final answer, and the resolver follows each hop itself.
Q: Why does DNS mostly use UDP instead of TCP?
Most DNS responses are small enough to fit in a single UDP packet, and UDP avoids the connection setup overhead of TCP - meaningful at the scale DNS operates at. DNS falls back to TCP when a response is too large (some DNSSEC responses, zone transfers).
Q: How would you use DNS to route users to the nearest data center?
GeoDNS at the authoritative layer - resolve the same hostname to different IPs based on the resolver's apparent location, paired with a low-enough TTL that a region failover is actually noticed in reasonable time.
Q: Your team just migrated to a new server, but some users still hit the old one. Why?
DNS propagation delay - some resolvers cached the old record and won't ask again until that TTL expires. The real fix, going forward: lower the TTL before a planned migration, not after.
12. Quick Reference - The Whole Thing, One Place
The chain, in order:
✔ Browser cache → OS cache → recursive resolver
✔ Resolver → root → TLD → authoritative (iterative)
✔ Answer cached at the resolver for next time
Remember when things go wrong:
✔ "Nothing changed" → check TTL / propagation first
✔ Users redirected somewhere wrong → consider cache poisoning
✔ Whole site "down" → check if it's actually just DNS
🏁 DNS isn't one lookup - it's a caching system wearing a phone book's clothes. Almost every real DNS problem is a caching problem wearing a DNS costume.