The Full DNS Resolution Process — How Many Hops from Browser to Root Server?

1. The Complete 8-Step Flow

┌─────────────────────────────────────────────────────────────┐
│  Browser (Chrome / Firefox) — type google.com                │
└────────────────┬────────────────────────────────────────────┘
                 │ ① Browser DNS cache (Chrome ~60s)
                 ↓ miss
┌─────────────────────────────────────────────────────────────┐
│  OS stub resolver + system DNS cache                          │
└────────────────┬────────────────────────────────────────────┘
                 │ ② System cache miss → sends a UDP query to the router
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Home router DNS forwarding + router cache                    │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ Router cache miss → forwards to the ISP recursive resolver
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ISP / public recursive resolver (1.1.1.1 / 8.8.8.8 / 223.5.5.5) │
│  Cache hit: returns directly, whole process takes 1-5ms        │
│  Cache miss: falls through to the "full lookup" flow below     │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ Asks the root NS "where is google.com?"
                 ↓
        13 clusters of root nameservers (a~m.root-servers.net)
                 │ ⑤ Replies "I don't know, ask .com's NS: a.gtld-servers.net"
                 ↓
        .com TLD authoritative servers (Verisign)
                 │ ⑥ Replies "I don't have it all either, ask google.com's NS: ns1.google.com"
                 ↓
        google.com authoritative servers (operated by Google itself)
                 │ ⑦ Replies "google.com's A record = 142.250.x.x"
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ The recursive resolver caches the answer (per TTL) and     │
│     returns it to the client — every layer along the way      │
│     caches its own copy too                                   │
└─────────────────────────────────────────────────────────────┘

Key insight: in real-world scenarios, the full 8-step flow almost never happens. The IP addresses of major sites are almost always sitting in the recursive resolver's cache, so ordinary users only get as far as step ④ before getting a response. Only obscure domains, rarely visited sites, expired TTLs, or newly registered domains trigger the complete flow.

2. The 5 Layers of DNS Caching Explained

When DNS was designed in 1983, it already accounted for one fact: lookups outnumber changes by a factor of 100,000. That's why caching is everywhere, with each layer holding data for a TTL (Time To Live) period.

3. Recursive vs. Iterative Queries — Key Concepts

3.1 Recursive

The client (browser / OS stub) tells the ISP's recursive resolver: "Find google.com's IP for me — I don't care how you do it." The recursive resolver must complete the entire lookup and return the final result.

3.2 Iterative

When the recursive resolver talks to the root, TLD, and authoritative servers, that exchange is iterative — it asks the root, the root says "ask .com", it goes and asks .com, .com says "ask google", it goes and asks google. Each step only crosses one hop — it's not a case of "I ask the root and the root handles everything for me."

4. Test It Yourself — dig +trace

dig +trace forces a full iterative lookup and shows every step:

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

; ① Hop 1 — query the root (.)
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (13 root NS records)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

; ② Hop 2 — query the .io TLD
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (the 4 NS for .io)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

; ③ Hop 3 — query cleanip.io's authoritative servers
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

; ④ Finally get the answer
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

Breaking it down:

• The whole process took 5 + 121 + 53 + 12 = 191 ms — the first cold lookup really is slow
• But querying the same domain a second later only takes 1-2 ms, because the ISP's recursive cache already has it (TTL 300 seconds)
• 104.21.x.x / 172.67.x.x are Cloudflare CDN addresses — our site's real origin IP is hidden behind the CDN

5. TTL Explained — How Long Does Caching Actually Last

TTL (Time To Live) is the field where the authoritative server tells every recursive resolver "you may cache this for at most this long", measured in seconds.

Note: TTL is the "maximum cache time" — individual resolvers can clear their cache early, but they can never extend it. So even if the authoritative TTL is 1 hour, some resolvers may re-query after just 10 minutes.

Gotcha: Before switching IPs, shorten the TTL first (1-5 minutes) and wait for the old TTL to fully expire before cutting over — otherwise some users will keep hitting the old IP for over an hour.

6. DNS Record Types Cheat Sheet

7. DNS Optimization — How to Make Resolution Faster

7.1 Pick a Nearby Recursive Resolver

Mainland China: 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod) resolve domestic sites fastest. Elsewhere: 1.1.1.1 (Cloudflare, the widest anycast footprint) / 8.8.8.8 (Google). Seepublic DNS resolver directory.

7.2 Enable DoH (DNS-over-HTTPS)

Encrypting DNS queries over HTTPS keeps ISPs from seeing or tampering with them (blocking NXDOMAIN hijacking). Chrome, Firefox, and Edge all support it — just enable it in settings.

7.3 Warm Up Ahead of Time (DNS Prefetch)

Add <link rel="dns-prefetch" href="//api.example.com"> to your site's <head> so the browser resolves it while idle — by the time the real request happens, it's a cache hit.

7.4 Use a CDN + Anycast NS

Put your authoritative NS on Anycast (Cloudflare / Route 53) so users worldwide reach the nearest instance — cutting step ③'s latency from 100ms down to 10ms.

7.5 Set TTL Sensibly

Set a long TTL (1-7 days) for records that rarely change (NS / MX); set a short TTL (5-60 minutes) for A records that might need to switch.

8. Frequently Asked Questions

8.1 I Changed My DNS but Nothing Happened — Why?

First, think about the current TTL. After changing DNS, every recursive resolver will keep returning the old IP until the old TTL expires. "Global propagation" generally takes about 2× the TTL (to account for resolvers being out of sync with each other).

• Client: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• Waiting for a public recursive resolver's cache to expire: 1.1.1.1 / 8.8.8.8 each offer their own "purge" tool for manually clearing it

8.2 Some Users Can Access It, Others Can't — DNS Pollution

Common when accessing overseas sites from mainland China — the GFW injects fake DNS responses / ISPs hijack queries. Switching to DoH (encrypted browser DNS) can bypass most DNS pollution.

8.3 How Long After Registering a Domain Can I Use It?

After registration, the TLD registry pushes your NS records up to the top-level authoritative servers for .com / .net and so on — usually 15 minutes to 24 hours. .cn / .com.cn domains may require ICP filing before they resolve within mainland China.