DNS TTL Strategy: Caching, Failover and Change

Key Takeaways

• Lowering a TTL changes future DNS answers; it does not shorten the countdown on copies already cached.
• Short TTLs support faster changes but increase reliance on fresh DNS lookups and require capacity planning.
• Successful migrations and failover depend on authoritative consistency, cache behavior and application recovery together.

Every DNS change raises the same question: how long until everyone sees it? DNS TTL is the setting that governs the answer, and its limits matter as much as its value. A failed cutover or a slow failover is visible to users and the business, not just to the DNS team. This post explains what TTL controls, where it stops working, and how to plan values for stable records, dynamic services and migrations.

What  DNS TTL  controls

Time to live (TTL) is a value in seconds that tells a DNS cache how long an answer may normally be reused before its source must be consulted again. An authoritative DNS server publishes records for a zone; a recursive DNS resolver obtains answers on behalf of clients and caches them.

Suppose a resolver caches an address with a TTL of 3,600 seconds. Ten minutes later, its remaining TTL is approximately 3,000 seconds. Answering another client from that cache does not restart the original hour. Once the TTL expires, the next lookup needs a fresh answer. Resolvers do not all refresh at that exact moment.

TTL also does not delete the authoritative record or determine when secondary servers receive zone updates. Those are separate parts of DNS operation.

A resource record set (RRset) groups records with the same name, class and type. Its members must share a TTL, as RFC 2181 explains, but different sets have independent lifetimes. A CNAME alias, its target’s IPv4 addresses and its IPv6 addresses can therefore expire at different times.

Why a low TTL does not guarantee fast failover

Shorter TTLs give clients more chances to pick up an updated answer. They also cut cache reuse, which raises query traffic to your authoritative servers and can add lookup latency and metered costs. Longer TTLs have an upside: clients can keep resolving through a short authoritative outage. RFC 9199 covers these trade-offs.

A 60-second TTL therefore describes only part of a recovery process. A service failure must be detected, a healthy destination selected, and the changed answer made available. Clients must then obtain that answer and successfully reconnect. Simply publishing several addresses does not provide application health checking.

DNS-based global server load balancing, such as EfficientIP DNS GSLB, adds health-aware destination selection. For disaster recovery planning, test the full path from failure detection to a successful application transaction.

Application behavior matters too. For example, libcurl can reuse an existing connection before performing another DNS lookup. Changing DNS does not move that connection to another server. Application caches, connection lifetimes and retry behavior belong in the recovery test.

There is also an intentional exception to normal expiry: serve-stale. Under RFC 8767, supporting resolvers can return expired cached data when authoritative refresh fails. That improves resilience, but it reinforces why TTL alone cannot guarantee when every client stops receiving an old answer.

Choose values by operational need

Treat these values as starting points to validate, not rules. Classify records by how fast you need to react, not only by how often they change. An address that rarely changes may still need to be redirected quickly in an emergency.

Operational DNS guidance supports choosing longer values for stable records and shorter ones for health-checked failover. The appropriate value still depends on the service. Dynamic DNS updates do not invalidate existing resolver caches.

For each short-TTL exception, record an owner, the required response time and a review date. Measure query volume, resolution latency and errors before and after the change.

Plan the migration before changing the address

Consider an illustrative migration of app.example.com with an existing TTL of 86,400 seconds. The team wants a five-minute TTL during cutover.

1. Map the dependencies. Identify the relevant A, AAAA and CNAME records, their current TTLs, and the authoritative servers serving them. Confirm that the new destination supports the application, certificates and network access.
2. Publish the lower TTL first. Keep the old destination in place while changing the affected TTLs to 300 seconds. Query every authoritative server to verify the lower values are being served.
3. Allow the old TTL to run out. Wait at least 24 hours after all authoritative servers publish the reduction, with operational margin. A resolver that obtained the old answer immediately before that point can retain its original one-day lifetime.
4. Cut over and observe. Change the destination, verify all authoritative answers, then check representative internal and external resolvers. Monitor real application transactions and traffic to both destinations.
5. Preserve rollback, then restore the baseline. Keep the previous endpoint serviceable through the agreed validation period and observed client/session drain. Retain the shorter TTL while rollback remains likely, then restore the normal value once the service is stable.

This follows the advance-reduction approach described in RFC 1034. Lowering the TTL at cutover leaves previously cached answers on their original countdowns.

Rollback needs the same care: reverting a record does not recall answers already cached for the new destination. A provider or nameserver migration also needs a separate review of parent delegation, glue and DNSSEC dependencies where applicable; changing an application’s address TTL does not change those lifetimes.

Remember that “does not exist” can be cached

Negative caching stores an answer that a name does not exist, or that a requested record type is absent. A client that queries a new hostname before it is created may continue receiving that cached negative answer after publication.

RFC 2308 derives the negative-cache TTL from the lower of the zone’s Start of Authority (SOA) record TTL and its SOA.MINIMUM field. The new A record’s TTL does not control an earlier cached negative response.

Create and validate new names before clients depend on them, and include negative-cache timing in the launch plan. Avoid deleting and recreating a name during a move when a direct record update will suffice.

Make TTL policy part of DNS operations

Keep record ownership, TTL exceptions and rollback instructions in the same change process. This becomes especially useful when DNS governance spans multiple clouds.

SOLIDserver DDI provides unified management of DNS, DHCP and IP address data, with change tracking. That gives teams a practical foundation for maintaining consistent records and reviewing changes. Pair that control with DNS measurements and application tests to validate the result clients experience.

Conclusion

A TTL strategy should explain why each record needs its chosen cache lifetime, how changes will be prepared and how recovery will be measured. Start by reviewing critical service records and rehearsing one migration, including rollback. The useful outcome is a predictable change process with evidence that applications recover as intended.