TTL (Time to Live)
A value in an IP packet or a DNS record that tells the network how long to keep the data before discarding or refreshing it.
Detailed Explanation
In DNS, a TTL of 3600 means resolvers should cache the IP address for one hour. A short TTL allows for fast updates but increases server load. In networking, the TTL field in an IP packet prevents it from looping forever, each router it passes through decrements the TTL by 1; if it hits 0, the packet is dropped.
Quick Summary
TTL is the lifetime stamped on cached or in-flight data , in DNS it limits how long a record is cached, in IP packets it prevents infinite loops. "How long is this true for?" is the core question TTL answers.
Key Takeaways
- DNS TTL: seconds a resolver may cache a record before refreshing. Common values: 60s (agile) to 86400s (stable).
- IP TTL: hop limit. Decremented at each router; reaching 0 drops the packet and triggers traceroute's ICMP responses.
- CDN cache TTL: how long the edge serves a cached response before revalidating.
- Lower TTL bounds the worst-case lag on changes but increases lookups; pick by how often the value really changes.
- Lower TTLs before known migrations; raise them again afterwards for headroom.
When to use it
- DNS migration planning: drop TTL to 60s for a week before flipping records.
- CDN cache invalidation strategies: short TTL + revalidation vs. long TTL + explicit purge.
- Distributed caches (Redis, Memcached): expiry policies for keys.
- Traceroute: each hop response is generated by a packet hitting TTL=0 at that hop.
Common Mistakes
- Forgetting to lower TTL before a migration, then waiting a full day for changes to propagate.
- Cache TTL longer than the data's actual validity, leading to stale-for-too-long bugs.
- Treating browser cache TTL and CDN cache TTL as the same thing , they're separate layers with separate headers.
- Setting application cache TTL without a strategy for changes, so updates take an unknown time to appear.
TTL (Time to Live), Frequently Asked
What's a sensible DNS TTL?
For stable records (apex A, NS): 3600–86400. For records you change occasionally: 300–600. During an active migration: 60s, then raise again once stable.
Does the client always honor TTL?
Mostly, but not strictly. OS resolvers cap caching; some browsers cache more aggressively than the DNS TTL says; some intermediate resolvers ignore short TTLs to reduce load. Don't bet on sub-60s changes propagating reliably.