DNS TTL
A DNS TTL declares how many seconds a resolver may cache a record, setting the upper bound on how quickly record changes propagate and how much authoritative load you carry.
Definition
TTL is the expiry field of every DNS record. Recursive resolvers serve cached answers until the TTL elapses, then re-query the authoritative server. It therefore fixes a hard trade-off: long TTLs cut query volume and latency but slow failover and migration, while short TTLs enable agility at the cost of resolver traffic.
Context and scope
Tuned when planning IP migrations, failover strategy, CDN provider switches, and load balancing with DNS. Any global traffic management decision is bounded by the TTLs already in the wild.
Common misconceptions
- A short TTL guarantees instant failover — clients and applications hold their own caches beyond resolver TTLs
- Lowering TTL takes effect immediately — resolvers keep serving the old TTL value until it expires
- TTL only matters for A records — it governs every record type including CNAME, MX, and TXT
Anti-patterns
- Switching infrastructure with a 24-hour TTL still cached everywhere and calling it a maintenance window
- Setting 60-second TTLs permanently on stable records and absorbing the query volume forever
- Forgetting that negative responses have their own TTL and waiting on a record that never existed
Related concepts
Related examples
Authoritative source
https://www.cloudflare.com/learning/dns/dns-records/dns-ttl/
What it is
Every DNS answer carries a TTL that tells resolvers how long it is trustworthy. After expiry the resolver must ask the authority again. The TTL is part of the data being cached, so changing it only takes hold after the previously cached value expires — a two-step propagation that surprises many operators.
How it works
Resolvers count down from the TTL at fetch time, so a record served near expiry may live only seconds in another resolver. Negative caching has its own TTL from the SOA record. Some browsers and OS layers apply minimum TTLs of their own, and stub caches ignore very low values.
When to care
Lower TTLs at least one old-TTL before a planned cutover so the change window is achievable. Failover systems need TTLs matched to business tolerance: 30 to 300 seconds is common. Stable infrastructure records can live at hours or a day to cut authority query load.
Pitfalls
Client-side caches and connection pools outlive DNS TTLs, so even a 30-second record cannot kill existing connections. Monitoring should compare authoritative answers with resolver-visible answers during migrations. Treat TTL as a budget for change, not a guarantee of it.