DNS TTL Strategy: Choosing Values and Lowering Them Before a Migration

A DNS TTL (time to live) is the number of seconds a resolver is allowed to cache a record before it must ask your authoritative nameservers again. The right strategy is simple to state: keep stable records on a moderately long TTL (3600 seconds or more) for speed and lower query load, and lower the TTL to about 300 seconds on any record you are about to change, doing so at least two of the old TTL windows (commonly 24 to 48 hours) before the cutover. Lowering the TTL at the moment you flip the record is too late, because the old long value is already cached across the internet and will keep serving the old answer until it expires.

That one timing rule is the heart of every clean migration. The rest of this guide explains how to pick steady-state values and how to run the pre-migration lowering playbook with numbers you can act on.

What TTL actually controls

When a resolver fetches your record, it starts a countdown from the TTL you set. Until that countdown hits zero, every user behind that resolver gets the cached answer and your nameservers never hear from them. This is good for performance and cost, and bad whenever the record needs to change. A TTL is therefore a trade between three things.

• Speed and load: longer TTLs mean more cache hits, faster lookups for users, and fewer queries hitting your authoritative servers.
• Cost on metered providers: some managed DNS services bill per million queries, so a longer TTL directly lowers the bill.
• Agility and outage sensitivity: shorter TTLs let you change or fail over quickly, but if the record points at something that breaks, a long TTL means the broken answer lingers.

Choosing steady-state values by record type

Outside of a migration, lean toward longer values on records that rarely change and shorter values only where you genuinely need fast control. These are sensible defaults, not hard rules.

You can inspect the current TTL on any record with dig. The number in the second column of the answer section is the seconds remaining in the cache, not the configured value, so query your authoritative server directly for the true setting.

$ dig example.com A +noall +answer
example.com.    3600    IN    A    203.0.113.10

$ dig @ns1.example.com example.com A +noall +answer
example.com.    3600    IN    A    203.0.113.10

The pre-migration lowering playbook

When you know a record will change, for example you are moving a site to a new host or switching mail providers, follow this sequence. The key is that you must lower the TTL far enough ahead that the old long TTL has fully expired everywhere before the day of the change.

1. Plan by the old TTL. If the record is currently at 86400 (one day), the old value can stay cached for up to a full day after any resolver last fetched it. So schedule your TTL reduction at least one, and ideally two, of those windows ahead. For a one-day TTL, that is 24 to 48 hours of lead time.
2. Lower the TTL only. Change the TTL to about 300 seconds while keeping the record value exactly the same. Nothing breaks, because the answer is identical; only the cache lifetime shrinks.
3. Wait out the old window. Let at least the full old TTL pass so that every cached copy of the long TTL has expired and been replaced with the new short TTL.
4. Cut over. Now change the record value. Because the TTL is 300 seconds, resolvers worldwide pick up the new answer within about five minutes instead of a day.
5. Confirm, then raise it back. Verify the new value is being served, then restore the TTL to its steady-state value to regain the performance and cost benefits.

Here is the same idea as a concrete timeline for a record currently at 86400.

# Day 0, 48h before cutover: lower TTL, keep value
app.example.com.   300    IN    A    203.0.113.10

# Day 2, cutover: change value, TTL still 300
app.example.com.   300    IN    A    198.51.100.25

# Day 2 + 1h, confirmed live: restore long TTL
app.example.com.   3600   IN    A    198.51.100.25

Why lowering at cutover does not work

This is the mistake that causes split-brain outages where some users see the new site and some see the old one for a full day. If a record is at 86400 and you lower it to 300 and change the value in the same edit, resolvers that already cached the old answer keep serving it for up to a day. They never see your new low TTL until their existing cache expires. The low TTL only helps future lookups, not the ones already in flight. Lowering the TTL has to happen before the old TTL has had time to flush.

Negative caching and newly added records

TTL strategy has a second, quieter side: negative caching. When a resolver asks for a name that does not exist, it caches that NXDOMAIN answer too, for a length of time set by the minimum field in your zone SOA record (per RFC 2308). This matters when you add a brand new record.

• If someone queried a hostname before it existed, the NXDOMAIN is cached, and your shiny new record will not appear for that resolver until the negative TTL expires.
• A sensible negative TTL is 300 to 3600 seconds. A value set to a full day can leave a newly added subdomain looking broken for everyone who checked early.
• Unlike a record TTL, you cannot lower the negative TTL after the fact to help an already-cached NXDOMAIN; the cached miss runs out on its own schedule.

The practical lesson: do not point clients, monitoring, or marketing at a hostname until after you have created the record, so you never prime a negative cache against yourself.

Plan your next cutover with confidence

Good TTL hygiene is invisible when it works and painful when it does not. Before and during any change, watch the record roll out in real time with the Valla DNS propagation checker so you know the exact moment a new value is live everywhere and it is safe to raise the TTL back. For the concepts behind these timings, see the related guides in the Valla DNS learning hub on DNS propagation, record types, and the SOA record that governs negative caching.