DNS TTL Strategy for Failover and Migration Planning

Quick answer: a DNS TTL tells resolvers how long they may cache an answer. Before a planned migration, lower the TTL at least one old-TTL period ahead of the change, make the switch, and raise it again afterward. Short TTLs speed up changes but increase query load and dependence on DNS, and some clients cache longer than the TTL, so keep the old environment running for a while.

How Does DNS Caching Work?

When a client looks up a name, a recursive resolver queries the authoritative servers, receives an answer with a TTL, and caches it for that many seconds. Until the TTL expires, the resolver answers from cache without asking again. Many layers can cache independently: the operating system, the browser, the application runtime, corporate resolvers, and ISP resolvers.

This is why DNS changes are not instant. If your record has a TTL of 24 hours and you change the address, some clients will keep using the old one for up to a day after the change, and different users switch at different times. Lowering the TTL does not retroactively shorten caches that already hold the old value. It affects answers fetched after the change.

Failed lookups are cached too. Resolvers cache non-existent answers for a period governed by the zone's negative caching setting, so creating a record that was recently queried and missing may not be visible immediately. Plan for this when you add new names shortly before launch.

How Do You Plan a Migration?

The standard approach is to lower the TTL ahead of time, so caches expire quickly when you switch. The order matters, because the lower value must be in place and have propagated before the cutover. A practical sequence is:

• Check the current TTL of the records involved, since the old value determines how long you must wait.
• Lower the TTL to a short value, such as a few minutes, and wait at least the previous TTL so old caches expire.
• Prepare the new environment and test it directly, without relying on DNS, to verify it serves traffic correctly.
• Change the record to point to the new target and watch traffic shift on both environments.
• Keep the old environment running until traffic drains, which can take longer than the TTL.
• Raise the TTL back to a normal value once the migration is stable.

Verification is easy from the command line. Querying a specific resolver shows the answer and the remaining TTL, and querying the authoritative server directly shows what you have actually published. Comparing both tells you whether a problem is propagation or configuration.

dig example.com A +noall +answer
dig @ns1.example-dns.net example.com A +noall +answer

What Are the Trade-offs of Short TTLs?

Short TTLs give faster changes, but cost something. Every cache miss triggers a lookup, so query volume grows, adding latency to the first request and increasing load on authoritative servers. A very short TTL also makes your availability depend more heavily on DNS, because clients re-resolve often, and a DNS outage becomes visible quickly instead of being masked by caches.

Long TTLs do the opposite: fewer queries and better resilience to brief DNS problems, but slow reaction to changes. Many teams keep TTLs moderate in normal operation, such as minutes to an hour for records that may need changing, and much longer for records that almost never change.

Be careful with DNS-based failover. Health-checked DNS can remove a failed endpoint from answers, but clients and resolvers that cache longer than the TTL, along with applications that resolve names once at startup, will keep using the failed address. Connection pools and some runtimes cache aggressively unless configured otherwise. Load balancers, floating addresses, or anycast give faster and more predictable failover, with DNS as a complement. Check your platform documentation for resolver caching behavior.

Frequently Asked Questions

What TTL should I use for a production record?

There is no universal value. Many teams use several minutes to an hour for records that may change, and longer for stable ones. Lower it before planned changes.

Why do some users still reach the old server after the TTL expired?

Some resolvers and applications cache longer than the TTL or resolve only at startup. Keep the old environment running until traffic drains.

Does lowering the TTL speed up the current change?

Not for caches that already hold the old record. It only affects answers fetched afterward, which is why you lower it in advance.

Can DNS alone provide high availability?

Only partially. Client caching limits how quickly failover takes effect. Combine DNS with load balancers or other mechanisms for faster recovery.

Summary

Treat TTL as a planning tool: lower it ahead of migrations, wait out the old value, switch, keep the old environment alive, then restore a moderate TTL. Understand the cost of short TTLs and the limits of DNS failover. Check your DNS provider's documentation for supported TTL ranges.