Back to tutorials
Tutorial

DNS Propagation Troubleshooting Tutorial (2026): Fix Wrong IP, NXDOMAIN, and “Site Not Found” After a Hosting Move

DNS propagation troubleshooting tutorial (2026) to fix wrong IP, NXDOMAIN, and SSL errors after a hosting migration—fast checks and safe fixes.

By Anurag Singh
Updated on Sep 12, 2026
Category: Tutorial
Share article
DNS Propagation Troubleshooting Tutorial (2026): Fix Wrong IP, NXDOMAIN, and “Site Not Found” After a Hosting Move

Most “my site is down” reports right after a migration aren’t server failures. They come from DNS cache, wrong nameservers, missing records, or a proxy/CDN still pointing at the old host. This DNS propagation troubleshooting tutorial gives you a repeatable way to find which layer is lying, fix it without guesswork, and confirm the internet resolves the right destination.

You’ll use a few commands (dig, curl, openssl), a couple of browser checks, and a short checklist. The same approach works for VPS, dedicated servers, and shared hosting moves.

What you’re troubleshooting (and what “propagation” really means)

“Propagation” gets blamed for everything. In practice, DNS breaks in a small number of predictable ways:

  • Wrong delegation: the domain still points at old nameservers (or the registrar hasn’t actually applied the change).
  • Wrong records: A/AAAA/CNAME still targets the old IP (or a parking/holding page).
  • Resolver cache: your ISP, office network, or device is holding old answers until TTL expires.
  • Multiple answers: split-brain results from mixed NS sets, stale glue, or mismatched zone files.
  • Non-DNS issues that look like DNS: HTTPS redirects, HSTS, CDN/proxy misrouting, or a server vhost that doesn’t match the Host header.

Your job is simple: identify which resolver returns which record. Then fix the earliest failure point in the chain (registrar delegation → authoritative DNS → caching resolvers → client).

Before you touch DNS: confirm the new server is ready

Don’t touch DNS until you know the destination behaves correctly. If the new host serves the wrong site, DNS changes just amplify the problem.

Step 1: Confirm the new IP serves the right site

From your laptop (or any Linux shell), hit the new IP while forcing the Host header:

NEW_IP="203.0.113.10"
DOMAIN="example.com"

curl -I --resolve ${DOMAIN}:443:${NEW_IP} https://${DOMAIN}
curl -I --resolve ${DOMAIN}:80:${NEW_IP} http://${DOMAIN}

What “good” looks like:

  • 200, 301, or 302 that matches your expected behavior
  • No redirects back to the old hostname
  • No default “Welcome”/placeholder vhost

If you’re moving WordPress and were updating during the move, a stuck maintenance state can masquerade as a DNS problem. Keep this nearby: WordPress stuck in maintenance mode tutorial.

Step 2: Validate TLS on the new server (without waiting for DNS)

If HTTPS is part of the cutover, confirm the new IP presents a certificate for your hostname:

openssl s_client -connect ${NEW_IP}:443 -servername ${DOMAIN} -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

If the certificate doesn’t include your domain in SAN, browsers will complain even after DNS is perfect. For a clean Let’s Encrypt setup on the destination, use: VPS SSL setup guide.

Hosting note: if you’re moving from shared hosting to your own server, you can avoid many edge cases with a VPS you control. A HostMyCode VPS gives you stable IP ownership, rDNS options for mail, and direct control over DNS and TLS.

DNS propagation troubleshooting tutorial: a step-by-step isolation workflow

This is the workflow. Run it in order.

Don’t jump straight to “flush DNS” until you know where the break is.

Step 1: Check the registrar delegation (NS records)

Start with delegation. Ask the parent zone (the TLD) which nameservers are authoritative for your domain.

This tells you whether the registrar change is actually live.

DOMAIN="example.com"
dig +short NS ${DOMAIN}

If you still see the old nameservers, this isn’t an A record “propagation” issue. It’s a delegation issue. Fix it at your registrar, then wait for the TLD to publish the new NS set.

Also watch for a classic footgun: mixed NS sets. If you see two old nameservers and two new ones, resolvers can hit either side. That creates random-looking results.

Step 2: Identify the authoritative nameservers and query them directly

Next, query each authoritative nameserver directly. This bypasses caching resolvers.

You’re checking what your DNS provider is serving right now.

dig +short NS ${DOMAIN}
# Example output:
# ns1.dnsprovider.tld.
# ns2.dnsprovider.tld.

NS="ns1.dnsprovider.tld"
dig @${NS} ${DOMAIN} A +noall +answer

Repeat for:

  • @ns2 ...
  • www.${DOMAIN} (A or CNAME)
  • AAAA if you publish IPv6

How to read the result:

  • If authoritative DNS is wrong: fix the zone at your DNS provider. Waiting won’t help.
  • If authoritative DNS is right: move on to caching resolver checks.

Step 3: Compare multiple public resolvers (cache reality)

Public resolvers give you a fast snapshot of “what many people are getting.” Query a few and compare:

DOMAIN="example.com"

# Cloudflare
DIG1=$(dig @1.1.1.1 +short A ${DOMAIN})
# Google
DIG2=$(dig @8.8.8.8 +short A ${DOMAIN})
# Quad9
DIG3=$(dig @9.9.9.9 +short A ${DOMAIN})

echo "1.1.1.1: ${DIG1}"
echo "8.8.8.8: ${DIG2}"
echo "9.9.9.9: ${DIG3}"

If they disagree, you’re usually looking at one of these situations:

  • Inconsistent data across authoritative NS (provider replication delay or misconfigured secondaries)
  • Recently changed records that are still cached because TTL was high
  • Split-horizon DNS (common on corporate networks)

Step 4: Inspect TTL and see how long caches might persist

Pull the TTL from a resolver so you know what you’re up against:

dig @1.1.1.1 ${DOMAIN} A +noall +answer

Example answer:

example.com.  300  IN  A  203.0.113.10

That 300 is 5 minutes. If TTL was 86400 (1 day) before you moved, some users will stick to the old IP long after you “fixed” things.

For the next migration, drop TTL ahead of the cutover. Use: DNS TTL reduction tutorial.

Step 5: If only you see the old site, isolate client vs network caches

If your phone on LTE shows the new site but your office Wi‑Fi shows the old one, assume an office resolver cache. Change that assumption only after you test.

Quick isolation checks:

  • Browser bypass: use a private window and retest.
  • Switch resolver: temporarily set your device DNS to 1.1.1.1 and 8.8.8.8.
  • Query your current resolver: identify it, then run dig against it directly.

Find your current resolver on Linux:

resolvectl status | sed -n '1,120p'

Then query it directly:

RESOLVER_IP="192.0.2.53"
DOMAIN="example.com"

dig @${RESOLVER_IP} ${DOMAIN} A +noall +answer

If your resolver returns the old IP while public resolvers return the new one, you’ve found the problem.

Your options are simple: wait for TTL, flush the resolver (if you manage it), or switch resolvers temporarily.

Common failure patterns (with fast fixes)

These are the DNS-shaped outages you’ll see most often during a hosting move. Each includes the quickest path to a fix.

Pattern A: NXDOMAIN for root domain or www

Symptom: dig returns NXDOMAIN, and browsers show “Server not found.”

Likely causes: missing zone, wrong domain in DNS provider, or wrong nameserver delegation.

Fix:

  • Verify delegation: dig +short NS example.com
  • Query the authoritative NS: dig @ns1 ... example.com SOA
  • Ensure the zone exists and has at least A/AAAA/CNAME records for the hostnames you use.

Pattern B: Root works, www doesn’t (or the opposite)

Symptom: example.com loads, www.example.com fails.

Likely causes: you updated only one record; www points to an old CNAME; or AAAA exists for one name only.

Fix: check both names explicitly:

dig @1.1.1.1 example.com A +noall +answer
dig @1.1.1.1 www.example.com A +noall +answer
dig @1.1.1.1 www.example.com CNAME +noall +answer
dig @1.1.1.1 example.com AAAA +noall +answer
dig @1.1.1.1 www.example.com AAAA +noall +answer

If you don’t serve IPv6 yet, don’t publish AAAA records “just because.” A broken IPv6 path can create slow, intermittent timeouts. Those often look like random downtime.

Pattern C: DNS is correct, but you still see the old site

Symptom: all resolvers return the new IP, but your browser shows old content.

Likely causes: CDN/proxy caching, local hosts file override, HSTS pinning to a different hostname, or the new server is reverse proxying to the old origin.

Fix checklist:

  • Check your /etc/hosts (Linux/macOS) or C:\Windows\System32\drivers\etc\hosts (Windows) for overrides.
  • Check whether a CDN is in front (Cloudflare “orange cloud”, other proxies). Purge cache or update the origin IP.
  • Fetch headers with curl -I https://example.com and look for CDN headers or unexpected redirects.

Pattern D: “Site not secure” after cutover

Symptom: DNS points to the new server, but HTTPS fails or shows the wrong certificate.

Likely causes: the new server serves a default certificate, SNI/vhost mismatch, or AutoSSL/Let’s Encrypt hasn’t issued yet.

Fix:

  • Validate SNI at the IP (see the openssl s_client command earlier).
  • Issue/renew the cert on the new host.
  • If you’re on cPanel/WHM and AutoSSL is failing, use: cPanel AutoSSL troubleshooting tutorial.

Hands-on: safe DNS cutover procedure you can reuse

If you’re mid-migration and want the least drama, use this sequence. It assumes you already tested the destination with curl --resolve.

  1. Lower TTL ahead of time (ideally 12–24 hours before): set A/AAAA/CNAME TTL to 300 seconds.
  2. Freeze risky changes: pause WordPress plugin/theme updates and bulk content edits until the cutover is stable.
  3. Update DNS records: change A/AAAA/CNAME to the new IP/target.
  4. Verify authoritative answers: query each authoritative NS until they all serve the new records.
  5. Verify public resolvers: check 1.1.1.1, 8.8.8.8, 9.9.9.9.
  6. Confirm HTTP and HTTPS behavior: curl -I, then a browser test.
  7. Raise TTL after stability: once you’re satisfied, raise TTL to something sane (3600–14400 is common).

If you want a fuller migration runbook (including rollback steps for SSL and email), use: Server migration tutorial.

Advanced checks that save hours (still practical)

Trace delegation issues with +trace

+trace walks the chain from root → TLD → authoritative. It’s also the quickest way to prove exactly where the break happens.

dig +trace example.com NS

If the trace ends at nameservers you don’t recognize, your registrar delegation still hasn’t changed. Another common cause is updating the wrong domain/account.

Spot split answers caused by “old glue” on child nameservers

If you run your own nameservers (for example, ns1.example.com) and changed their IPs, you must update glue at the registrar.

If you don’t, resolvers may keep trying the old IP for your authoritative DNS.

Quick hint: if dig +trace shows the right NS names but queries time out intermittently, suspect glue first.

Check for CAA records blocking certificate issuance

CAA can stop Let’s Encrypt/AutoSSL from issuing a certificate on the new server.

dig @1.1.1.1 example.com CAA +noall +answer

If your CAA policy only allows a different CA, issuance will fail until you update it.

Don’t delete CAA casually if you use it for policy. Adjust it intentionally.

Operational checklist: what to capture during an incident

If you support client sites or reseller accounts, collect outputs you can paste into a ticket as-is.

  • Domain + affected hostname(s): example.com, www.example.com
  • Expected IP and old IP
  • dig +short NS example.com output
  • dig @ns1 ... example.com A output (authoritative truth)
  • dig @1.1.1.1 ... and dig @8.8.8.8 ... output (cache reality)
  • curl -I https://example.com headers (redirects/proxy hints)
  • openssl s_client summary if HTTPS is involved

With these in hand, you can align everyone on the same facts fast.

If you migrate client sites often, consistency beats heroics. Standardize the destination environment so DNS and SSL changes behave predictably. Start with a managed VPS hosting plan for steady defaults, or choose a self-managed HostMyCode VPS when you want full control over DNS, certificates, and cutover timing.

FAQ

How long should DNS propagation take in 2026?

It depends on TTL and resolver caching. With TTL at 300 seconds, many users update within minutes, but some ISP caches can lag longer. Always verify with direct authoritative queries.

Public resolvers show the new IP, but my ISP doesn’t. What should I do?

Query your ISP resolver directly to confirm it’s caching the old record. If you can’t flush it, switch your device/router DNS temporarily (1.1.1.1/8.8.8.8) or wait for TTL expiry.

Why does HTTPS fail even after DNS points to the new server?

The new server might be serving a default certificate, the vhost/SNI is misconfigured, or certificate issuance is blocked (CAA). Test with openssl s_client against the new IP using -servername.

Should I keep both old and new A records during a move?

No. Multiple A records will round-robin traffic, which breaks sessions and can split writes (especially for WordPress/WooCommerce). Use a clean cutover plus a rollback plan instead.

Summary: a clean way to stop guessing

DNS feels random until you separate delegation, authoritative answers, resolver caches, and client behavior.

Query authoritative nameservers first. Validate public resolver results next. Chase local caching and HTTPS issues last.

If you want a destination that’s easier to validate (stable IP, predictable stack, and straightforward SSL), move sites onto a HostMyCode VPS and keep your DNS cutovers boring.