DNS TTL and propagation, and why to lower it before a move

When a website move goes wrong, it is rarely the copy of the files. It is the DNS switch: half the visitors see the new server, half the old one, and mail lands in the wrong place. The cause is TTL, and the fix is a calendar, not a tool. This post puts the dates in order. It fits with the full plan in moving from cPanel without downtime, and with how the DNS feature of a panel manages records.

What TTL is

TTL (time to live) is a number of seconds attached to each DNS record. It tells resolvers how long they may keep the answer before asking again. Cloudflare's documentation (read 30 October 2026) puts it this way: longer TTLs speed up lookups but make record updates take longer to take effect. On Cloudflare, unproxied records can use a TTL from 60 seconds (30 on Enterprise) up to one day, and Auto means 300 seconds. Proxied records are fixed at 300.

The propagation myth

People say DNS changes "propagate", as if the new value spread outward. It does not. Nothing is pushed. You change the record at the authoritative server, and every resolver that already holds the old answer keeps using it until its own timer ends. A resolver that asked one minute before your change waits almost the full TTL. One that never asked sees the new value at once.

So the worst case is the old TTL. With a 24 hour TTL, some people reach the old server for a day. That is the reason to lower it first.

The timeline

Say the record has a TTL of 86400 seconds (one day).

1. At least 2 days before: lower the TTL on the records you will change (A, AAAA, CNAME, MX) to 300 seconds. Wait at least the old TTL, so every cache has seen the short value.
2. A day before: check the new server on its own address, using a hosts file entry.
3. Move day: do a final sync of files and databases, then change the records. The switch is complete in about five minutes for most people.
4. For 24 to 48 hours: keep the old server serving, ideally forwarding writes or showing a notice, since a few caches lag.
5. After the move: once old server traffic is gone and the new setup is stable, raise the TTL again to an hour or more, so lookups are fast and your DNS host sees less load.

Check with dig

Ask several resolvers and your own authoritative server:

dig +noall +answer example.com A @1.1.1.1
dig +noall +answer example.com A @8.8.8.8
dig +noall +answer example.com A @9.9.9.9
dig +noall +answer example.com A @ns1.yourhost.com

The number between the name and the type is the remaining TTL in the resolver's cache. Repeat the query and it counts down. When the cached copies reach zero and refresh, they show the new address. The authoritative answer always shows the full TTL.

Mail is the special case

Mail survives a late switch better than web traffic, but only if you plan for it. Sending servers cache the MX record and, if your server does not answer, queue the message and retry for days. Lower the MX TTL together with the A records. Keep the old mail server receiving after the move, then collect what landed there. If mailbox contents are moved by copy, run a final copy after the switch. Do not delete the old mail server the same day.

Negative caching

Resolvers also cache "this name does not exist". RFC 2308 (read 30 October 2026) says the negative TTL is the lower of the SOA record's own TTL and its MINIMUM field, and suggests resolvers cap it, with one to three hours a sensible default and values over a day found to be problematic. In practice: if you create a new subdomain and someone already looked it up, they may not see it until that negative answer expires. Create the records before you announce the name.

Cleanup

• Raise TTLs back.
• Remove test hosts entries.
• Delete the old records, not the old server, a week later.
• Write down the final values so the next move starts from facts.

Which TTL should you pick

For stable sites, an hour to a day is fine. For a record you may need to change in an emergency, 300 seconds costs little. For the days around a move, 300 seconds on everything you will touch.