DNS Caching and TTL: Balancing Performance and Freshness
How Time to Live values shape resolver behavior, and why tuning them is a genuine engineering trade-off.
Core Concept
TTL (Time to Live) tells resolvers how long they're permitted to cache a DNS record before checking back with the authoritative source.
It exists to balance two competing goals: minimizing load on authoritative nameservers, and keeping the internet's view of a domain reasonably current.
How Caching Reduces Load
Without caching, every single request for a website would trigger a fresh query to the authoritative nameserver, which doesn't scale.
- Recursive resolvers cache per-record based on TTL
- Operating systems maintain their own short-lived cache
- Browsers add an additional caching layer on top
Layered Caching
A single domain lookup can be cached at three or more independent layers simultaneously, each honoring TTL separately.
Choosing TTL Values
Different record types and use cases call for different TTL strategies.
- Stable infrastructure — long TTLs (hours to a day)
- Failover-critical records — short TTLs (60-300s)
- Pre-migration windows — temporarily shortened TTLs
TTL and Failover Systems
Systems that rely on DNS-level failover live or die by their TTL configuration.
A failover record with a long TTL means that even after a health check detects an outage, cached resolvers will keep sending traffic to the dead endpoint until the cache expires.
Failover Speed Limit
TTL sets the absolute floor on how fast DNS-based failover can react — no monitoring system can override a resolver's cached answer.
Common TTL Mistakes
A few recurring patterns cause the majority of TTL-related incidents.
- Forgetting to lower TTL ahead of a planned migration
- Setting TTL too long on records expected to change frequently
- Assuming a TTL change itself propagates instantly
Real-World Implementation
TTL tuning shows up throughout production DNS strategy.
- Health-check-driven failover systems using short TTLs
- Static infrastructure using long TTLs to reduce query costs
- Blue-green deployments temporarily shortening TTL before cutover
Treating TTL as a deliberate engineering parameter, rather than a default left untouched, gives teams real control over how fast their infrastructure can respond to change.
Common Mistakes to Avoid
A few common mistakes around TTL configuration lead to avoidable operational issues.
- Setting a very long TTL on a record expected to change frequently.
- Forgetting that a TTL reduction itself needs time to propagate before a migration.
- Using an extremely short TTL everywhere, unnecessarily increasing load on authoritative servers.
- Assuming a shorter TTL guarantees instant failover regardless of resolver behavior.
- Leaving TTL values at default without considering the specific use case for each record.
- Setting different TTLs across a record's redundant copies inconsistently.
- Overlooking negative caching TTL, which is configured separately from positive record TTL.
- Failing to consider TTL implications for third-party services depending on your DNS records.
- Overlooking that some resolvers cap maximum TTL regardless of the configured value.
- Assuming TTL behaves identically for positive and negative caching scenarios.
- Failing to account for TTL when planning a blue-green deployment cutover.
- Overlooking that CDN-level caching can operate independently of standard DNS TTL settings.
Best Practices Checklist
These practices help teams use TTL deliberately rather than as an afterthought.
- Set TTL based on how often a record is genuinely expected to change.
- Lower TTL well ahead of any planned migration or failover event.
- Reserve very short TTLs for records specifically tied to failover systems.
- Use longer TTLs for stable infrastructure to reduce unnecessary resolver load.
- Review TTL settings periodically rather than leaving them unexamined indefinitely.
- Keep TTL values consistent across redundant record copies to avoid unpredictable behavior.
- Configure negative caching TTL deliberately, separate from standard record TTL.
- Communicate planned TTL or record changes to third-party services that depend on them.
- Check whether resolvers you rely on impose a maximum TTL cap.
- Configure negative caching TTL deliberately, separate from standard positive record TTL.
- Factor TTL directly into blue-green deployment cutover timing.
- Distinguish CDN content caching from DNS record caching, since the two operate independently.
Frequently Asked Questions
Frequently asked questions about DNS TTL and caching.
What TTL should I use for a typical A record?
It depends on how often the record changes — stable infrastructure can use hours or a day, while failover-critical records typically use 60 to 300 seconds.
Does a short TTL guarantee fast failover?
It sets the ceiling for how fast failover can happen, but actual speed also depends on resolvers correctly honoring the TTL rather than caching longer than instructed.
Why does lowering TTL before a migration matter?
It gives caches time to expire on the shorter value ahead of the actual change, rather than being stuck with a long-cached old record during the cutover.
Is there a downside to setting TTL extremely low everywhere?
Yes — it significantly increases query load on authoritative nameservers and can introduce a small amount of additional latency for resolvers.
How long before a migration should TTL be lowered?
A common guideline is 24 to 48 hours, giving existing longer TTLs time to expire before the actual cutover happens.
Is negative caching TTL the same as regular record TTL?
No — it's configured separately via the SOA record's minimum TTL field, controlling how long NXDOMAIN responses are cached.
Can inconsistent TTLs across redundant DNS providers cause problems?
Yes — if redundant providers serve different TTL values for the same record, caching behavior can become unpredictable across different resolvers.
Should third parties be notified before a major TTL or DNS change?
It's a good practice when those third parties have dependencies on your DNS records, helping them adjust their own systems accordingly.
Do some resolvers cap TTL below the configured value?
Yes — certain resolvers impose their own maximum TTL cap, meaning your configured value may not always be fully honored.
Should TTL be considered during a blue-green deployment?
Yes — the cutover timing needs to account for how long old cached records may persist before all traffic reaches the new version.
Is CDN content caching the same as DNS TTL caching?
No — they're separate mechanisms; CDN content caching governs response bodies, while DNS TTL governs how long a resolved IP is cached.
Inspect TTL Values
Run a DNS analysis to see the current TTL configured on every record for a domain.
Launch Tool →