How DNS Resolves Names to IP Addresses

DNS (Domain Name System) is the internet’s address book. When you type example.com, something has to convert that to 93.184.216.34 before any packet can be sent. That something is DNS — and it’s a beautifully distributed hierarchy that resolves billions of queries per second worldwide.

The full resolution path

You type "www.example.com" in browser
                    ↓
1. Browser cache    (already cached? done.)
                    ↓
2. OS cache         (cached? done.)
                    ↓
3. Stub resolver    (your machine asks the configured DNS server)
                    ↓
4. Recursive resolver  (e.g. 1.1.1.1, 8.8.8.8, your ISP)
                    ↓
5. Recursive resolver asks ROOT servers
                    ↓ "Try the .com TLD servers"
6. Recursive resolver asks .com TLD servers
                    ↓ "Try example.com's authoritative servers"
7. Recursive resolver asks AUTHORITATIVE servers
                    ↓ "www.example.com is at 93.184.216.34"
8. Recursive resolver caches the answer + returns to you

The 4 player types

1. Stub resolver (your laptop)

The DNS client built into your OS. It has a tiny cache and forwards everything to the recursive resolver configured in /etc/resolv.conf (Linux) or your DHCP-supplied DNS server.

2. Recursive resolver

The server that does the actual heavy lifting — walking the DNS tree to find the answer. Your ISP runs one. Public ones include 1.1.1.1 (Cloudflare), 8.8.8.8 (Google), 9.9.9.9 (Quad9).

3. Root servers (13 logical, hundreds physical)

The 13 root server “letters” (a.root-servers.net through m.root-servers.net) know where the TLD servers are. They’re hosted by IANA via Anycast — there are actually hundreds of physical instances.

4. TLD servers

Run by registries. Verisign runs .com and .net. Each TLD knows the authoritative servers for every domain registered under it.

5. Authoritative servers

The DNS servers configured by the domain owner. They have the final word on what records exist for that domain. Your domain registrar usually provides these (or you can run your own).

Recursive vs iterative queries

• Recursive — you ask once, you get a final answer. Used between client and recursive resolver.
• Iterative — you ask, you get a referral (“ask this other server”). Used between recursive resolver and root/TLD/authoritative servers.

Caching is everywhere

If every query had to go all the way to the authoritative server, DNS wouldn’t scale. So everyone caches:

• Browsers cache (~60 seconds typically)
• OS resolver cache
• Recursive resolver cache (hours, controlled by TTL)
• CDN edge caches

This is why DNS changes take time to “propagate” — they have to wait for caches to expire.

Watch DNS happen

# Default lookup
dig example.com

# Show every step (the "trace")
dig +trace example.com

# Force a specific resolver
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

# Just the IP, please
dig +short example.com

# Reverse lookup (IP → name)
dig -x 93.184.216.34

# What does my machine use as resolver?
cat /etc/resolv.conf      # Linux
scutil --dns              # macOS
ipconfig /all             # Windows

The two transport protocols

DNS uses UDP for queries (fast, small) and TCP for responses larger than 512 bytes (zone transfers, DNSSEC). Modern DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) use TCP for privacy.

Common things to debug

“DNS_PROBE_FINISHED_NXDOMAIN”

The domain doesn’t exist according to the authoritative server. Check spelling. Check it’s actually registered.

“Site loads on phone but not laptop”

Different DNS resolver caches. Flush yours: sudo systemd-resolve --flush-caches (Linux) or change DNS in your network settings.

“Just changed my A record but old IP still resolves”

TTL hasn’t expired yet. Wait. Or temporarily lower TTL before making changes.

What to learn next

DNS record types — A, AAAA, MX, TXT, CNAME, NS — what each one does. Up next.