DNS Caching and TTL Explained

“I changed my A record an hour ago but my site still loads from the old IP.” Welcome to DNS caching. Without it, every page load would have to walk the entire DNS hierarchy from root servers down. With it, changes can take hours to fully propagate. The trade-off is fundamental.

What TTL is

TTL (Time To Live) is the number of seconds a DNS record can be cached before being considered stale. It’s set per record by the authoritative DNS server.

example.com.    300   IN   A   93.184.216.34
                ↑
              TTL in seconds (5 minutes here)

Every cache (browser, OS, recursive resolver) is supposed to honor this TTL. Most do.

Where DNS gets cached

Layer	Where	Cache time
Browser	Chrome, Firefox internal	~60 seconds
OS resolver	systemd-resolved, mDNSResponder	Honors TTL
Recursive resolver	1.1.1.1, ISP DNS	Honors TTL
Authoritative server	Your DNS provider	N/A — source of truth

Why “DNS propagation” is misleading

Nothing actually “propagates” — there’s no push from authoritative to caches. What’s happening: each cache independently expires its old entry and asks the authoritative server fresh. So:

• If your record’s TTL was 3600 seconds (1 hour), some users could see the old value for up to an hour after you change it.
• Some buggy resolvers ignore TTLs and cache for days.
• Some browsers/OSes have minimum cache times that ignore short TTLs.

Choosing the right TTL

Record type	Recommended TTL	Why
Stable A record (your main site)	3600–86400 (1h–1d)	Reduces load on resolvers
CDN / load-balanced	60–300	Need quick failover
MX records	3600+	Email rarely changes infrastructure
NS records	86400+	Almost never changes
Pre-migration (temporary)	60–300	Rapid switch-over needed

The migration playbook

Want to change your A record without breaking users? Plan ahead:

Day 1 — lower TTL

# Change TTL from 3600 to 60 (no other changes)
example.com  A  93.184.216.34  TTL=60

Wait at least the OLD TTL (3600 sec = 1 hour) for caches to flush.

Day 2 — make the actual change

# New IP
example.com  A  198.51.100.5  TTL=60

Caches expire within 60 seconds, users see new IP almost immediately.

Day 3 — restore high TTL

# Back to long TTL after change is stable
example.com  A  198.51.100.5  TTL=3600

Flush caches manually

# Linux (systemd-resolved)
sudo resolvectl flush-caches
sudo systemd-resolve --flush-caches   # older versions

# Linux (nscd)
sudo nscd -i hosts

# Linux (dnsmasq)
sudo killall -HUP dnsmasq

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

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

Negative caching

“This name doesn’t exist” responses (NXDOMAIN) also get cached. The TTL for negative caching comes from the SOA record’s “minimum” field. If you’ve ever created a new subdomain and wondered why dig still says NXDOMAIN, that’s why.

Check what your resolver thinks

# What's the TTL according to YOUR resolver right now?
dig example.com | grep -E "ANSWER|^example"

# What's the actual authoritative TTL?
dig @ns1.example.com example.com

What to learn next

DNSSEC — how DNS responses get cryptographically verified to prevent spoofing. Up next.