How and When to Lower DNS TTL Before a Migration

Every DNS record carries a TTL — time to live — that tells the rest of the internet how long it may cache an answer before asking again. Lowering your DNS TTL a day or two before a migration is what turns a slow, unpredictable cutover into one that finishes in minutes. This guide covers which service owns the setting, what value to use, and how to confirm the change took effect before you move anything.

The TTL change is one step in a larger job. Read how to choose a web host if you are still picking the destination, and our zero-downtime migration guide for the full cutover plan.

Know which service owns your DNS TTL

Keep the registrar login, DNS provider login, and hosting login straight. They may be the same company, but they are different jobs, and the TTL lives with whoever answers DNS queries for your domain — usually the service your nameservers point at. Confusing them is how a small DNS change becomes a long afternoon.

Make a short note with the account that controls DNS, the domain, and the records you plan to touch. Do not put passwords or recovery codes in the note. You want enough detail to retrace the work without creating a new security risk.

Record the current values, then lower the TTL

Record each record's current value and TTL before you edit it. DNS entries are short, but a single missing dot or wrong record type can direct visitors and mail somewhere else, and the note is your undo button.

Lower the TTL on the records the move will change — usually the A and AAAA records — at least a day before the migration. Around 300 seconds, five minutes, is a sensible floor. The old, longer TTL has to expire from caches everywhere first, which is why this happens a day early rather than an hour before.

Leave the records' values alone at this stage. You are only shortening how long the world is allowed to remember them.

Test with an independent lookup

Make DNS changes one at a time, then confirm each with an independent lookup rather than a browser. A browser can keep an older answer in cache long after the record has moved on.

Most of what people call DNS propagation is old TTLs expiring on schedule. If a lookup still returns the old value, check the elapsed time against the previous TTL before assuming the edit failed — a 24-hour TTL means some resolvers hold the old answer for up to a day. Our DNS propagation guide covers reading those delays.

When to stop and ask for help

Stop when the next action could overwrite data, change production mail, or remove access to the account. Send support the domain, time in UTC, the exact record, and the changes you made. Include a screenshot when it shows the error, but never private keys or passwords.

ICANN's DNS overview has useful background on the standards behind this topic: ICANN's DNS overview. Use it to understand the terms, then return to the small, reversible next step.

Raise the TTL back after the move

A five-minute DNS TTL is a migration setting, not a permanent one. Once the new records have been stable for a day or two, raise the TTL back to something like 3600 seconds so resolvers are not re-asking constantly.

Put the final values and the date in a short maintenance note. DNS problems repeat because nobody remembers which account owns a record or why a TTL has an unusual value, and a dated note turns the next incident into a lookup instead of an investigation.

Keep the change auditable

Use a short before-and-after record: the record you found, its old value and TTL, the exact time you changed it, and when you expect the new answer to be visible everywhere. This record is useful even when everything works. A few months later, it tells you why a setting has the value it does.

Do not confuse the DNS dashboard with evidence from the live internet. A dashboard shows what it accepted; a resolver near your visitors may still hold the old answer. Test from outside the account, and use a second network if a cached answer could mislead you.

If you hand the migration to someone else, give them the record rather than a conclusion. "DNS is being weird" is hard to investigate. "The A record changed at 14:00 UTC with a 300-second TTL, and one resolver still returns the old IP" gives the next person a useful starting point.

One last check

Before you call the TTL work finished, look the records up from a connection you have not used all day — a phone off wifi works. If the lookup shows the new, shorter TTL, caches are refreshing on your schedule and the cutover will move as fast as you planned. A quiet confirmation now is much easier than discovering a 24-hour TTL during the launch.

Leave a useful handoff

Save the final record values, TTLs, and test results with the date and the account involved. If someone revisits the setup later, they should be able to see what changed without reconstructing the whole migration from browser history.

Bottom line

Lowering the DNS TTL before a migration is cheap insurance: do it a day ahead, keep the old values written down, and verify with independent lookups. After the cutover settles, raise the TTL back and leave a dated note so the next change starts from evidence instead of guesswork.

Frequently asked questions

Should I lower the TTL on every DNS record at once?

No. Lower it only on the records the migration will change, usually A and AAAA. Keep the previous values noted until the new setup has been stable for a few days.

What should I send support if a DNS change is not taking effect?

Give the domain, the exact record, the UTC time of the change, and what your lookups return. That is usually enough for support to find the relevant logs.

Should I back up DNS records before changing the TTL?

Yes. Export the zone file or screenshot the full record list before any edits. DNS has no undo button, and the export is your rollback if a record gets mangled during the migration.