Skip to content

Lower your TTL before a migration

Updated 6 min readBy the DNSPeek team

Lower the TTL of the records you will change to 300 seconds at least one full old TTL before the migration, usually 24 to 48 hours ahead. Resolvers then cache the old address for at most five minutes, so the switch reaches almost everyone quickly and a rollback is just as fast. Raise the TTL back to a normal value a few days after the move.

What TTL does during a migration

Every DNS record has a TTL (time to live) in seconds. It tells resolvers how long they may reuse a cached answer before asking again. With a TTL of 86400, a resolver that looked up your domain just before the switch can keep sending its users to the old server for a whole day.

Lowering the TTL does not speed anything up by itself. It shortens the next cache period. That is why timing matters: the short TTL only takes effect once the old, long TTL has run out in every cache that holds it.

The timeline

TTL timeline for a migration
WhenRecordTTLWhy
TodayA → old server IPLower to 300Caches start picking up the short TTL as their old copies expire
After one old TTL has passedA → old server IP300Every cache now holds the record for at most five minutes
Switch dayA → new server IP300Visitors move over within minutes; rollback is just as fast
A few days laterA → new server IPBack to 3600 or moreFewer queries, better resilience if your DNS provider has an outage
zone file
; Before the move: same IP, short TTL
example.com.   300   IN   A   198.51.100.7

; Switch day: new IP
example.com.   300   IN   A   203.0.113.10

; A few days later: a longer TTL again
example.com.   3600  IN   A   203.0.113.10

How to lower the TTL

  1. Step 1: Check the current TTL

    Look up the TTL of every record you will change with the TTL checker or dig, and note the highest value.

  2. Step 2: Set the TTL to 300 seconds

    In your DNS provider’s panel, change only the TTL of those records to 300. Keep them pointing at the old server.

  3. Step 3: Wait one old TTL

    Wait at least as long as the old TTL you noted, so every cached copy with the long TTL has expired.

  4. Step 4: Switch the records

    Change the records to the new server. Most visitors reach it within five minutes; watch with the DNS propagation checker.

  5. Step 5: Raise the TTL again

    A few days after the move, when you are sure you will not roll back, set the TTL back to 3600 seconds or more.

Check the current TTL

The free TTL checker shows the TTL of each record of a domain. From a terminal, the number after the name is the TTL in seconds:

Terminal (macOS / Linux)
dig example.com A +noall +answer
# example.com.   3600   IN   A   198.51.100.7
PowerShell (Windows)
Resolve-DnsName -Name example.com -Type A | Format-Table Name, TTL, IPAddress

Cached answers count down

A recursive resolver shows the remaining time of its cached copy, so the number shrinks between queries. Ask the authoritative nameserver directly (dig @ns1.your-dns-host.com example.com A) to see the configured value.

Which records to lower

  • A and AAAA for the domain and for www, plus any other hostnames that point at the old server, such as shop or api.
  • CNAME records that will point somewhere new.
  • MX only if email moves too. If email stays where it is, leave MX alone.
  • TXT records such as SPF, if the sending servers change.

Records you will not touch can keep their TTL. If you are moving the DNS zone to another provider (changing nameservers), the TTL of individual records helps less: the delegation at the registry has its own TTL that you cannot change, often one to two days. In that case copy every record to the new zone first and compare both sides with DNS compare before you change the nameservers. The nameserver checker shows what the registry hands out.

How low should you go?

300 seconds is the usual choice. It is short enough that a switch or a rollback reaches most visitors within minutes, and long enough not to load your DNS provider. Going lower, such as 60 seconds, rarely helps in practice: some resolvers apply a minimum cache time anyway, and browsers and operating systems keep their own short caches.

Some DNS panels do not allow values below a minimum, or show TTL as a menu with names like “Auto”. With a proxied record on a CDN such as Cloudflare, the TTL you set does not matter for the switch at all: visitors resolve to the CDN, and you change the origin in the CDN instead.

Common TTL mistakes

  • Lowering it on switch day. Caches that already hold the record with a one-day TTL keep it for up to a day, short TTL or not.
  • Changing the wrong zone. If the domain’s nameservers point at Cloudflare, editing the zone at the registrar does nothing. Check which nameservers are authoritative first.
  • Forgetting www and IPv6. The bare domain switches in minutes while www or an AAAA record still carries the old IP with a long TTL.
  • Never raising it again. A permanent 300-second TTL works, but it means more queries and less protection if your DNS provider has an outage.
  • Expecting TTL to fix a CDN. With a proxied record, visitors resolve to the CDN either way; the change happens in the CDN’s origin settings.

Use the waiting time to test

A short TTL is also your safety net. If something goes wrong after the switch, pointing the record back at the old server reaches visitors just as quickly, as long as the old server is still running. Keep it until the move has settled. The day between lowering the TTL and the switch is the ideal time to check the new server. Open the site on the new IP with a DNSPeek preview link, run a QA report and send the link to whoever needs to approve it. The QA report also reads the domain’s DNS and reminds you to lower the TTL if it is still long.

TTL checklist

TTL

  • Current TTL of every record to change noted
  • TTL lowered to 300 seconds, records still on the old IP
  • One old TTL waited before the switch
  • Records switched to the new IP
  • Propagation checked from public resolvers
  • TTL raised again a few days later

Frequently asked questions

How long before a migration should I lower the TTL?

At least one full old TTL before the switch. With a TTL of one hour, lower it more than an hour ahead; with a TTL of one day, lower it more than a day ahead. Doing it 24 to 48 hours before covers the common cases.

What TTL should I use for a DNS switch?

300 seconds, or five minutes, is the usual value. It makes the switch and any rollback fast without putting noticeable load on your DNS provider.

Does lowering the TTL right before the switch help?

Very little. Resolvers that cached the record with the old, long TTL keep it until that TTL expires, so the short value only helps resolvers that ask again after you lowered it.

Should I keep a low TTL permanently?

Usually not. A longer TTL, such as an hour or more, means fewer lookups and keeps your site reachable for longer if your DNS provider has an outage. Lower it again before the next planned change.

Does TTL affect a nameserver change?

Only partly. The delegation to your nameservers is cached by resolvers according to the parent zone’s TTL, which you cannot change. Copy every record to the new provider and expect up to two days for the nameserver change itself.

Moving a site? Use the migration checklist

Every step from lowering the TTL to checking email after the switch, on one printable page. With a free account you keep your preview links in one place and run a QA report of the site on the new server.

Check the new server before you switch

DNSPeek gives you one HTTPS link that shows your site from the new server while DNS still points at the old one. Open it on any device, share it with your team or client, and run a QA crawl on the same link.

Create a free preview link