DNS Propagation Tutorial (2026): Low‑Downtime Domain Cutovers with TTL Planning, Record Checks, and Rollback

DNS doesn’t “propagate” like a file copy spreading across the internet. It expires. Resolvers cache old answers until the TTL runs out. That creates an awkward middle: some visitors hit the new server, while others still land on the old one.

This DNS propagation tutorial shows a low‑downtime cutover pattern. You’ll plan TTL changes, verify records before you flip them, and keep a rollback that is fast and boring.

The workflow below fits a WordPress move to a new VPS, a mail-provider switch, or a full reseller-stack migration.

You’ll rely on a few repeatable checks (dig, curl, openssl). You’ll also follow two habits that prevent most outages: lower TTL early, and only change what you can verify.

What you’re actually waiting for during “DNS propagation”

In practice, three timers affect what users see. You control only one.

Record TTL: how long resolvers cache an answer. You set this in your zone (e.g., 300 seconds).
Negative caching TTL: how long NXDOMAIN (non‑existent) responses get cached, controlled by the SOA minimum/negative TTL.
Resolver behavior: some resolvers cap TTLs, ignore very low TTLs, or cache aggressively behind the scenes.

That last item explains a common surprise: “some users are still on the old IP” even with a 60‑second TTL.

The goal isn’t perfect uniformity. You want a cutover window that is predictable enough to run.

Pre-flight checklist (do this before you touch TTL)

Most cutovers fail because the record inventory is wrong.

You think you’re changing one A record. Then you discover extra hostnames, legacy CNAMEs, or forgotten mail records.

Export your current zone from your DNS provider (screenshot + raw zone if available).
List every hostname that matters: @, www, api, mail, autodiscover, ftp, cpanel, whm, etc.
Confirm what is authoritative (nameservers). If you’re changing nameservers as part of the move, you’re doing a second, larger cutover.
Decide what “success” means: homepage loads over HTTPS, wp-admin works, mail sends/receives, API health endpoint returns 200.

Quick commands to map what’s live right now

Run these from your workstation (macOS/Linux) or from an admin shell on the server.

DOMAIN=example.com

dig +short NS $DOMAIN

dig +short A $DOMAIN

dig +short AAAA $DOMAIN

dig +short CNAME www.$DOMAIN

dig +short MX $DOMAIN

dig +short TXT $DOMAIN

If mail is part of the move, confirm SPF/DKIM/DMARC first. Also plan reverse DNS up front.

These guides are handy if email is in scope: SPF/DKIM/DMARC setup guide and reverse DNS setup guide (PTR).

DNS propagation tutorial step 1: Lower TTL safely (the day before)

Lower TTL early so existing caches “age out” before the change.

A pattern that works well:

T‑24 hours: drop A/AAAA/CNAME TTLs to 300 seconds (5 minutes).
T‑2 hours: optionally drop to 120 seconds if your provider allows it.
After cutover stabilizes: raise TTL back to 3600–14400 seconds to reduce resolver load.

Avoid TTL=0. Many platforms reject it. Others treat it as “cache anyway.”

Also adjust the SOA negative TTL if you’re creating new records

If you’ll create new hostnames (for example, adding staging.example.com during a migration), a high negative TTL can make “it doesn’t exist” stick for hours.

Many DNS providers expose this as “negative caching” or “minimum TTL.” If you can edit it, set it to 300 during the cutover window.

Restore it afterward.

Step 2: Build the new server so you can test it before DNS flips

You want the new host ready while the old one still serves real users. Treat the new host like production.

Make sure SSL is installed. Confirm the correct vhost/server block is active. Match PHP settings, and verify firewall rules.

If you’re moving to a VPS, the cleanest approach is usually a fresh instance plus a controlled migration. HostMyCode’s HostMyCode VPS plans fit this model because you control the cutover timing and can run both servers during the overlap.

Test over IP using a temporary hosts-file override

Before you touch DNS, force your own machine to resolve the domain to the new IP. Then test end to end.

Linux/macOS: edit /etc/hosts and add:

203.0.113.10  example.com www.example.com

Then verify:

curl -I https://example.com/
curl -I https://www.example.com/

Windows: edit C:\Windows\System32\drivers\etc\hosts (run editor as Administrator).

Remove the hosts entry after testing. If you forget it, you’ll misread every cutover check that follows.

Verify the certificate matches the hostname

openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

If you terminate TLS on Nginx/Apache directly, confirm the right server_name or vhost is being selected.

If you’re using a proxy in front for safer reloads, see this TLS termination setup guide.

Step 3: Decide your cutover type (IP change vs nameserver change)

Most migrations fall into one of two buckets. They behave differently under pressure.

Change A/AAAA/CNAME records at the same DNS provider. Lowest risk. Your authoritative nameservers don’t change.
Change nameservers (moving DNS hosting). This can create split-brain if the zones don’t match perfectly across providers. Only do it if you must.

For hosting migrations, prefer the first option.

Keep DNS where it is, flip records, and move DNS hosting later in a separate maintenance window (if you still want to).

Step 4: Cut over web traffic with an A/AAAA switch (with verification)

Keep the sequence tight. Change one thing, confirm it, then move on.

Changing a handful of records and “checking afterward” is how you end up guessing.

4.1 Update the A record for @ and www

Typical setups:

@ has an A record to your server IP
www is a CNAME to @ (preferred), or its own A record

Update the target IP (and AAAA if you use IPv6).

If you don’t actively manage IPv6, don’t publish AAAA records “just in case.” Broken IPv6 paths cause intermittent failures that look like random downtime.

4.2 Validate at the authoritative nameserver first

Query the authority directly. This confirms you changed the record you meant to change.

DOMAIN=example.com
NS=$(dig +short NS $DOMAIN | head -n1)

dig @$NS $DOMAIN A +noall +answer

dig @$NS www.$DOMAIN A +noall +answer

dig @$NS www.$DOMAIN CNAME +noall +answer

If the authoritative answer is correct but your local resolver still shows the old IP, you’re waiting on caching.

Don’t “fix” what isn’t broken.

4.3 Check a few public resolvers to estimate the spread

dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
dig @9.9.9.9 example.com A +short

A mix of answers during the TTL window is normal.

4.4 Confirm your site is serving the right content on the new server

Run this from a network that is not using your hosts-file override:

curl -sS -o /dev/null -w "HTTP %{http_code}  IP %{remote_ip}  Total %{time_total}\n" https://example.com/

If you get a 200 but the remote_ip is the old server, that resolver hasn’t switched yet.

If you’re migrating a full website stack with minimal downtime, pair the DNS steps with a structured move plan.

This guide follows the same approach: server migration tutorial for near‑zero downtime.

Step 5: Keep the old server alive during the overlap (and log it)

Even with a 300‑second TTL, plan for stragglers for a few hours. Keep the old server answering requests.

This matters most for checkouts, logins, and anything session-heavy.

Freeze content changes (or enable maintenance mode) if you can’t sync changes reliably.
Log both sides so you can tell when traffic has truly moved.

On the old server, watch requests by client IP and vhost:

sudo tail -f /var/log/nginx/access.log

Or for Apache:

sudo tail -f /var/log/apache2/access.log

If you want faster incident response during the cutover window, centralized logs make patterns easier to spot.

This tutorial shows a practical approach with rsyslog + logrotate: VPS log auditing tutorial.

Step 6: Cut over email carefully (MX changes are not the same as A changes)

Web cutovers can tolerate “some users hit old, some hit new.” Email is less forgiving.

Senders retry delivery, and receivers can reject mail if DNS and rDNS don’t line up.

If your migration includes mail:

Lower TTL for MX and related TXT (SPF/DKIM/DMARC) records ahead of time.
Verify rDNS (PTR) for the new outbound IP before you send mail.
Plan a window where both mailboxes exist (old and new), or use server-side sync.

For hands-on mail build steps, use: Mail server setup tutorial (Postfix + Dovecot).

If you’re troubleshooting spam or rejections post-cutover, this is the practical next step: email deliverability troubleshooting.

Step 7: Rollback plan (you need one even if you’re confident)

A rollback should be one DNS change you can do quickly and confidently.

That’s also why a nameserver move is a bad companion to a hosting migration.

Rollback checklist

Old server stays online and intact until you’ve observed stable traffic on the new host.
You know exactly which records you changed (A/AAAA/CNAME, possibly MX).
Old IP is documented and ready to restore.
You have a “what breaks” list: checkout, login, upload paths, cron jobs, webhooks.

If you need to roll back web traffic, set the A/AAAA records back to the old IP.

With the lowered TTL still in place, recovery is usually quick.

Step 8: Raise TTL back up and clean up after the cutover

Once traffic is consistently landing on the new server, restore TTL to a sensible value. For most production sites:

3600 seconds (1 hour) is a good default for A/AAAA/CNAME.
14400 seconds (4 hours) is fine for stable records you rarely change.

Then do the cleanup that prevents “mystery” issues a week later.

Remove temporary firewall openings you used for testing.
Verify renewals: Let’s Encrypt timers, AutoSSL, or your commercial certificate renewal path.
Confirm cron jobs and background workers exist on the new host.
Keep the old server for a short tail (often 48–72 hours), then retire it.

Practical diagnostics: common DNS cutover problems and quick fixes

You changed DNS but you still see the old site

Check your local cache: some OS/browser combos cache aggressively.
Query authoritative DNS (example above) to confirm the change is real.
Verify you didn’t update the wrong zone (common with multiple DNS providers).

Some visitors see HTTPS warnings after cutover

The new server may be serving a default certificate (wrong vhost/server block match).
There may be an old AAAA record pointing to a different host.

Check both A and AAAA, and confirm the SNI certificate with openssl s_client.

APIs or webhooks fail intermittently

Clients may resolve and cache DNS differently than browsers.
Your firewall might allow 443 but block a required port (or outbound requests).

If you suspect firewall issues post-migration, this walkthrough is built for real “I locked myself out” scenarios: Firewall troubleshooting tutorial.

When you should use a dedicated server instead of a VPS for migrations

A VPS fits most business sites, staging environments, and reseller stacks.

A dedicated server starts to make sense when you need consistent performance under sustained load, heavy IO, or stricter isolation.

Large WooCommerce stores with high checkout concurrency
Agencies hosting dozens of client sites with bursty traffic
Workloads with heavy image processing, video handling, or large caches

If you’re doing a major platform move and want headroom for the next 12–24 months, consider HostMyCode dedicated servers for the destination environment, then execute the same DNS cutover method.

Summary: a safe DNS cutover pattern you can repeat

Lower TTL 24 hours early.
Make the new server testable before DNS flips (hosts-file override + SSL verification).
Change records (not nameservers) for the main migration whenever possible.
Verify at the authoritative nameserver first, then check public resolvers.
Keep the old server alive during the overlap and watch logs.
Raise TTL back up after stabilization, then decommission cleanly.

If you want a clean migration runway—two servers running in parallel, time to test, and full control over the cutover—use a managed VPS hosting plan from HostMyCode.

You get a stable target to move to, and the workflow above keeps downtime close to zero.

If you’re planning a DNS cutover as part of a site move, build the destination first and test it end to end. HostMyCode VPS hosting gives you control over DNS timing, and migration help keeps the data transfer and validation steps tight.

FAQ

How long does DNS propagation take in 2026?

Usually as long as the TTL you set, plus some extra variance from resolver caching.

With a 300-second TTL, most users move within minutes, but stragglers can persist for hours.

Should I change nameservers during a VPS migration?

Not if you can avoid it. Flip A/AAAA/CNAME records at the current DNS provider first.

Move nameservers later as a separate change once the site is stable.

What TTL should I use for a planned cutover?

300 seconds is the practical sweet spot. It’s low enough for fast changes, but not so low that providers or resolvers behave unexpectedly.

Why do I still see the old IP after I changed DNS?

Your resolver may be caching the old record until TTL expiry. Or you’re querying a different DNS path than your visitors.

Confirm the authoritative answer with dig @$NS to rule out “wrong zone” mistakes.

Can I cut over email and web at the same time?

You can, but it increases risk.

If the business depends on email deliverability, do web first, then mail with careful SPF/DKIM/DMARC and rDNS validation.