How to lower TTL before a website migration?

To lower TTL before a website migration, find the current TTL on the records you're going to change, then reduce it to a short value such as 300 seconds (five minutes) at least one full old TTL before the migration. If your A record currently has a TTL of 86,400 seconds (24 hours), lower it at least 24 hours in advance, and ideally 48. When you then change the record to point at the new server, resolvers will only hold the old address for five minutes. After the migration is stable, raise the TTL back to a longer value.

The timing is the part people get wrong. Lowering the TTL on the morning of the migration doesn't help, because resolvers that cached the record yesterday will keep the old value with the old, long TTL until it expires. In this guide you'll learn how TTL caching really works, how to check your current values, exactly when to lower them, which records matter, how to make the change through a dashboard or an API, and how to confirm resolvers have picked it up.

Why TTL Matters During a Migration

Every DNS record has a TTL (time to live), measured in seconds. When a recursive resolver, such as your ISP's resolver or 8.8.8.8, looks up your record, it caches the answer for that many seconds. Until the timer runs out, it answers from cache and doesn't ask your nameservers again.

That's great for performance, but it means a record change isn't seen by everyone at once. If your www record has a TTL of 86,400 and you change it, some visitors could keep reaching the old server for up to a day.

With a TTL of 300, the worst case is five minutes. That makes the switch fast and, just as importantly, makes a rollback fast. If something goes wrong on the new server, you can point the record back and most visitors return to the old server within minutes.

The Timing Rule

The key rule is simple:

Lower the TTL at least one old TTL period before you change the record value.

Here's why. Suppose a resolver cached your record at 09:00 on Monday with a TTL of 86,400. If you lower the TTL to 300 at 10:00 on Monday, that resolver doesn't know. It keeps the cached record until 09:00 on Tuesday. Only after it fetches the record again does it learn the new, short TTL.

A typical timeline looks like this:

When	Action	Record value	TTL
T minus 48 hours	Lower TTL	Old server, 192.0.2.10	300
T minus 24 hours	Check resolvers show the short TTL	Old server	300
T (migration)	Change the record	New server, 203.0.113.50	300
T plus 1 to 7 days	Raise TTL again once stable	New server	3600 or higher

Allowing double the old TTL gives you a margin for resolvers that refreshed late, or for records you lowered slightly later than planned.

Step 1: Find Your Current TTLs

You need to know the TTL your authoritative nameservers publish, not the countdown a resolver happens to show. Query your own nameservers directly.

First, find them:

dig example.com NS +short

ns1.dns-host.example.
ns2.dns-host.example.

Then ask one of them for each record you plan to change:

dig @ns1.dns-host.example example.com A +noall +answer
dig @ns1.dns-host.example www.example.com +noall +answer

example.com.		86400	IN	A	192.0.2.10
www.example.com.	86400	IN	CNAME	example.com.

The second column is the TTL. Here both records use 86,400 seconds, so you need to lower them at least a day before the move.

If you ask a recursive resolver instead, you'll see a smaller number that drops each time you query, because it's showing the time remaining in its cache:

dig @8.8.8.8 example.com A +noall +answer

example.com.		61234	IN	A	192.0.2.10

That's useful later for confirming the change has spread, but it isn't the configured TTL.

Step 2: Decide Which Records to Lower

Lower the TTL on every record whose value will change during the migration, plus any record that depends on it. For a typical web hosting move, that means:

• The apex A and AAAA records (example.com).
• The www record, whether it's an A record or a CNAME.
• Any other subdomains pointing at the old server, such as shop, blog or api.
• CNAME targets you control: If www is a CNAME to lb.example.com, lower lb.example.com too, because the resolver caches each step separately.

If you're moving email at the same time, add:

• MX records.
• SPF, DKIM and DMARC TXT records that will change.
• Autodiscover or SRV records used by mail clients.

Records that won't change, such as verification TXT records, don't need touching.

Don't Forget the AAAA Record

A common mistake is to lower the TTL on the A record, move the site, and forget the AAAA record. Visitors on IPv6 networks keep going to the old server, or to nowhere if the old server is switched off. If the new host doesn't support IPv6, remove the AAAA record as part of the migration, and lower its TTL in advance like any other record.

Step 3: Lower the TTL

In a DNS Dashboard

Most dashboards show a TTL drop-down or field next to each record. Change it to 300 seconds (often labelled "5 minutes") and save. Keep the record's value exactly the same.

A few provider details to be aware of:

• Cloudflare: The "Auto" TTL is 300 seconds. Proxied records always use Auto, and visitors connect to Cloudflare's edge rather than your server directly, so changing the origin IP takes effect almost immediately anyway.
• Minimum TTLs: Some providers won't let you go below 60, 300 or even 3,600 seconds on cheaper plans. Check the lowest allowed value before you plan the timeline.
• Registrar DNS: Some registrar control panels apply a single TTL to the whole zone rather than per record.

With the Cloudflare API

If you manage many records, an API call is faster and leaves less room for error. This updates only the TTL of an existing record:

curl -s -X PATCH \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"ttl": 300}'

You can find record IDs by listing the zone's records:

curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?name=www.example.com" \
  -H "Authorization: Bearer $CF_API_TOKEN" | jq '.result[] | {id, name, type, ttl}'

With the AWS CLI for Route 53

Route 53 changes are submitted as a change batch. An UPSERT with the same value and a new TTL lowers the TTL without changing anything else:

{
  "Comment": "Lower TTL before migration",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "example.com.",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [{ "Value": "192.0.2.10" }]
      }
    }
  ]
}

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEFGHIJ \
  --change-batch file://lower-ttl.json

Route 53 alias records don't have a TTL you can set, because they inherit the TTL of the AWS resource they point to.

In a BIND Zone File

If you run your own nameservers, edit the TTL on each record (or the $TTL default), increment the SOA serial, and reload:

$ORIGIN example.com.
$TTL 300
@    IN  SOA  ns1.example.com. hostmaster.example.com. (
              2026101501 ; serial, increment on every change
              3600       ; refresh
              900        ; retry
              1209600    ; expire
              300 )      ; negative caching TTL
@    300  IN  A      192.0.2.10
www  300  IN  CNAME  example.com.

named-checkzone example.com /etc/bind/zones/db.example.com
sudo rndc reload example.com

Forgetting to increment the serial means your secondary nameservers won't pick up the change, so some queries keep returning the old TTL.

Step 4: Confirm Resolvers Have the Short TTL

After one old TTL has passed, check a few public resolvers. Each should report a TTL of 300 or less:

for r in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
  printf "%-16s " "$r"
  dig @"$r" example.com A +noall +answer | awk '{print $2, $5}'
done

1.1.1.1          212 192.0.2.10
8.8.8.8          287 192.0.2.10
9.9.9.9          300 192.0.2.10
208.67.222.222   45 192.0.2.10

If any resolver still shows a large TTL, it cached the record before your change. Wait for that number to drop before migrating.

Public resolvers are anycast networks with many independent caches, so repeated queries may hit different caches with different countdowns. That's expected.

Step 5: Migrate and Change the Record

On migration day, get the new server fully ready first: site deployed, database synced, certificate issued and tested. You can test the new server before switching DNS by overriding name resolution locally:

curl -I --resolve example.com:443:203.0.113.50 https://example.com/

This sends a request to 203.0.113.50 while using example.com for TLS and the Host header, so you can confirm the certificate and site work without touching DNS.

Then update the record's value to the new IP address, keeping the TTL at 300. Within about five minutes, most resolvers will return the new address:

dig @1.1.1.1 example.com A +short

203.0.113.50

Keep the old server running for a while. Some clients cache beyond the TTL, as described below, and a short overlap costs very little.

Step 6: Raise the TTL Again

A low TTL isn't harmful, but it does mean more queries to your nameservers and slightly slower lookups for visitors whose resolver cache has expired. Once you're confident the migration is complete, raise it again. Common choices are:

Record type	Sensible long-term TTL
A, AAAA, CNAME for websites	3600 (1 hour)
MX	3600 to 86400
TXT for SPF, DKIM, DMARC	3600
Records you change often	300 to 600

Wait a day or two before raising it, so you can still roll back quickly if a problem appears.

Things That Ignore Your TTL

Lowering TTL gets you most of the way, but a few caches don't follow it exactly:

• Resolver minimum TTLs: Some resolvers enforce a floor, for example caching everything for at least 30 or 60 seconds, regardless of what you publish.
• Browsers: Chrome and Firefox keep their own short-lived DNS caches, and a browser with an open connection to the old server may keep using it until the connection closes.
• Operating systems: Windows, macOS and systemd-resolved cache answers locally, usually respecting the TTL.
• Long-running applications: Java applications in particular can cache DNS results for the life of the process depending on JVM security settings, and some HTTP clients and connection pools resolve a hostname once and keep the connection.
• Negative caching: If a record didn't exist and someone looked it up, the "doesn't exist" answer is cached for the SOA's negative caching TTL. That matters if you're creating new names as part of the migration.

None of these is a reason to skip lowering the TTL. They're the reason to keep the old server running for a short time after the switch.

What You Can't Lower: Nameserver Delegation

If your migration also involves changing nameservers, lowering TTLs inside your zone doesn't help with that part. The NS records that matter are held at the TLD registry, and for .com and .net they carry a TTL of 172,800 seconds (48 hours). You can see it by asking a .com server directly:

dig @a.gtld-servers.net example.com NS +norecurse +noall +authority

example.com.		172800	IN	NS	ns1.dns-host.example.
example.com.		172800	IN	NS	ns2.dns-host.example.

The way to deal with that is to keep both the old and new DNS providers serving identical records during the changeover, rather than relying on TTL.

---

FAQ: Lowering TTL Before a Migration

---

Conclusion

Lowering TTL is one of the cheapest ways to make a website migration smooth. Check the TTL your nameservers actually publish, reduce it to around 300 seconds at least one old TTL before the move, confirm public resolvers show the short value, and only then change the record. The switch takes minutes, and so does a rollback if you need one.

Remember to include every record that will change, including AAAA records and CNAME targets, keep the old server running briefly for clients that cache longer than they should, and raise the TTL again once things are stable. If you're changing nameservers too, plan for the registry's 48-hour delegation TTL separately.