You type google.com in your browser. Your computer has no idea where that is. It needs an IP address. Here’s how it finds one in about 20 milliseconds.

Step 1: Browser cache

Your browser checks its own DNS cache first. If you visited google.com in the last few minutes, the IP is already cached. Done in microseconds.

Chrome: chrome://net-internals/#dns
Firefox: about:networking#dns

Step 2: OS cache

If the browser doesn’t have it, it asks the operating system. Your OS maintains its own DNS cache.

# macOS: see cached entries
sudo dscacheutil -cachedump

# Windows:
ipconfig /displaydns

# Linux:
systemd-resolve --statistics

Step 3: Router cache

If the OS doesn’t have it, the query goes to your router (usually 192.168.1.1). Most routers cache DNS responses too.

Step 4: ISP’s recursive resolver

If nobody in your local chain has the answer, the query goes to your ISP’s DNS resolver (or whatever you configured — 8.8.8.8 for Google, 1.1.1.1 for Cloudflare).

This is where the real work happens. The recursive resolver’s job is to find the answer by asking a chain of authoritative servers.

Step 5: Root nameservers

The resolver asks one of the 13 root nameserver clusters: “Where is google.com?”

The root server doesn’t know google.com’s IP. But it knows who’s responsible for .com domains:

Response: “I don’t know, but ask the .com TLD servers at these addresses.”

Step 6: TLD nameservers

The resolver asks the .com TLD (Top-Level Domain) server: “Where is google.com?”

The TLD server doesn’t know the IP either. But it knows which nameservers are authoritative for google.com:

Response: “I don’t know, but google.com’s nameservers are ns1.google.com at 216.239.32.10.”

Step 7: Authoritative nameserver

The resolver asks Google’s nameserver: “What’s the IP for google.com?”

Response: “142.250.80.46. TTL: 300 seconds.”

Finally, an actual answer.

Step 8: Response chain

The answer flows back:

1. Google’s nameserver → recursive resolver
2. Recursive resolver caches it (for 300 seconds, per the TTL)
3. Recursive resolver → your OS
4. OS caches it → your browser
5. Browser caches it → makes the HTTP connection to 142.250.80.46

The full journey

Browser cache → miss
OS cache → miss
Router cache → miss
ISP resolver → miss
    ├── Ask root server: "where is .com?" → TLD addresses
    ├── Ask .com TLD: "where is google.com?" → NS addresses
    └── Ask google NS: "IP for google.com?" → 142.250.80.46
Response cached at every level
Browser connects to 142.250.80.46

Total time: 20-100ms for a cold lookup. <1ms for a cached one.

Why TTL matters

TTL (Time To Live) tells caches how long to keep the answer. Google uses 300 seconds (5 minutes). If you’re migrating servers and change your DNS, it can take up to the TTL for everyone to see the new IP.

“It takes 24-48 hours for DNS to propagate” is mostly a myth. It takes as long as the old TTL. If your TTL was 86400 (24 hours), then yes, it takes up to 24 hours. If it was 300, it takes 5 minutes.

Pro tip: lower your TTL to 60 seconds a day before a migration, then change the IP. Propagation in minutes, not hours.

DNS record types

• A: Domain → IPv4 address (google.com → 142.250.80.46)
• AAAA: Domain → IPv6 address
• CNAME: Domain → another domain (www.google.com → google.com)
• MX: Domain → mail server (google.com → smtp.google.com)
• TXT: Arbitrary text (used for email verification, SSL validation)
• NS: Domain → nameserver

The one-sentence summary

DNS is a hierarchical lookup: your browser asks your OS, which asks your router, which asks your ISP, which asks root → TLD → authoritative nameservers, and the answer gets cached at every level on the way back.

Related: What is DNS? · DNS Resolution Failed — fix · How HTTPS Keeps Your Data Safe