LinkedIn Hook

You type google.com into your browser.

Before a single byte of HTML arrives, your computer runs a 7-step investigation across a globally distributed system — all in under 50 milliseconds.

Most engineers know "DNS converts domain names to IPs."

Fewer can explain what actually happens:

Why your browser might have a different answer than your OS

Why changing your DNS record doesn't take effect instantly everywhere

Why there are only 13 root server "addresses" — but hundreds of physical machines

Why your ISP's DNS server knows the answer for google.com even though it's not Google

DNS resolution is a perfect distributed systems problem — hierarchy, caching, TTLs, and graceful fallback — compressed into one invisible network call.

If you've ever been in a system design interview and said "then DNS resolves the hostname" — you owe it to yourself to know what that actually means.

Read the full lesson → [link]

#Networking #DNS #SystemDesign #BackendEngineering #InterviewPrep #WebDevelopment

DNS Resolution thumbnail

What You'll Learn

The analogy that makes DNS resolution instantly intuitive
Every step in the DNS resolution journey, from browser cache to authoritative nameserver
The difference between recursive and iterative queries — and which one your client actually makes
How DNS caching works, what TTL means, and why it controls how fast DNS changes propagate
What negative caching (NXDOMAIN) is and why it matters
How to inspect DNS cache on Linux, macOS, and Windows
Why the hosts file overrides DNS entirely and how engineers exploit this

The Analogy: Asking for Directions

Imagine you are new in town and need to find "Google's office."

You ask a friend (your recursive resolver). Your friend doesn't know the address personally, but they are willing to do the legwork for you.

Your friend calls city hall (the root server). City hall doesn't know the exact address either, but says: "We don't track individual offices — try the Department of Commerce Buildings (the .com TLD server). They handle all commercial addresses."

Your friend calls the Department of Commerce Buildings. They say: "We don't have the exact office number, but Google registered their building here. Their building manager (Google's authoritative nameserver) will know. Call them."

Your friend calls Google's building manager. The building manager looks up a ledger (the DNS zone file) and says: "Google's office is at 142.250.80.46."

Your friend brings the answer back to you, writes it in their notebook so they don't have to ask again for a while (cache), and you walk to the address.

That is DNS resolution in one paragraph. Now let's go step by step through what actually happens when you type google.com into your browser.

The Full DNS Resolution Journey

You type: google.com

  [Browser Cache]
       |
       | (miss)
       v
  [OS Cache + /etc/hosts]
       |
       | (miss)
       v
  [Recursive Resolver]  <--- your ISP's DNS, 8.8.8.8, or 1.1.1.1
       |
       | (cache miss — starts iterative lookups)
       |
       +-----> [Root Server]  (a–m.root-servers.net)
       |            |
       |            | "Try the .com TLD server"
       |            v
       +-----> [.com TLD Server]
       |            |
       |            | "Try ns1.google.com"
       |            v
       +-----> [Authoritative Nameserver]  (ns1.google.com)
                    |
                    | "google.com = 142.250.80.46"
                    v
  [Recursive Resolver] --- caches result for TTL seconds
       |
       v
  [OS] --- caches result
       |
       v
  [Browser] --- caches result
       |
       v
  TCP connection to 142.250.80.46:443

Step 1 — Browser Cache

The journey starts before any network call is made. Your browser maintains its own internal DNS cache. If you visited google.com recently and the cached entry hasn't expired, the browser uses that IP directly — no OS call, no network, nothing.

Every cached entry has an expiration time driven by the record's TTL (Time to Live). Once the TTL expires, the browser discards the entry and the resolution process begins again.

Inspecting Chrome's DNS cache:

chrome://net-internals/#dns

You can see all currently cached hostnames, their resolved IPs, and TTLs. There's also a "Clear host cache" button — useful when debugging stale DNS entries during development.

Firefox has a similar internal cache, though it doesn't expose a UI for it. Safari respects the OS cache more aggressively than Chromium-based browsers.

Key point: The browser cache is independent of the OS cache. You can flush the OS cache and the browser may still have a valid entry — and vice versa. This surprises many engineers when a DNS change "works on one browser but not another."

Step 2 — OS Cache (and the Hosts File)

If the browser has no cached answer, it asks the operating system to resolve the name. The OS has its own DNS cache — maintained by a system service.

Before checking its cache, the OS checks the hosts file — a plain text file that maps hostnames to IP addresses directly. Entries in the hosts file bypass DNS entirely. The OS never makes a network query for any hostname listed there.

Platform	Hosts File Path
Linux / macOS	`/etc/hosts`
Windows	`C:\Windows\System32\drivers\etc\hosts`

Example hosts file entry:

# /etc/hosts
127.0.0.1   localhost
::1         localhost

# Block ads
0.0.0.0     ads.example.com

# Point a domain to a local dev server
127.0.0.1   myapp.local
192.168.1.10 staging.myapp.com

Engineers use the hosts file to:

Route a production domain to a local development server (without changing DNS)
Block domains by pointing them to 0.0.0.0 (ad blockers, parental controls)
Test infrastructure changes before updating DNS records publicly

If the hostname isn't in the hosts file, the OS checks its own DNS cache (managed by nscd, systemd-resolved, dnsmasq, or the Windows DNS Client service depending on the OS).

Checking and flushing the OS DNS cache:

# macOS (Big Sur and later)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Ubuntu with systemd-resolved
resolvectl flush-caches
# or
sudo systemd-resolve --flush-caches

# Ubuntu with nscd
sudo service nscd restart

# Windows (PowerShell or Command Prompt)
ipconfig /flushdns
ipconfig /displaydns   # view current OS DNS cache

Step 3 — Recursive Resolver

If neither the browser cache, the hosts file, nor the OS cache has an answer, the OS sends a DNS query to the recursive resolver — the DNS server configured for your network connection.

This resolver is typically:

Your ISP's DNS server (assigned automatically via DHCP)
A public DNS server you've configured manually: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9)

Checking your configured DNS resolver:

# Linux (systemd-resolved)
resolvectl status
# or
cat /etc/resolv.conf

# macOS
scutil --dns | head -20
# or
cat /etc/resolv.conf

# Windows
ipconfig /all | findstr "DNS Servers"

The resolver first checks its own cache. Resolvers like Google's 8.8.8.8 serve millions of clients — google.com is almost certainly already cached. The cached result is returned immediately, and the journey ends here for popular domains.

If the resolver has no cached answer, it begins the iterative lookup process — doing the legwork on your behalf so your OS doesn't have to talk to multiple servers directly.

Step 4 — Root Server

The recursive resolver's first call goes to one of the root servers — the top of the DNS hierarchy.

There are exactly 13 root server names (labeled a through m):

a.root-servers.net  through  m.root-servers.net

But these 13 names represent hundreds of physical machines spread across the globe, operated by 12 different organizations (ICANN, Verisign, NASA, the US Army, Cogent, etc.). Any given DNS query reaches the geographically closest physical machine via anycast routing — the same IP routes to multiple machines, and the network delivers traffic to the nearest one automatically.

The root server does not know google.com's IP address. It knows only one thing: which TLD nameservers handle .com. It responds with a referral:

;; AUTHORITY SECTION:
com.    172800  IN  NS  a.gtld-servers.net.
com.    172800  IN  NS  b.gtld-servers.net.
...

"I can't answer your question, but these servers can help you with .com."

Why only 13 root server names?

DNS responses were originally designed to fit in a 512-byte UDP packet. 13 IPv4 addresses fit comfortably within that constraint. With EDNS0 extensions and TCP fallback, this limit is less relevant today — but the 13-name design remains.

Step 5 — TLD Server

The recursive resolver now queries one of the .com TLD nameservers (operated by Verisign for .com and .net).

The TLD server holds delegation records — it knows which nameservers are authoritative for every registered .com domain. It does not store the actual DNS records (like IP addresses) for those domains.

For google.com, the TLD server responds with:

;; AUTHORITY SECTION:
google.com.   172800  IN  NS  ns1.google.com.
google.com.   172800  IN  NS  ns2.google.com.
google.com.   172800  IN  NS  ns3.google.com.
google.com.   172800  IN  NS  ns4.google.com.

"I don't have the IP, but Google's own nameservers do. Try them."

The glue record problem: Notice that ns1.google.com is itself under the google.com zone. To resolve ns1.google.com, you'd need to ask the google.com authoritative nameserver — but you can't reach that without resolving ns1.google.com first. Circular dependency. TLD servers solve this with glue records — they include the IP addresses of the nameservers directly in the referral response, breaking the loop.

Step 6 — Authoritative Nameserver

The recursive resolver queries one of Google's authoritative nameservers (e.g., ns1.google.com).

This server is the final authority for google.com. It holds the actual DNS zone file — the source of truth containing all records for the domain: A records, AAAA records, MX records, CNAME records, TXT records, and more.

The resolver asks: "What is the IP address for google.com?"

The authoritative nameserver responds with the A record:

google.com.   300  IN  A  142.250.80.46

Broken down:

google.com. — the queried name
300 — TTL in seconds (5 minutes)
IN — Internet class (always IN for practical purposes)
A — record type (IPv4 address)
142.250.80.46 — the answer

This is the only server in the entire chain that says "yes, I know the definitive answer." All previous servers only knew who to ask next.

Querying DNS from the command line:

# Query the default resolver
dig google.com

# Specify a nameserver to query
dig @8.8.8.8 google.com

# Query the authoritative nameserver directly
dig @ns1.google.com google.com

# Trace the full resolution chain step by step
dig +trace google.com

# See all records for a domain
dig google.com ANY

# Query a specific record type
dig google.com MX
dig google.com AAAA
dig google.com TXT

The dig +trace output shows exactly what this lesson describes — the resolver querying root, then TLD, then authoritative nameserver, with each referral displayed.

Step 7 — The Response Travels Back

The authoritative nameserver's answer flows back up the chain:

Authoritative nameserver → Recursive resolver: The resolver receives 142.250.80.46 with a TTL of 300 seconds. It caches this answer. Any subsequent client asking for google.com within the next 5 minutes gets the cached answer without going through the whole chain again.
Recursive resolver → OS: The resolver returns the IP to the OS. The OS caches it in its own DNS cache.
OS → Browser: The OS returns the IP to the browser process. The browser caches it.
Browser → Server: The browser now opens a TCP connection (or QUIC for HTTP/3) to 142.250.80.46 on port 443, completes the TLS handshake, and sends the HTTP request.

All 7 steps — for a name that isn't cached anywhere — typically complete in 20–120 milliseconds, depending on network latency to the servers. For well-cached names, steps 3–6 are skipped entirely and the answer comes from local cache in under 1 millisecond.

Recursive vs Iterative Queries

These terms describe who does the work of contacting each nameserver in the chain.

Recursive Query

A recursive query says: "Find the answer for me. I don't want referrals — I want the final IP."

Your client (OS) sends a recursive query to the recursive resolver. The resolver takes responsibility for doing all the legwork. Your OS sends one query and gets one answer. It doesn't talk to root servers or TLD servers — the resolver handles all of that.

This is why it's called a "recursive" resolver — it recursively resolves the query on your behalf.

Client ——[recursive query]——> Recursive Resolver
Client <——[final answer]——————— Recursive Resolver

Iterative Query

An iterative query says: "Tell me what you know. If you don't have the full answer, tell me who to ask next."

The recursive resolver sends iterative queries to each nameserver in the chain. Each server either answers or returns a referral. The resolver follows the referral chain itself — iterating through root, TLD, and authoritative nameservers.

Resolver ——[query]——> Root Server
Resolver <——[referral: ask TLD]——— Root Server

Resolver ——[query]——> TLD Server
Resolver <——[referral: ask Auth NS]——— TLD Server

Resolver ——[query]——> Authoritative NS
Resolver <——[answer: 142.250.80.46]——— Authoritative NS

Summary: Your client makes a recursive query. The resolver makes iterative queries. This separation is what allows the DNS system to scale — clients stay simple, resolvers do the heavy lifting, and nameservers only need to answer for their own zone.

DNS Caching and TTL

Every DNS response includes a TTL (Time to Live) value — a number in seconds that tells the recipient how long to cache the record before discarding it and fetching a fresh copy.

TTL is set by the domain owner in their DNS zone configuration. It represents a deliberate tradeoff:

TTL	Duration	Tradeoff
`60`	1 minute	Fast propagation of changes. High DNS query volume — every minute, every resolver re-queries.
`300`	5 minutes	Good balance for frequently-updated records.
`3600`	1 hour	Standard for most A records. Lower query volume. Slower propagation.
`86400`	24 hours	For stable records (rarely changing infrastructure). Very low query volume. Slow propagation — changes take up to a day to reach all resolvers.

How TTL Affects You Practically

When you update a DNS record — say, you point mysite.com to a new IP after migrating servers — the change doesn't instantly appear everywhere. Here's why:

Every resolver that cached the old record retains it until its local TTL counter reaches zero
The TTL countdown starts when the resolver first caches the record, not when you make the change
Different resolvers cached the record at different times — they expire at different times
A resolver that cached the record 1 minute ago with a 3600s TTL will hold the old IP for another 59 minutes

Best practice: Before a planned migration, lower your TTL to 300s or less a day in advance (giving time for the old high-TTL record to expire everywhere). After the migration is confirmed, raise the TTL back.

Caching at Each Layer

Layer	Cache Location	Controlled By
Browser	In-memory browser cache	Browser internals
OS	System DNS cache (nscd, systemd-resolved, Windows DNS Client)	OS service
Recursive Resolver	Resolver's cache (may serve millions of clients)	Resolver operator
Authoritative Nameserver	No caching — it IS the source of truth	Domain owner

Negative Caching (NXDOMAIN)

What happens when you query a domain that doesn't exist?

The authoritative nameserver returns an NXDOMAIN response ("Non-Existent Domain"). The resolver doesn't throw this away — it caches the negative result too.

Why? Because someone typing gmial.com (typo for gmail.com) shouldn't cause the resolver to hammer the root server with repeated queries every time they retry. The NXDOMAIN is cached for a short period — typically defined by the SOA record's negative TTL (often 300–900 seconds).

What this means for developers:

If you query a domain that doesn't exist yet, then create it, your resolver may still return NXDOMAIN for a few minutes even after the record is live
Flushing your local DNS cache forces a fresh lookup and bypasses the cached NXDOMAIN

# Checking NXDOMAIN behavior
dig nonexistent-domain-xyz123.com
# Response will show:
# status: NXDOMAIN
# SOA record with negative TTL

Common Mistakes

Thinking DNS is one big centralized database. DNS is explicitly designed to be hierarchical and distributed. There is no single server that knows every domain name. The hierarchy (root → TLD → authoritative) exists specifically so that no single point of failure or single organization controls the entire system. Thousands of authoritative nameservers worldwide each hold authority for their own zones only.
Not understanding why DNS changes don't take effect immediately. When you update a DNS record, your registrar updates the authoritative nameserver instantly. But every resolver that previously cached the old record continues serving that cached value until the TTL expires. If your TTL was 86400 (24 hours), old records can persist for up to 24 hours across different resolvers worldwide. This is not a bug — it is the caching system working as designed. The fix is to set a low TTL before planned changes.
Confusing the recursive resolver with the authoritative nameserver. The recursive resolver (8.8.8.8, 1.1.1.1, your ISP's DNS) is a middleman — it asks questions on your behalf, caches the answers, but holds no authoritative data of its own. The authoritative nameserver is the source of truth — it holds the actual zone file configured by the domain owner. When you "change your DNS settings" at a domain registrar or hosting provider, you are updating the authoritative nameserver's records. The recursive resolver only knows what the authoritative nameserver tells it.

Interview Questions

1. Walk me through what happens when you type google.com in the browser (DNS part only).

Strong answer structure: Browser cache check → OS cache + hosts file check → recursive resolver query → resolver cache check → if cache miss: iterative queries to root server (returns .com TLD referral) → .com TLD server (returns Google's NS referral) → Google's authoritative nameserver (returns A record with IP) → resolver caches result → OS caches → browser caches → TCP connection begins. Mention TTL at each caching layer.

2. What is the difference between a recursive resolver and an authoritative nameserver?

A recursive resolver is a middleman that resolves queries on behalf of clients. It caches results but holds no authoritative data. A client sends one query and gets one answer — the resolver handles all the intermediate queries. An authoritative nameserver is the source of truth for a specific DNS zone. It holds the actual DNS records (A, MX, CNAME, etc.) configured by the domain owner. It does not recursively resolve — it only answers queries about its own zone.

3. What is the role of the root server in DNS resolution?

Root servers sit at the top of the DNS hierarchy. They don't store records for individual domains — they store delegation information pointing to TLD nameservers. When a resolver has no cached answer and no idea where to start, it queries a root server, which responds with a referral to the appropriate TLD server (e.g., ".com servers are here"). There are 13 root server names (a–m.root-servers.net), backed by hundreds of physical machines worldwide via anycast, operated by 12 different organizations. Root servers rarely receive direct traffic in practice — most queries are resolved from resolver caches before reaching the root.

4. What is TTL in DNS and why does it matter?

TTL (Time to Live) is the number of seconds a DNS record can be cached before the caching entity must discard it and perform a fresh lookup. Domain owners set TTL on their records. High TTL (86400s) means lower query volume but slow propagation of changes — old records can persist in caches for up to 24 hours. Low TTL (300s) means fast propagation of changes but higher DNS query volume. TTL matters operationally because it determines how long it takes for a DNS change (like a server migration or failover) to reach all clients globally. Best practice: lower TTL before planned changes, raise it afterward.

5. What is the /etc/hosts file and how does it relate to DNS?

/etc/hosts (Linux/macOS) or C:\Windows\System32\drivers\etc\hosts (Windows) is a static file mapping hostnames to IP addresses. The OS checks this file before making any DNS query. If a hostname is found in the hosts file, that IP is used directly — DNS is bypassed entirely. This makes the hosts file useful for local development (routing a production domain to localhost), blocking domains (pointing them to 0.0.0.0), and testing DNS changes before they go live. It's also a historical artifact — before DNS, the entire internet's host-to-address mapping was maintained in a single hosts file distributed manually.

Quick Reference — Cheat Sheet

DNS Resolution Chain (7 Steps)

1. Browser Cache
   └─ Check local browser DNS cache (TTL-based)
   └─ HIT: use cached IP → done
   └─ MISS: go to step 2

2. OS Cache + Hosts File
   └─ Check /etc/hosts (overrides DNS entirely)
   └─ Check OS DNS cache (nscd / systemd-resolved / Windows DNS Client)
   └─ HIT: use cached IP → done
   └─ MISS: go to step 3

3. Recursive Resolver (ISP DNS / 8.8.8.8 / 1.1.1.1)
   └─ OS sends query to configured DNS server
   └─ Resolver checks its own cache
   └─ HIT: return cached IP → done
   └─ MISS: begin iterative lookup

4. Root Server (a–m.root-servers.net)
   └─ Resolver queries nearest root server (anycast)
   └─ Root returns referral to TLD nameserver
   └─ e.g., "ask the .com TLD servers"

5. TLD Server (.com → a.gtld-servers.net, etc.)
   └─ Resolver queries TLD nameserver
   └─ TLD returns referral to authoritative nameserver
   └─ e.g., "ask ns1.google.com"
   └─ Includes glue records (NS IP addresses) to avoid circular lookups

6. Authoritative Nameserver (ns1.google.com, etc.)
   └─ Resolver queries domain's authoritative nameserver
   └─ Auth NS returns actual A record from zone file
   └─ e.g., google.com → 142.250.80.46 (TTL: 300)

7. Response Travels Back
   └─ Resolver caches result for TTL seconds
   └─ Returns IP to OS
   └─ OS caches result
   └─ Returns IP to browser
   └─ Browser caches result
   └─ TCP connection opens to 142.250.80.46:443

ASCII Flow Diagram

  [Client Browser]
        |
        | 1. Check browser cache
        |    MISS
        v
  [Operating System]
        |
        | 2. Check /etc/hosts + OS cache
        |    MISS
        v
  [Recursive Resolver]  ←── (8.8.8.8 / 1.1.1.1 / ISP DNS)
        |
        | 3. Check resolver cache
        |    MISS — begin iterative lookups
        |
        +──────────────────────────────────────────+
        |                                          |
        | Query                              Referral
        v                                          |
  [Root Server]  ──────────────────────────────────+
  a-m.root-servers.net     "Ask .com TLD servers"
        |
        +──────────────────────────────────────────+
        |                                          |
        | Query                              Referral
        v                                          |
  [.com TLD Server]  ──────────────────────────────+
  a.gtld-servers.net       "Ask ns1.google.com"
        |
        +──────────────────────────────────────────+
        |                                          |
        | Query                              A record
        v                                          |
  [Authoritative NS]  ─────────────────────────────+
  ns1.google.com           "google.com = 142.250.80.46 (TTL 300)"
        |
        v
  [Recursive Resolver] — caches result for 300s
        |
        v
  [OS] — caches result
        |
        v
  [Browser] — caches result
        |
        v
  TCP → 142.250.80.46:443

Key Concepts at a Glance

Concept	Definition
Recursive Resolver	Middleman DNS server that resolves queries on client's behalf. Caches results.
Authoritative Nameserver	Holds the actual DNS zone file. Source of truth for a domain.
Root Server	Top of DNS hierarchy. Returns referrals to TLD servers. 13 names, hundreds of machines.
TLD Server	Handles top-level domains (.com, .org, .net). Returns referrals to authoritative NS.
TTL	Time to Live — seconds a cached DNS record remains valid.
NXDOMAIN	Response when a domain does not exist. Also cached (negative caching).
Hosts File	Static file that overrides DNS. Checked before any DNS query.
Anycast	Routing technique where one IP reaches multiple physical machines; nearest one responds.
Glue Record	IP address of a nameserver included directly in a referral to break circular lookups.
Recursive Query	Client asks resolver for final answer; resolver does all iterative work.
Iterative Query	Resolver asks each server in turn; each returns an answer or referral.

Common DNS CLI Commands

# Resolve a domain (default resolver)
dig google.com

# Use a specific resolver
dig @1.1.1.1 google.com

# Trace the full resolution chain
dig +trace google.com

# Query specific record types
dig google.com A         # IPv4
dig google.com AAAA      # IPv6
dig google.com MX        # Mail
dig google.com TXT       # Text (SPF, DKIM, etc.)

# Flush DNS cache
# macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux (systemd-resolved):
resolvectl flush-caches
# Windows:
ipconfig /flushdns

Previous: Lesson 6.1 — What is DNS? (01-what-is-dns.md) Next: Lesson 6.3 — DNS Record Types (03-dns-record-types.md)

This is Lesson 6.2 of the Networking Interview Prep Course — 8 chapters, 32 lessons.

DNS Resolution