Stage 3 · Build
DNS: The Phone Book of the Internet
DNS Resolution Chain
Recursive resolvers, authoritative servers, caching, TTL, and negative caching.
The DNS Hierarchy
DNS is a distributed hierarchical database. At the top are the root servers (13 clusters identified by letters a-m). Below them are TLD servers (.com, .org, .net, .io). Below those are authoritative nameservers for individual domains. Each level delegates authority to the level below.
. (root)
/ | \
.com .org .net ...
/ | \
example wikipedia github
/ \
www mailEach domain owns nameservers that know the answers for that domain. The hierarchy lets any domain in the world be found by starting at the root and following the chain.
Resolution Walkthrough
When you type www.example.com in a browser, your computer asks a recursive resolver (usually your ISP or 8.8.8.8) to find the answer. The resolver does the work of walking the hierarchy on your behalf.
1. Browser checks local cache -> miss
2. OS checks /etc/hosts -> miss
3. OS asks recursive resolver (e.g., 8.8.8.8)
4. Resolver checks its cache -> miss
5. Resolver asks root server: Who handles .com?
-> Ask a.gtld-servers.net
6. Resolver asks .com TLD: Who handles example.com?
-> Ask ns1.example.com
7. Resolver asks example.com: What is www.example.com?
-> 93.184.216.34, TTL=3600
8. Resolver returns 93.184.216.34 to your computer
9. Resolver caches the answer for 3600 secondsThis entire chain typically completes in under 50ms because the recursive resolver caches aggressively. Most DNS lookups hit cache and never reach the root servers.
Recursive vs Iterative Queries
| Type | Who Does the Work | Who Caches |
|---|---|---|
| Recursive | Resolver resolves everything | Resolver caches the final answer |
| Iterative | Client follows each referral | Each server caches what it learned |
Your computer makes a recursive query to the resolver -- it asks and waits for the final answer. The resolver makes iterative queries to the hierarchy -- it asks each server and follows referrals. This is a fundamental design choice: clients are simple, resolvers do the heavy lifting.
Caching and TTL
Every DNS record has a Time-To-Live (TTL) that tells resolvers how long to cache it. Short TTLs (60-300 seconds) allow fast changes. Long TTLs (3600-86400 seconds) reduce DNS traffic but slow propagation.
# See TTL in the answer
dig example.com
# Force fresh query (bypass cache) by querying authoritative server directly
dig @ns1.example.com example.com
# Check TTL for specific record type
dig AAAA example.com
dig MX example.comIn the dig output, look for the TTL field (the number after the record in the ANSWER section). Lower TTL means the record expires faster from cache.
Before a DNS migration, lower your TTL to 60-300 seconds at least 24-48 hours in advance. This ensures that by the time you change the record, all caches have expired their old values. After the migration, raise the TTL back up.
Negative Caching
DNS also caches negative results -- when a domain does not exist (NXDOMAIN). The SOA record minimum TTL field controls how long negative answers are cached. This prevents DNS servers from being overwhelmed by queries for non-existent domains.
# Query a non-existent domain
dig this-does-not-exist.example.com
# You get NXDOMAIN with a TTL
# The resolver caches this NXDOMAIN for the SOA minimum TTL
# Check negative caching TTL
dig example.com SOAThe minimum field in the SOA record sets the negative caching TTL. If a domain returns NXDOMAIN, resolvers cache that result for the minimum TTL period before trying again.
If you accidentally create a DNS record then delete it, clients that looked up the old record may have cached the NXDOMAIN response. They will not see the new record until the negative cache expires. This causes confusing intermittent failures.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.