Lower Your DNS TTL Before a Hosting Move for a Fast Switch

If you lower your DNS TTL to 300 seconds at least one full old-TTL period before you move hosts, almost every visitor will reach the new server within about five minutes of the switch. If you skip that step, resolvers around the world can keep sending people to the old server for as long as the old TTL says, and that is often hours or a whole day. The fix costs you one small edit and a bit of patience a day or two ahead.

Here is a scene I see far too often: someone moves a site on Friday evening, updates the A record, and spends the weekend watching orders land on a server they meant to switch off. Nothing was broken. DNS did exactly what it was told.

By the end of this guide you will be able to read your current TTL, plan the timing, make the change, prove it worked with dig, and fix the usual problems.

What a DNS TTL actually is

A DNS record is the entry that maps a name like example.com to an IP address, such as an A record pointing to 192.0.2.10. Every record carries a TTL, short for "time to live".

RFC 1035, the core DNS specification, defines the TTL in section 3.2.1 as the time interval that the record "may be cached before the source of the information should again be consulted". Section 4.1.3 of the same RFC adds that the value is in seconds.

Think of it as the expiry label on a carton of milk. A resolver (the DNS server your internet provider or a public service runs on your behalf) buys the milk once, reads the label, and keeps pouring from that carton until the date passes. It does not phone the farm every morning to ask if the milk changed.

There is a second kind of label, too. RFC 2308 describes negative caching, which it defines as "the storage of knowledge that something does not exist". If someone looks up a name that does not exist yet, resolvers can remember that "no such record" answer. RFC 2308 says the TTL for that negative answer comes from the zone's SOA record: the minimum of the SOA MINIMUM field and the SOA record's own TTL.

Why this matters: if you plan to create a brand new name during the move, such as new.example.com, test it after you create it, not before. Looking it up early can cache a "does not exist" answer.

Why the old IP keeps answering

When you edit a record, your DNS provider updates its own nameservers quickly. The slow part is everyone else's cache.

Each resolver that already holds your old answer keeps using it until its copy expires. One that fetched the record just before your edit holds it for nearly the full TTL. That spread is what people call "propagation".

AWS puts the trade-off plainly in its Route 53 docs: a longer TTL means fewer queries and lower cost, but "it takes longer for changes to the record (for example, a new IP address) to take effect". The same page recommends using a shorter value first, "such as 300 seconds", and increasing it after you confirm the new settings are correct.

That is the whole trick. You shorten the label before the move, so on moving day every carton in every fridge is close to its date.

Before you start

Run through this list a few days before your planned move.

• Login access to the DNS panel where your records actually live. This is wherever your nameservers point, which may not be your registrar or your current host.
• The old server IP, for example 192.0.2.10, and the new server IP, for example 203.0.113.25.
• A copy of every record in the zone, saved somewhere off the old server. Step 2 shows how.
• A calendar plan that leaves at least one full old-TTL period between lowering the TTL and the switch. If your TTL is one day, that means starting at least a day ahead.
• A rough risk level. A brochure site can tolerate a few minutes of split traffic. A shop, a booking system, or anything that writes to a database needs a content freeze or a sync plan during the overlap.
• The new site already working on the new server. Our guide to planning a website migration to a new host covers copying files and databases.

Quick tip: if you are not sure which panel controls your DNS, ask dig for the NS records of your domain. Whatever nameservers come back are the ones you edit.

The timing plan, step by step

Step 1: Write down the current TTL

You need the current TTL because it tells you how long to wait after lowering it.

This command asks your default resolver for the A record of your domain and prints only the answer line.

dig example.com A +noall +answer

You should see one line per address, in this illustrative pattern, not captured output. The second column is the TTL in seconds.

example.com.    3600    IN    A    192.0.2.10

A resolver counts its cached TTL down, so the number you see from a resolver may be lower than the configured value. To read the real configured TTL, ask your authoritative nameserver directly. First find it with this command, which lists the nameservers for the domain.

dig example.com NS +noall +answer

Then ask one of those nameservers directly with the @ form. The dig manual describes @server as "the name or IP address of the name server to query". Replace ns1.example.com with a name from the previous output.

dig @ns1.example.com example.com A +noall +answer

The TTL in that answer is the value you configured. Write it down. Do the same for www.example.com and for any AAAA (IPv6 address) record, because each record has its own TTL.

On Windows without dig, nslookup works for checking which IP a resolver returns. In non-interactive mode the first parameter is the name to look up and the second is the DNS server to use. This command asks Cloudflare's public resolver for the address.

nslookup example.com 1.1.1.1

You should see the address or addresses for example.com in the answer. Microsoft's docs say nslookup -debug gives more information about the packets sent, so try nslookup -debug example.com if you want more detail. For reading TTLs reliably, dig is the easier tool.

Step 2: Back up the zone

Before you touch anything, save a copy of every record. If an edit goes wrong, you want to be able to put things back exactly.

The simplest method is to open your DNS panel and copy each record (name, type, value, TTL) into a text file. You can also save what the authoritative nameserver currently returns for the names that matter with this command, which saves each answer to a file.

for t in A AAAA MX TXT CNAME NS; do dig @ns1.example.com example.com $t +noall +answer; done > zone-backup.txt

Open zone-backup.txt afterwards. You should see your records listed. Repeat for www.example.com and any subdomains you use, because this loop only covers the names you ask for.

Heads up: MX and TXT records handle email and verification. Keep them in the backup in case someone clicks the wrong row.

Step 3: Lower the TTL to 300

Edit the A record (and AAAA, and the www record) and change only the TTL to 300. Keep the IP pointing at the old server, 192.0.2.10.

Five minutes is a sensible middle ground. It is the "shorter value" AWS suggests, and it matches the Auto value on Cloudflare. The exact menu paths for three panels are in the Variants section below.

Step 4: Wait one full old-TTL period

This is the step people skip, and it is the one that matters.

Resolvers that cached your record just before Step 3 still hold the old, long TTL. You have to wait for those copies to expire. If the old TTL was 3600, wait at least one hour. If it was 86400, wait at least a full day.

Why this matters: lowering the TTL on moving day does almost nothing. The caches out there were filled with the long label, and they will honour it.

Step 5: Check that the low TTL is live

Ask two big public resolvers what they now hold. Cloudflare lists 1.1.1.1 and 1.0.0.1 as its resolver addresses. Google lists 8.8.8.8 and 8.8.4.4 for Google Public DNS.

These two commands query each resolver for your A record.

dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer

You should see the old IP with a TTL of 300 or lower on both. If either still shows a number above 300, some cache has not turned over yet. Wait and check again.

Step 6: Switch the record

Now change the A record value from 192.0.2.10 to 203.0.113.25. Change AAAA and www too if they point at the old server. Leave the TTL at 300.

If you need a refresher on which records point where, see how to point a domain at your host.

Step 7: Keep the old server running until traffic stops

Do not cancel the old hosting on switch day. Some resolvers will still send people there for a while, and RFC 8767 even describes a "serve-stale" method that lets resolvers use expired data when they cannot reach your nameservers.

Watch the access logs on the old server. When requests for your site drop to nothing (or to bots only) for a full day or two, it is safe to shut it down. If your site takes orders or form submissions, put the old copy in read-only or maintenance mode so nothing is written there and lost.

Step 8: Raise the TTL again

Once the new server has been stable for a day or so and you will not roll back, set the TTL back to its old value or something like 3600. A longer TTL means fewer queries and faster repeat lookups.

A worked example

This is a made-up example. The addresses come from the ranges RFC 5737 reserves for documentation, so they will never belong to a real server.

Priya runs example.com on an old server at 192.0.2.10. Her A record TTL is 86400, one day. She wants to move to 203.0.113.25 on Saturday at 10:00.

• Thursday 09:00: she saves her records to a text file and lowers the TTL on example.com and www.example.com to 300.
• Friday 10:00: a full day has passed. She runs the dig @1.1.1.1 and dig @8.8.8.8 checks and sees TTLs of 300 or lower.
• Saturday 10:00: she changes both records to 203.0.113.25.
• Saturday 10:15: both public resolvers return the new IP.
• Monday: the old server's logs show only bots. She raises the TTL to 3600.
• The following weekend: she cancels the old hosting.

Without the Thursday step, some resolvers could have kept the old IP until Sunday morning. If any of these terms are new, our plain explainer on web hosting is a quick refresher.

Variants

cPanel Zone Editor

The cPanel documentation describes the Zone Editor interface, and notes your host can switch it on or off, so if you cannot find it, ask them. To edit a record:

1. Open Zone Editor and click Manage next to the domain.
2. Find the record. You can filter the list by typing a name or picking a record type filter.
3. Click Edit next to the record.
4. Update the information in the text boxes. Change the TTL to 300 and leave the address alone for now.
5. Click Save Record, or Save All Records if you edited several.

TTL appears as its own column in the Manage table, so you can confirm the new value at a glance.

Cloudflare

Cloudflare's docs split records into two kinds here. For proxied records, the TTL is Auto, which equals 300 seconds, and you cannot edit it. The docs say this keeps changes to Cloudflare's own anycast addresses from being cached for long, so there is nothing for you to lower.

At the time of writing (20 October 2026), Cloudflare lets you set the TTL on DNS only records anywhere from 60 seconds (30 seconds on Enterprise plans) up to one day. To edit one:

1. In the Cloudflare dashboard, go to the DNS Records page for your domain.
2. On the record, select Edit.
3. Change TTL to Auto, which Cloudflare defines as 300 seconds.
4. Select Save.

Heads up: Cloudflare's TTL page notes that changes can still take longer than five minutes to show up, because local DNS caches may update more slowly.

Amazon Route 53

AWS documents these console steps for editing a record:

1. Sign in to the AWS Management Console and open the Route 53 console.
2. In the navigation pane, choose Hosted zones.
3. Choose the row for the hosted zone that holds the record.
4. Select the record row and make your changes in the Edit record pane.
5. Set TTL (seconds) to 300.
6. Choose Save changes.

At the time of writing (20 October 2026), AWS says changes "generally propagate to all Route 53 name servers within 60 seconds". That is the time for Route 53's own servers. Resolver caches still follow your TTL.

How to check it worked

Run the same queries against both public resolvers after the switch.

dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer

An illustrative good result looks like this, with the new IP and a TTL of 300 or lower.

example.com.    300    IN    A    203.0.113.25

If you only want the IP, the +short option gives a terse answer. This command prints just the address.

dig @8.8.8.8 example.com A +short

You should see one line: 203.0.113.25. Repeat for www.example.com and for AAAA records.

Quick tip: finally, load the site in a private browser window and check something only the new server has, such as a test file you uploaded there.

What TTL does not fix

Lowering the TTL helps with resolver caches that respect it. Some things sit outside its reach.

• Your own device cache. Your computer keeps a DNS cache too. On Windows, ipconfig /flushdns flushes and resets the contents of the DNS client resolver cache, per Microsoft. Testing from a second device or network is the quickest way to rule your machine out.
• Resolvers that hold answers longer than you asked. Cloudflare's docs warn that local caches may update more slowly, and RFC 8767 lets resolvers serve stale data when your nameservers are unreachable. Your old server stays up for exactly this reason.
• Nameserver changes. If your move also changes which company hosts your DNS, you are changing NS records at the registry level, and those carry their own TTL. AWS notes that the typical TTL setting for the NS record is 172800 seconds, or two days, and that you may need to wait two days after lowering it. Your record TTL does not shorten that.

Troubleshooting

The old IP is still showing an hour after the switch

Symptom: dig returns a line like example.com. 14000 IN A 192.0.2.10, with the old IP and a large TTL.

Cause: the TTL was lowered too late, or this resolver cached the record before the change.

Fix: wait out the seconds shown. To refresh public resolvers sooner, use Google's Flush Cache tool at dns.google/cache and Cloudflare's Purge Cache tool at one.one.one.one/purge-cache/. Google advises flushing the main domain before its subdomains if your DNS hosting recently changed.

One public resolver has the new IP and the other does not

Symptom: dig @1.1.1.1 shows 203.0.113.25 but dig @8.8.8.8 still shows 192.0.2.10.

Cause: each resolver fetched your record at a different moment, so their copies expire at different times.

Fix: this is normal inside the TTL window. Wait up to the TTL you saw, or use the flush tools above.

A brand new name says it does not exist

Symptom: nslookup prints Nonexistent domain for a name you just created.

Cause: Microsoft's docs say this means the computer or DNS domain name does not exist. A resolver may have cached that negative answer from an earlier lookup, as RFC 2308 allows.

Fix: confirm the record exists on your authoritative server with dig @ns1.example.com new.example.com A +noall +answer, then wait for the negative cache to expire or flush it with the tools above.

The lookup finds the name but no address

Symptom: nslookup prints No records.

Cause: Microsoft's docs say the name is valid but the server has no records of the type you asked for. For example, you asked for AAAA but the domain only has an A record.

Fix: check the type with nslookup -type=A example.com, and add the missing record if your site needs it.

The resolver does not answer at all

Symptom: nslookup prints timed out.

Cause: per Microsoft, the server did not respond after a set time and number of retries.

Fix: try the other public resolver, or run the check from a different network or from the new server itself.

Your own computer still shows the old site

Symptom: dig @8.8.8.8 example.com A +short prints 203.0.113.25, but your browser still loads the old site.

Cause: your computer's own DNS cache still holds the old answer.

Fix: on Windows, run ipconfig /flushdns. Then test from another device or network to rule out your machine.

You cannot change the TTL on a Cloudflare record

Symptom: the record's TTL shows Auto and you cannot edit it.

Cause: the record is proxied, and Cloudflare does not allow TTL edits on proxied records.

Fix: nothing to do. Cloudflare's docs say proxied records use Auto, which is 300 seconds, and resolvers will not cache them longer than that.

Pro tips and security notes

• Lower TTL on every record you will change, not only the root A. The www record is the one people forget.
• Use two-factor authentication on your DNS and registrar accounts. Whoever can edit your DNS can send your visitors anywhere.
• Make sure the new server has a valid SSL certificate for your domain before Step 6, or visitors on the new IP will see a browser warning.

The one message worth forwarding

If someone else manages your DNS or your server, send them this:

"Hi, we are moving example.com from 192.0.2.10 to 203.0.113.25 on [date and time]. Please lower the TTL on the A, AAAA and www records to 300 seconds at least one full current-TTL period before that, and send me the current TTL so I can plan the wait. Please export or copy the zone first as a backup. On the day, change only the IPs, keep the old server running until its logs show no real traffic, and raise the TTL back afterwards. Thanks."

The takeaway: shorten the expiry label a full old-TTL ahead, and moving day becomes a five-minute job.