DNS cutover

48+ hours before: lower the TTLs

DNS records are cached for as long as their TTL (time-to-live) says. If your A record has a 24-hour TTL, a mistake takes up to 24 hours to fully wash out of caches. Fix this before you need it:

• Lower the TTL on every record you'll touch (A/AAAA, CNAME, and any records you're replacing) to 300 seconds.
• Do this at least 48 hours before the cutover — ideally a full week. The old, longer TTL has to expire out of caches first; lowering it the morning of the cutover does nothing.
• Write down the current values of every record you're changing. Screenshots of the DNS panel count.

Before the window: verify the target

• The new origin serves the site correctly when accessed directly (via its IP, staging hostname, or hosts-file override). Click through it like a visitor.
• TLS certificate is provisioned for the exact hostnames you're cutting over — apex (example.com) and www are different names and both need coverage. If your host provisions certificates automatically on first request, trigger that provisioning before the cutover, not during.
• Apex vs. www decision is made: one of them is canonical and the other redirects to it. Decide now, configure the redirect now, test it now.
• Email records are untouched and verified: MX, SPF, DKIM, DMARC. The most common DNS-cutover casualty isn't the website — it's email. Confirm mail still flows after any change, and never delete records you don't understand.

The cutover window

Pick a low-traffic window and have the rollback values (the screenshots from step one) open in another tab.

1. Update the records. Change A/AAAA (or CNAME) to the new target. Double-check you edited the right record — apex and www are the classic mix-up.
2. Verify with dig/drill from multiple vantage points. Your local resolver may still show the old value; check the authoritative nameservers directly, plus at least two public resolvers (e.g., 1.1.1.1 and 8.8.8.8). Propagation checkers that query from many locations are useful here.
3. Confirm HTTPS. Load https:// on the apex and on www. Check for certificate name mismatches and mixed-content warnings in the browser console.
4. Walk the critical flows on the live domain: homepage, signup, checkout, contact form. DNS is correct only when the site works through it.
5. Confirm email still flows — send a test message in and out if the domain handles mail.

After: raise the TTLs back

Once the cutover has been stable for 24–48 hours, raise TTLs back to their normal values (commonly 3600 seconds / 1 hour, or higher for stable records). Low TTLs left in place permanently just make your DNS slower and more fragile.

Rolling back

Because you lowered TTLs in advance, rollback is the cutover in reverse and takes minutes, not hours:

1. Restore the previous record values from your screenshots/notes.
2. Verify from the authoritative nameservers and public resolvers, same as the cutover.
3. Confirm the old site serves correctly and email still flows.
4. Diagnose calmly — the pressure is off, the old site is live, and you can re-attempt the cutover later.

Common failures

• Stale cache: "It works for me but not for them" is almost always caching — resolver cache, browser cache, or a CDN edge. Verify at the authoritative nameserver to know the truth.
• Certificate name mismatch: the cert covers www but not the apex (or vice versa). Provision for both before cutover.
• Mixed content: the page loads over HTTPS but pulls images, scripts, or fonts over HTTP. Browsers block or warn on these — find them in the console and fix the URLs.
• Email silently broken: MX/SPF/DKIM records deleted or altered during "cleanup." Verify mail flow explicitly after every DNS change.
• Changing the wrong record: editing the apex when you meant www. Read the hostname column twice before saving.