DNS TTL Explained: How Low to Go Before a Migration

What TTL actually controls during a cutover

TTL (time to live) is the number of seconds a resolver is allowed to cache a DNS record before it must ask again. When a user's resolver looks up your A record and gets a 3600-second TTL, it will keep answering with that same IP for the next hour without rechecking, even if you've already changed the record at your authoritative nameserver.

During a migration that caching is the enemy. You flip the A record to the new server, but every resolver that cached the old value keeps sending users to the old IP until its copy expires. The window of that split, some users on the new server, some on the old, is bounded entirely by the TTL that was in effect when they last looked up the record.

How low to go

For the records you're about to change, drop the TTL to 300 seconds (5 minutes) as a safe, widely-respected default. That gives you a worst-case five-minute divergence at cutover, which is short enough for almost any migration. If you want a tighter window, 60 seconds is reasonable for the hour or two around the switch.

Going lower than 60 rarely pays off. Many recursive resolvers quietly enforce a floor and won't honor a TTL below a minute, so a value of 5 or 10 seconds mostly just multiplies your query volume without buying you faster propagation. It also raises your exposure to a transient DNS outage, because clients have to re-resolve constantly. Low TTL during a migration is a temporary tactic, not a permanent setting.

• 3600s (1 hr) or higher, normal steady-state default
• 300s (5 min), safe pre-migration value for the records you'll change
• 60s, aggressive, for a tight cutover window
• Below 60s, often ignored by resolvers, generally not worth it

The timing trap: change the TTL early

This is the step people miss. Lowering the TTL only affects lookups that happen after the change. Any resolver that cached the record while it still had a 3600-second TTL will hold that old value, including the old TTL, for up to a full hour, no matter what you do at the nameserver afterward.

So you have to lower the TTL at least one old-TTL period before the migration. If your record currently has a 3600-second TTL, drop it to 300 at least an hour, ideally a day for safety, before cutover, so that every cached copy has time to expire and be replaced with the low-TTL version. Only then is your effective divergence window actually 300 seconds. Skip this lead time and your carefully-lowered TTL does nothing on migration day.

Cutover, step by step

With the low TTL in place and aged in, the switch itself is anticlimactic, which is the goal.

Don't forget the negative side of caching: the SOA record's minimum field controls how long a NXDOMAIN or empty response is cached. If you're adding a record that didn't exist before, a high SOA minimum can make resolvers remember its absence. Check that value too if you're introducing new hostnames.

• Lower the TTL on the target records and wait out the old TTL period
• Stand up and verify the new destination before touching DNS
• Change the record at your authoritative nameserver
• Watch old and new servers to confirm traffic shifting over
• Keep both endpoints alive until the low-TTL window fully drains

Verify propagation instead of guessing

Don't rely on a single dig from your own machine, your resolver's cache isn't representative. Query several public resolvers directly (dig @1.1.1.1, dig @8.8.8.8) and check from a few geographic locations so you're sampling different caches. Our DNS checker lets you read the live record and its TTL across resolvers without setting up anything locally.

Watch the actual servers, too. Traffic still hitting the old endpoint after your TTL window should have drained is a sign that some resolver isn't honoring the TTL, or that a record you forgot about (a stray CNAME, an MX, an AAAA) is still pointing the old way. If you want a refresher on which record types you need to move, DNS records explained covers them.

Raise the TTL back, and monitor for drift

Once traffic has fully cut over and settled, put the TTL back up to its normal value (3600 or higher). Leaving it at 60 forever means more queries, slightly slower first lookups for users, and a larger blast radius if your DNS provider has a bad moment.

Migrations are also exactly when DNS records get changed by hand, and manual changes are where drift creeps in, a record left pointing at a decommissioned box, a TTL nobody reset, a subdomain that quietly stopped resolving. VigilDog's DNS monitoring records your resolution and TTLs continuously and alerts you when a record changes or drifts from its expected value, so the cleanup after a migration doesn't turn into next month's incident.