Routers don’t speak English. Every packet on the internet needs a numeric destination — an IP address like 142.250.80.46. But humans use names like google.com.
DNS (Domain Name System) is the distributed database that translates one into the other. When your browser needs to connect to google.com, it runs a DNS lookup — a short conversation with a chain of servers that collectively know where every domain in the world points. The whole process typically completes in 20–80 milliseconds.
This post traces that conversation, hop by hop.
The Four Actors
DNS resolution involves four distinct types of server. Understanding who each one is makes the rest of the post click.
Your browser (stub resolver) — knows only one thing: the address of a recursive resolver to ask. It delegates all the work.
Recursive resolver — the server that actually does the resolution work. It queries root, TLD, and authoritative nameservers on your behalf, caches the results, and returns the final answer. Your ISP provides one by default; 8.8.8.8 (Google) and 1.1.1.1 (Cloudflare) are popular alternatives.
Root nameservers — the starting point for any resolution. They don’t know where google.com is, but they know who handles .com. There are 13 root nameserver addresses (labeled a through m), each backed by an anycast cluster of hundreds of physical servers worldwide.
TLD nameservers — responsible for top-level domains like .com, .org, .io. They don’t know Google’s IP, but they know which nameservers are authoritative for google.com.
Authoritative nameservers — the final authority for a domain. Google operates ns1.google.com through ns4.google.com. These servers hold the actual DNS records and return the definitive answer.
The Full Resolution Journey
With the four actors clear, here is the complete lookup for www.google.com — including the cache checks that make real-world DNS fast.
Step by step
Step 1 — Your browser sends the query to its configured recursive resolver. This is a UDP packet (usually, though TCP is used for larger responses).
Step 2 — The resolver checks its own cache. If it resolved www.google.com recently and the TTL hasn’t expired, it returns immediately — no further network calls. For a first lookup, the cache misses.
Step 3 — The resolver asks a root nameserver. Root doesn’t know Google’s IP, but it knows which servers handle .com. It returns a referral to the .com TLD nameservers.
Step 4 — The resolver asks the .com TLD nameserver. TLD doesn’t know the IP either, but it knows ns1.google.com is authoritative for google.com. It returns a referral — including glue records (the IP address of ns1.google.com itself, to avoid a circular dependency). More on glue records in the next post.
Step 5 — The resolver asks Google’s authoritative nameserver directly. This server knows the answer: 142.250.80.46 with TTL 300 (5 minutes).
Step 6 — The resolver caches the answer and returns it to your browser.
Total round trips: 3 network hops for a cold cache. In practice, root and TLD answers are cached for hours or days, so most real-world lookups require only the final hop to the authoritative server.
TTL: Why DNS Changes Take Time
Every DNS record has a TTL — a number (in seconds) set by the domain owner that tells resolvers how long to cache the answer.
www.google.com. 300 IN A 142.250.80.46
↑↑↑
TTL: 300 seconds (5 minutes)Once a resolver has cached this record, it will serve that cached answer for up to 300 seconds without asking Google’s nameserver again. If Google changes their IP during that window, resolvers serving cached answers will still point to the old address until their cached entry expires.
This is what “DNS propagation” means — not a global sync that pushes changes out, but a collection of TTL timers draining across thousands of resolvers worldwide. A TTL of 300 seconds propagates fully in about 5 minutes. A TTL of 86400 (24 hours) means some users may see the old address for up to 24 hours.
Practical implication: If you’re planning a domain migration, lower the TTL to 60 seconds a day or two before switching. After the switch, raise it back. This minimises the exposure window.
Reading a Real DNS Response
The dig command is the standard tool for querying DNS. Every developer who works with domains should know it.
Reading the output:
status: NOERROR— the query succeeded. Other values:NXDOMAIN(domain doesn’t exist),SERVFAIL(nameserver error),REFUSED.flags: qr rd ra—qrmeans this is a response (not a query),rdmeans recursion was desired,rameans recursion is available at this resolver.- QUESTION SECTION — what was asked: the A record for
www.google.com. - ANSWER SECTION (highlighted) — the response: TTL 300, type A, value
142.250.80.46. SERVER: 8.8.8.8— which resolver answered. On your machine, this will be your configured DNS server.Query time: 18 msec— resolver already had this cached. A cold cache would be 60–200ms.
Watching the Hops Live
The +trace flag tells dig to perform the full recursive resolution itself, showing each nameserver hop.
Each highlighted Received line marks a hop:
- Hop 1 (14ms) — root nameserver returns the
.comTLD NS addresses - Hop 2 (22ms) —
.comTLD returns Google’s authoritative NS + glue A records forns1–ns2.google.com - Hop 3 (12ms) — Google’s authoritative NS returns the final answer:
142.250.80.46 - Final answer (8ms) — the authoritative answer, TTL 300
Total: ~56ms for a completely cold cache. Subsequent lookups skip the first two hops entirely.
Notice lines 15–16: ns1.google.com. 172800 IN A 216.239.32.10 — these are the glue records. The TLD included the IP addresses of Google’s nameservers in the ADDITIONAL section so the resolver doesn’t need to make a separate DNS lookup just to reach ns1.google.com. The next post explains glue records in full.