What TTL actually controls
RFC 1035 defines the TTL field as the time interval that a resource record may be cached before the source of the information should again be consulted. It is an instruction attached to each answer, and it is read at the moment a resolver fetches the record. That detail drives everything else in this guide: a resolver that cached your A record yesterday with a one-day TTL holds the instruction it received yesterday, not the shorter value you set this morning.
Cloudflare states the trade-off plainly on its TTL reference page: a longer TTL also means that updates to your records take longer to go into effect. Lowering TTL before a move is therefore not about the cutover moment itself. It is about making sure every cached copy that exists at cutover was fetched under the short TTL, so that the change you make is picked up within minutes instead of hours.
For a course or membership site this matters more than for a brochure site. During the window when some visitors reach the old host and some reach the new one, a student can complete a lesson, or a member can renew, on a server whose database you are about to abandon.
The timing math
The rule is simple arithmetic: the earliest safe cutover time is the moment you lowered the TTL plus the old TTL value. If the A record currently carries a TTL of 86400 seconds (one day) and you lower it to 300 at 09:00 on Monday, a resolver that cached it at 08:59 can keep the old answer until 08:59 on Tuesday. Cutting over on Monday afternoon would leave those visitors on the old host for most of a day.
After the change, the maximum staleness drops to the new TTL. With 300 seconds, a resolver that respects the TTL should ask again within five minutes. Add a margin to both numbers, because you do not control exactly when each resolver last refreshed.
| Current TTL | Lower it no later than | Worst-case stale window after cutover (new TTL 300) |
|---|---|---|
| 300 seconds (5 minutes) | Already short; no change needed | About 5 minutes |
| 3600 seconds (1 hour) | At least 1 hour before; the day before is easier | About 5 minutes |
| 14400 seconds (4 hours) | At least 4 hours before | About 5 minutes |
| 86400 seconds (1 day) | At least 24 hours before; 48 hours gives margin | About 5 minutes |
Cloudflare: DNS-only versus proxied records
On Cloudflare, a TTL of Auto is set to 300 seconds. For DNS-only records Cloudflare lets you choose a TTL between 60 seconds (non-Enterprise) or 30 seconds (Enterprise) and 1 day. Cloudflare says DNS queries for DNS-only records resolve to the record's actual origin IP address, so the timing math above applies to them directly.
Proxied records behave differently. Cloudflare documents that a DNS query to a proxied record is answered with Cloudflare anycast IP addresses, and that all proxied records have a TTL of Auto, which is set to 300 seconds. Because the public answer is a Cloudflare address, moving your origin from the old host to the new one does not change what resolvers see. The switch happens inside Cloudflare when you edit the origin address on the proxied record, and lowering TTL in advance does nothing useful for that record.
This is why a migration checklist should start by listing every record that will change and marking whether it is proxied. A site whose www and apex records are proxied, but whose mail or API subdomain is DNS-only, needs the TTL step only for the DNS-only records.
What TTL cannot control
TTL applies to records inside your zone. It does not speed up a nameserver change, which is made at the registrar. Cloudflare's setup guide tells you to wait up to 24 hours while your registrar updates your nameservers, and to turn DNSSEC off at the registrar before replacing nameservers because changing nameservers while DNSSEC is active can cause the domain to become unreachable. If your move also changes DNS providers, plan for that longer window separately; the DNSSEC side is covered in the nameserver migration check guide.
TTL is also a request to caches, not a guarantee about every client. Treat the stale window as a minimum, keep the old host serving the site until traffic there stops, and decide in advance what happens to any writes it receives. For a membership site the safest answer is usually a short write freeze: put the old site into maintenance mode at cutover so no new orders, renewals, or lesson completions land in the old database.
- Lowering TTL does not change answers already cached under the old value.
- Proxied Cloudflare records hide the origin; origin moves do not touch public DNS.
- Nameserver changes follow the registrar's timeline, not your record TTLs.
- Old-host traffic after cutover is a data problem, not only a DNS problem.
A step-by-step TTL plan
Use this sequence for a planned host move where the DNS provider stays the same. Write each time and value into the cutover worksheet so the rollback owner can see what was changed and when.
- Two to three days before: export the zone and record every record that will change, its current value, its current TTL, and whether it is proxied.
- At least one old-TTL period before cutover (plus margin): lower the TTL on the DNS-only records that will change, for example to 300 seconds.
- Confirm the new TTL is being served by querying your authoritative nameservers directly.
- At cutover: freeze writes on the old site, run the final data sync, then change the record values.
- For the next hour: watch old-host access logs; traffic there should taper off within roughly the new TTL.
- After the site is stable for a day or two: raise TTLs back to your normal value, since short TTLs only buy faster changes.
Questions before you decide
Can I just set the TTL to 60 seconds permanently?
On a non-Enterprise Cloudflare plan, 60 seconds is the lowest DNS-only TTL Cloudflare offers. A permanently short TTL is not required for a migration; it only needs to be short during the window when you expect to change records. Raise it again after the move is stable.
My site records are orange-clouded on Cloudflare. Do I need to lower TTL?
Not for those records. Cloudflare answers proxied records with its own anycast addresses and a fixed Auto TTL of 300 seconds, so changing the origin IP does not change the public DNS answer. Lower TTL only on DNS-only records that will change.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- IETF: RFC 1035, Domain names - implementation and specification Accessed 13 Oct 2026
- Cloudflare: Time to Live (TTL) Accessed 13 Oct 2026
- Cloudflare: Proxy status Accessed 13 Oct 2026
- Cloudflare: Full setup Accessed 13 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.