TTL and DNS Caching
The knob between freshness and query volume
TTL decides how long a DNS answer lives in caches. Low TTL = fast changes and failover but more resolver queries and cost; high TTL = snappy, cheap lookups but glacial drift. Tuning it is a risk/performance trade.
What you will learn
- Explain TTL at record and resolver layers
- Trade off low vs high TTL
- Handle negative caching and propagation windows
TTL (seconds) is the answer's shelf life in any resolver cache. Low TTL speeds every change and failover but adds DNS query volume and cost; high TTL slashes queries and latency but makes edits slow to land worldwide.
What is this?
TTL per record (e.g. 60s, 300s, 3600s): resolver caches the answer for ≤ TTL. Negative caching: an NXDOMAIN/servfail also caches (SOA minimum) — new records can be delayed by minutes. Edge cases: multiple cache layers (browser→OS→resolver→ISP/EDNS), network or provider forced lower/higher caps. Cost: Route 53/TM bill per query; the 'free' high TTL cuts query count.
Why do you need it?
- The TTL knob shows up in every migration and incident ('why is DNS still old?').
- Failover speed is bounded by TTL + health-check reaction, not just the record switch.
- Query cost: high TTL on a hot domain can cut millions of queries/month.
- Negative caching decides how fast a new subdomain starts resolving.
Mental model
A bus timetable posted at a stop, rewritten when routes change
TTL
A long-valid timetable (high TTL) stays pinned for weeks — great for commuters, bad the day the route changes. A daily one (low TTL) is current but everyone re-checks it constantly.
How it works
- The authoritative answer includes TTL; each caching layer holds it for at most that long.
- Resolver returns cached answers within TTL with zero upstream traffic.
- After expiry, the resolverer re-queries; a changed record now appears.
- Negative responses cache too — NXDOMAIN linger from SOA minimum (minutes).
- TTL 0 disables caching — used by some for hot-rotation, expensive at scale.
TTL across layers.
Examples
Set and inspect TTL
# Route 53: short TTL recordaws route53 change-resource-record-sets --hosted-zone-id ZONE \ --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{ "Name":"app.example.com","Type":"A","TTL":60, "ResourceRecords":[{"Value":"203.0.113.10"}]}}]}'# inspectdig app.example.com +noall +answerTTL 60 gives a 1-minute propagation target — the standard for failover-sensitive names.
In production
- A failover policy pair holds TTL 60 for quick DR; the rest of the zone 300.
- Mail SPF/TXT records hold higher TTL because they change rarely.
- A load balancer-alias record keeps TTL 60 so an LB change is invisible to traffic.
Best practices
- Use low TTL (30-60s) on records you flip often or that sit in failover policies.
- Rarely-changed SRV/MX OK at 300-3600s.
- Test negative-cache delay before launching new subdomains.
- Count queries: high-traffic zones should favor higher TTL to cut DNS spend.
Common mistakes
- Changing a record and expecting instant global effect — TTL says otherwise.
- A failover record at TTL 3600 falsely 'not working' during an incident.
- Negative caching blocking a new record for the SOA minimum window.
- Zero-TTL records everywhere → resolver load spikes and cost inflation.
Common issues
DNS stuck after editLong TTL + multiple cache layers
Confirm authoritative answer; wait out TTL; lower TTL for future edits.
Failover 'took 20 minutes'High TTL on the failover records
Set 30-60s TTL on all records participating in failover.
Debugging tips
- Check the TTL the resolver actually returns (dig shows it per answer).
- To force freshness: dig @authoritative to see the true record and TTL.
- For the propagation len: three highest TTLs + resolver churn ≈ your window.
- If a new DNS record 'doesn't exist', query NXDOMAIN cache (dig @1.1.1.1 and compare).
Interview checkpoint
Quick quiz
A high TTL makes DNS failover faster.