DNS TTL Before a Website Move: What to Lower and Verify

Web Hosting & Domains / DNS changes / Migration planning

Lower the TTL of the DNS records you will change before a website move, then allow the previous TTL to expire before switching their destination. Verify the authoritative answers and several recursive resolvers, keep the old hosting available during the transition, and treat a short TTL as a planning aid rather than a downtime guarantee.

The common mistake is lowering TTL at the same moment as changing the address. That helps future lookups, but it does not recall answers that other systems already cached. The safer plan separates preparation, the destination change, and the decision to retire the old server.

01 / Understand the authoritative and cached views

TTL means time to live. For DNS records it is expressed in seconds and tells caching resolvers how long they may retain an answer. A value of 300 is five minutes; 3,600 is one hour; 86,400 is one day.

ISC’s nameserver explanation distinguishes an authoritative server, which answers from the zone data it serves, from a recursive resolver, which finds answers for clients and can reuse cached results. This distinction gives you two different questions during a move:

• Authoritative view: has the DNS provider published the intended record?
• Recursive view: what answer is this particular resolver returning to its users now?

A dashboard save is useful evidence, but it is not the same observation as either query. Record the hostname, type, answer, TTL, server queried and time. That small log is easier to reason about than repeatedly refreshing a browser and guessing which layer changed.

Amazon Route 53’s TTL guidance describes the trade-off: shorter TTLs make updates visible sooner to resolvers that refresh more frequently, while longer TTLs allow more cache reuse and fewer authoritative queries. There is no single best value for every record.

02 / Identify the records that actually control the website

Before editing, export the zone if your provider supports it and save the exact existing values. Build a small change list for the bare domain, the www hostname and any other hostname included in the move. Ask the new host for its required record values rather than copying a tutorial’s example address.

Keep the change narrow. Do not delete mail, domain-verification or certificate-related records simply because the new hosting panel presents a shorter example zone. A website move is a poor moment to combine unrelated cleanup with routing changes.

For Cloudflare, the current TTL documentation says proxied records use an uneditable Auto TTL of 300 seconds. DNS-only records have configurable TTLs, with Auto also set to 300 seconds. The origin address and the public proxy address are different observations; our Cloudflare Proxied vs DNS-only guide explains that routing choice.

If you also intend to change the registrar or nameservers, pause and write a separate plan. Our domain transfer vs DNS change guide helps separate those operations.

03 / Lower TTL before the change window

Choose a temporary value your provider supports and your operations team accepts. For example, 300 seconds can be a useful planning value for a scheduled website-record change. It is an example, not a requirement to force on every provider or managed record.

AWS’s stale-record troubleshooting guidance explicitly notes that changing TTL does not accelerate an answer already cached under the old value. Apply the lower TTL, verify that the authoritative servers serve it, and allow at least the previous TTL interval before changing the destination, adding operational margin where needed.

Write down both TTL changes and destination changes as separate events. If preparation did not happen early enough, adjust the move window or plan for a longer period with both hosting environments available. Repeatedly lowering the value further is not a substitute for the missing preparation time.

Do not present the interval as a global completion deadline. Provider publication, local caches, application behaviour and failures can complicate the observed result. The cutover still needs monitoring.

04 / Query the source and the caches separately

Use read-only queries to compare the same hostname and record type at different servers. With dig available, these examples inspect A records. Replace the example hostname and authoritative nameserver with values for your own zone.

# Find the domain's nameservers
dig example.com NS

# Query one actual authoritative server directly
dig @ns1.example.net www.example.com A +norecurse

# Compare two public recursive resolvers
dig @1.1.1.1 www.example.com A
dig @8.8.8.8 www.example.com A

The BIND dig manual documents server selection and query options. Keep the full output so you can inspect response status, answer and authority sections, TTLs and flags. For the direct query, check that the response is authoritative for the requested name; a referral is not the record answer you were looking for.

On Windows with the DnsClient PowerShell module, Microsoft documents Resolve-DnsName with explicit name, type and server parameters:

Resolve-DnsName -Name www.example.com -Type A -Server 1.1.1.1 -DnsOnly

Repeat for AAAA when relevant and inspect the alias path if the hostname uses CNAME. Compare all authoritative servers assigned to the zone, not just one. Queries from two public resolvers are samples; they do not prove that every visitor worldwide has the same result.

05 / Make the destination change with a rollback plan

Before the window, confirm that the new hosting environment is ready for the real hostname: certificate, site configuration, content, redirects and application dependencies. Use the host’s supported preview or testing procedure. Testing an IP address alone does not establish that the named HTTPS site is ready.

• Save the previous records and the approved replacement values.
• Identify who will make the change and who can reverse it.
• Decide which errors or failed workflows would trigger rollback.
• Plan how forms, orders, uploads and other writes remain consistent during overlap.
• Keep the old hosting accessible while transition checks continue.

Change only the approved destinations and confirm authoritative answers first. Then sample recursive resolvers and test the real site over HTTPS. Check a representative page, a redirect and a business-critical workflow, such as submitting an enquiry. Use safe test data and check where it arrives.

If rollback is needed, restore the recorded values and verify them again. Plan for overlap during rollback too: some clients may already have the newer destination cached. DNS reversal also does not undo an order, upload or database edit made on the new system. Reconcile those writes separately before treating the old environment as current.

06 / Diagnose disagreements rather than waiting blindly

New hostnames have another complication: negative caching. RFC 2308 describes cached NXDOMAIN and no-data responses, with negative-cache timing carried through the zone’s SOA information. Creating a record after a failed lookup does not necessarily make that resolver retry immediately. Inspect the response status and authority section instead of looking only for an A-record TTL.

Cache clearing has limited scope. Google Public DNS documents a Flush Cache tool for its own service. It does not purge every ISP, browser or device. Use provider-specific troubleshooting when appropriate, but do not build the migration around the assumption that you can flush the entire internet.

07 / Restore normal TTL after evidence supports it

Keep the temporary TTL while you investigate problems and observe representative traffic and workflows. Record the evidence needed to finish: expected authoritative answers, sampled resolver results, functioning HTTPS, successful application checks and an agreed plan for any remaining writes on the old host.

Once the move is stable and quick reversal is no longer a near-term requirement, restore an appropriate normal TTL. AWS’s best-practice guidance recommends temporarily shortening critical-record TTLs for changes and increasing them after the change works as expected. Preserve your before-and-after record list for future troubleshooting.

Retire the old hosting only after the migration owner approves it based on the transition evidence and business requirements. A successful lookup from your laptop is not enough to justify deleting the only remaining copy of uploads or cancelling a service that still receives traffic.

Frequently asked questions