Diagnosing DNS Propagation Delays During a Host Migration

Goal

When you migrate a subdomain between hosts and the new platform says the domain is "correctly configured," but visiting the site still shows the old host's error page, figure out fast whether this is a real misconfiguration or just DNS caching — without guessing or re-editing a record that was already correct.

The Scenario

• Migrating notes.example.com from one host (e.g. Netlify) to another (e.g. Vercel).
• Updated the CNAME record at the registrar to point to the new host.
• The new host's dashboard confirms the domain as a valid, correctly-configured custom domain.
• Visiting notes.example.com still resolves to the old host's default/error page.

The instinct at this point is to assume the new record didn't save, or that something in the new host's setup is wrong. Usually neither is true yet.

Root Cause

The record at the registrar (the authoritative source) is correct. The problem is that your local machine's resolver — or your ISP's resolver, or a resolver somewhere between you and the authoritative server — cached the old answer before the change was made, and that cached answer's TTL hasn't expired yet.

Every DNS answer ships with a TTL (Time To Live, in seconds): how long a resolver is allowed to reuse that answer before it's required to re-query. Until the TTL expires, the resolver has no way of knowing the record changed — it will keep confidently handing back the stale answer, and it isn't wrong to do so; it's just doing exactly what TTL tells it to do.

Diagnostic Commands

| Command | What it tells you | |---|---| | dig NS example.com | Which nameservers are authoritative for the domain — confirms whether DNS is managed at your registrar, or still by the platform you're migrating away from. | | dig CNAME notes.example.com | What your local resolver currently believes the record is, plus the remaining TTL on that cached answer. | | dig @<nameserver> CNAME notes.example.com | Bypasses every layer of caching by asking the authoritative server directly. |

1. Confirm who's actually authoritative

dig NS example.com

;; ANSWER SECTION:
example.com.        3600    IN      NS      ns1.registrar-dns.com.
example.com.        3600    IN      NS      ns2.registrar-dns.com.

If these point to wherever you actually edited the record (your registrar, or a DNS provider like Cloudflare), you've confirmed changes there are the real source of truth — not the platform you're leaving.

2. Check what your resolver currently has cached

dig CNAME notes.example.com

;; ANSWER SECTION:
notes.example.com.   187     IN      CNAME   old-host-app.netlify.app.

187 is the remaining TTL in seconds — this cached answer still has about three minutes left before the resolver is required to re-check it. Seeing the old target here doesn't mean your change failed; it means this particular resolver hasn't re-asked yet.

3. Ask the authoritative server directly, bypassing the cache

dig @ns1.registrar-dns.com CNAME notes.example.com

;; flags: qr aa rd; QUERY: 1, ANSWER: 1
;; ANSWER SECTION:
notes.example.com.   300     IN      CNAME   cname.vercel-dns.com.

The aa flag (authoritative answer) is the detail that matters here — it confirms this response came straight from the server that owns the record, not from any cache along the way. If this already shows the new target, the change is live and correct at the source. Anything still showing the old target anywhere else downstream is pure propagation delay, not a configuration problem.

The Key Insight

When a DNS change "isn't working," check the authoritative server directly before touching the configuration again:

• Authoritative answer is already correct → the change worked. What you're seeing elsewhere is caching delay, not misconfiguration. Re-editing the record now just restarts a new TTL countdown on top of the one already running, making things slower, not faster.
• Authoritative answer is still wrong → the change didn't actually save, or you edited the wrong record or the wrong zone. Now it's worth digging into the actual configuration.

Practical Takeaway

Note the TTL as soon as you make a DNS change, before you go looking for a problem:

• Low TTL (60–300s, typical of Vercel, Namecheap, and Cloudflare defaults) → propagation is usually a matter of minutes. If it's been hours and the authoritative record is already confirmed correct, the holdup is almost certainly a stubborn resolver cache — including your own browser or OS DNS cache — not the DNS configuration itself.
• High TTL (3600s+, common on older or default registrar records) → propagation can genuinely take an hour or more. This is exactly why lowering the TTL before a planned migration (then raising it back afterward) is standard practice: it puts a hard cap on how long the transition window can drag on.

TTL isn't just metadata — it's the answer to "how long do I actually need to wait" before treating something as broken. Check it before spending time troubleshooting the wrong problem.