DNS TTL and Propagation When Moving a Website

DNS caching matters when moving a website. Recursive resolvers retain answers between lookups, and a record's Time to Live (TTL) helps you plan cache changes. The standards also describe exceptions that need care.

How Resolver Caching Works#

The Domain Name System maps human-readable names to the machine-readable addresses servers use. To avoid contacting authoritative nameservers for every lookup, recursive resolvers keep a local cache of the records they retrieve. As RFC 1034: Domain Names - Concepts and Facilities describes, a resolver checks that cache first, and if it holds valid data for a question, it returns the cached answer rather than asking the authoritative server again.

DNS resource records carry a TTL measured in seconds. RFC 1034 defines this value as the instruction a resolver uses to decide how long the record may stay cached before it should be discarded or refreshed. For normal caching, TTL is a planning input; the stale-serving exception below prevents treating it as a complete cutover deadline.

• Longer TTLs increase cache hits, which speeds repeated lookups — but a record change takes longer to reach end users whose resolvers still hold the old answer.
• Shorter TTLs let updates land sooner across resolvers, at the cost of more frequent refresh queries.
• Zero TTL prohibits caching outright, so resolvers fetch data for every transaction.

Lowering Your TTL Before the Migration#

RFC 1034 addresses this situation directly: when a change is anticipated, the zone administrator can reduce the TTL beforehand to minimize inconsistency during the change, then restore the former value afterward. That gives you a four-step shape:

1. Reduce the TTL on your existing records — the A or CNAME records that currently point at your old server — before anything else changes.
2. Wait out the original TTL. Make the reduction at least one full old-TTL cycle ahead of your planned cutover. If the record previously used 86,400 seconds (24 hours), a resolver that cached it just before your change may hold the old value for up to that long before it comes back for the shorter TTL.
3. Cut over. Once resolvers have picked up the shorter TTL, update the record's address or hostname to point at the new hosting server. Under normal caching, refreshed records use the shortened TTL; refresh failures may still lead a resolver to serve stale data.
4. Restore the TTL. After traffic has settled on the new server, raise the TTL back toward its normal value to regain the caching benefit.

Before scheduling the change, check the TTL currently set on the records you will edit and ask your DNS provider which lower value is supported. Keep those values with your cutover notes.

Cloudflare's TTL Rules#

If your zone is on Cloudflare, the applicable limits are published in the Cloudflare DNS TTL reference. Proxied records carry an Auto TTL that you cannot edit, set to 300 seconds (5 minutes). For unproxied (DNS-only) records, you can choose a custom TTL from 30 seconds on Enterprise plans or 60 seconds on other plans, up to 1 day; choosing Auto there also yields 300 seconds. Cloudflare also notes that TTL settings for nameservers apply to Cloudflare and custom nameservers, while standard NS records in the DNS table use their own record fields.

These figures describe Cloudflare specifically. For another DNS service, ask which values its documentation permits before choosing a cutover window.

When Resolvers Serve Stale Data#

A TTL expiry does not guarantee a resolver will immediately have fresh data. RFC 8767: Serving Stale Data to Improve DNS Resiliency defines a mechanism by which a recursive resolver may continue returning expired records from its cache as an exceptional fallback when the authoritative nameservers are unreachable or the refresh attempt fails. The intent is availability: during an authoritative outage, users receive an older but usable answer instead of a failure.

Serve-stale behavior means the old TTL is a preparation interval for normal caching, not an upper bound on every resolver switching to the new answer. Keep the documented refresh-failure exception in mind when assessing the cutover, rather than assuming an expired TTL proves that every resolver now has fresh data.

Checklist for Your Cutover#

• Confirm your provider's lowest permitted TTL and the TTL currently set on your live records.
• Lower the TTL at least one full old-TTL cycle before the migration window.
• Update the record to the new host's address or hostname once the shorter TTL is in place.
• Verify resolution from more than one network, watch traffic arrive at the new server, and restore the TTL to its normal value when the migration is complete.

Treat your record settings as planning inputs and verify the observed result; resolver behavior can differ across networks.