TTL Strategy: Setting DNS TTLs for Speed, Failover, and Painless Migrations

A record's TTL (time to live) tells resolvers how many seconds to cache the answer before asking again — and choosing it well is a balance between performance and how quickly you can change things. There is no single "correct" TTL; the right value depends on what that record is for.

The core trade-off

• High TTL (hours to a day) — answers are cached longer, so fewer queries hit your nameservers and lookups are faster on average. The cost: changes take longer to take effect.
• Low TTL (seconds to minutes) — changes propagate quickly and failover works, but resolvers query far more often, adding load and a touch of latency.

TTLs and failover

Automatic DNS failover only works if the TTL is short — a record cached for a day cannot be redirected for a day. Failover setups typically use very low TTLs (30–60 seconds), accepting the extra query load in exchange for fast recovery.

The migration playbook

Low TTLs are your best friend during a move:

1. Lower the TTL well in advance — to a few minutes, at least one old-TTL period before the change, so caches have expired and are holding the short value.
2. Make the change — resolvers pick it up within the short TTL.
3. Verify, then raise the TTL back up for normal caching.

This is the heart of a zero-downtime DNS migration, and why lowering TTL first matters so much for propagation.

Sensible defaults

• Stable records (a fixed A record) — hours, for good caching.
• Records you may change soon — a few minutes.
• Failover records — 30–60 seconds.

Check any record's remaining cached TTL with dig — it counts down on repeated queries to the same resolver.

Frequently asked questions

What TTL should I use by default?

For stable records, a few hours balances caching and flexibility. Drop it to minutes before any planned change, and use very low values only where you need fast failover, since low TTLs increase query load.

Why lower the TTL before a migration and not during?

Because resolvers may already be caching the old, high TTL. You must lower it at least one old-TTL period ahead so those caches expire and start holding the short value before you make the switch.

Does a low TTL slow down my site?

Slightly, since resolvers look up more often, but the extra latency is usually tiny and only on the DNS step. The bigger cost is more query volume on your nameservers, which robust providers handle easily.