When to lower DNS TTL before a website move

Quick answer: Lower the relevant A, AAAA or CNAME record TTL at least one full old TTL before a planned origin cutover, then leave time to check that the new lower TTL is being served. If a website moves at Friday 18:00 UTC and its old TTL is 86,400 seconds (24 hours), changing it to 300 seconds at Thursday 17:00 UTC gives 25 hours: the old TTL plus a chosen one-hour planning buffer. This improves the conditions for a later switch; it does not promise that every resolver or visitor changes at the same instant. Sources: Route 53 DNS practices, Cloudflare TTL reference.

Important constraint: Lowering an authoritative TTL cannot remotely flush answers that recursive resolvers already cached with the previous longer TTL. A change made five minutes before cutover can leave some clients using the old target. Keep the old origin able to serve traffic while you verify the new one, and plan application data, sessions, TLS and redirects separately from DNS. A correct DNS answer is only one layer of a working migration.

This guide covers a website origin change under the current authoritative DNS provider. The team edits web-facing A, AAAA or CNAME records and leaves the registrar, authoritative nameservers, DNSSEC chain and mail service alone. Moving nameservers or transferring a registration is a separate project with different cached-delegation and ownership questions. Keeping that boundary narrow makes the TTL calculation useful rather than turning one cutover into several simultaneous migrations.

Inventory each answer the site can use

List the apex domain, www and any app hostname that the move affects. Check whether each name has A records for IPv4, AAAA for IPv6, a CNAME alias, or provider-specific proxy behavior. Do not assume a correct A record proves the site has moved if an unchanged AAAA still leads IPv6 clients to the old origin. Follow any CNAME to understand which answer and TTL the client may actually encounter. Leave MX and mail-related records untouched unless mail is explicitly part of the project.

Keep the old and new target values in the same row. A rollback is harder if the operator remembers only the desired new address. Include the person who can change the authoritative zone and the person who can validate the application. A DNS operator can confirm the record value without knowing whether the new server has the right certificate or current data.

If the domain uses a proxy, understand which layer the public DNS answer represents. Cloudflare’s TTL documentation says proxied records use an automatic 300-second TTL that cannot be edited; DNS-only records have their own supported TTL choices. Changing a proxied origin does not mean visitors receive the raw origin IP in public DNS. Do not disable proxying merely to make this example’s TTL field editable; that would change a different part of the traffic path.

Why the old TTL sets the preparation window

TTL is a cache duration in seconds. A recursive resolver that asked for the old A answer shortly before the team lowers TTL may keep that old answer for the TTL it learned then. The new 300-second value applies to answers fetched after the authoritative change reaches that resolver. It does not recall an old cached answer. This is the practical implication of the cache behavior described in Route 53 guidance and Cloudflare’s TTL reference.

Suppose cutover is Friday at 18:00 UTC. The old TTL is 86,400 ÷ 3,600 = 24 hours. Lower it to 300 seconds (five minutes) by Thursday at 17:00 UTC. The interval to cutover is 25 hours, leaving 24 hours for a late old-TTL answer to age out plus a one-hour scenario buffer to inspect the authoritative change. The buffer is a planning choice, not a DNS standard or an uptime guarantee. Resolvers and local caches can behave differently, and clients may hold connections or DNS state beyond a simple record lookup.

If the team waits until Friday 17:55, five minutes before cutover, a resolver that just obtained the old answer under an 86,400-second TTL may keep using it long afterward. Setting the authoritative record to 300 at 17:55 does not shorten the TTL stored with that prior answer. A five-minute new TTL is useful only after the resolver has fetched the lowered-TTL answer. This is why the preparation change and the actual target change are two separate events.

Short TTLs cause more frequent DNS queries. Keep them temporarily low for the cutover and rollback window, then raise them after the site is stable and the team no longer needs rapid answer changes. Route 53’s best practices describe that trade-off. Choose the later steady-state TTL for the application’s reliability and query-cost needs, not by assuming 300 seconds is always preferable.

Use explicit checkpoints rather than one calendar reminder. At Thursday 17:00, lower only the affected authoritative records and confirm the new TTL is served. During the next day, keep both origins ready and verify the replacement site without directing normal traffic to it yet. Shortly before Friday 18:00, confirm the new origin’s certificate, redirects, application read/write path and rollback target. At cutover, change the intended records and record the authoritative update time. Over the following period, compare selected recursive answers and actual site behavior while the old origin remains available. Restore the steady-state TTL only after the team has accepted the new route and its rollback window.

If the schedule slips, recompute from the last time a resolver could have learned the old long TTL, not simply from the originally planned cutover. For example, if the lower-TTL change was not served authoritatively until Thursday 19:00, a Friday 18:00 cutover leaves less than the full 24-hour old-TTL window. The one-hour buffer in the example cannot compensate for a two-hour late preparation. Delay the target change or knowingly plan for more mixed traffic; do not relabel a short wait as fully propagated.

Check three different layers during the cutover

At the preparation step, confirm the authoritative provider now serves the lower TTL for every affected DNS-only record. At cutover, change only the intended web targets. Then check a small set of recursive resolvers as samples to see whether they return old or new answers and what TTL remains. Finally, test the actual application through both relevant network paths. These observations answer different questions; none alone proves global convergence.

An AWS Route 53 change marked deployed or INSYNC concerns the provider’s authoritative service state. It is not a universal certificate that all recursive caches on the internet have expired. Check the affected records directly and compare selected resolver observations over time. A resolver sample is useful evidence for a runbook; describe it as a sample, not a “100% propagated” claim.

For the application check, verify the correct hostname and certificate, redirects from www or the apex, a representative authenticated page or read path, and any write behavior whose data must be consistent across old and new origins. DNS cannot copy a database, keep user sessions valid, or make a new TLS certificate appear. The team needs a separate application cutover plan for those requirements. If the old origin is still receiving requests, decide whether both origins can safely serve them before changing records.

Rehearse a rollback before removing the old origin

Write a rollback condition before switching: perhaps the new origin fails its application checks, TLS is wrong, or writes are not reaching the intended data store. Keep the old origin healthy while traffic and checks indicate some clients may still use it. If the new route fails, restore the old DNS target and verify the application there. Do not assume that reversing the record instantly reverses traffic: a resolver that cached the new answer may keep it until its TTL expires, and existing connections can have their own lifetime.

The rollback plan should therefore address both endpoints for a while. If old and new origins cannot safely accept writes at the same time, define a maintenance or synchronization strategy before cutover. A DNS flip is not a data rollback. Record who may authorize the reversal, which record values to restore, and how the team will tell users about a temporary interruption if one is necessary. These are application choices, not outcomes guaranteed by setting a lower TTL.

After the new route has passed checks and retained traffic to the old origin has been understood, raise the TTL to the chosen normal value. Keep the record ledger and cutover timestamps for later diagnosis. If a future project instead changes authoritative nameservers, use a separate delegation plan; Route 53’s hosted-zone migration guide treats cached delegation as its own concern. The domains hub covers those distinct ownership and registration questions. For this origin-only move, success means the DNS answers and the website’s real behavior have been checked without assuming a no-downtime guarantee.