DNS propagation stuck: how to verify globally

TL;DR

DNS "propagation" is really just TTL expiry plus caching: check the authoritative nameserver first (that is the truth), then check public resolvers worldwide to see who has picked it up. If the authoritative server shows the new record, you are done and just waiting on TTL; if it shows the old one, the change never applied. Most "stuck propagation" is a change made at the wrong nameserver.

Error / query

DNS propagation stuck: how to verify globally

Use this skill when

• You changed a DNS record and some users still see the old value hours later
• You need to prove to someone that the change is live (or is not)
• A migration depends on the new record being visible everywhere
• You suspect the change was made at the wrong DNS provider

Not for this skill when

• Nothing resolves at all; that is an outage, not propagation
• The record is correct everywhere but the app misbehaves; the problem is not DNS
• You are waiting on domain registration or nameserver delegation changes; those take up to 48h regardless

Steps

Step 1: Ask the authoritative nameserver directly

dig +short example.com @ns1.exampledns.com

Expected: the new IP; the authoritative server is the source of truth, replace ns1.exampledns.com with your domain's real nameserver.

Step 2: Find which nameservers are actually authoritative

dig +short NS example.com

Expected: the NS list; if this does not match where you made the change, you edited the wrong provider and nothing will ever propagate.

Step 3: Check what public resolvers see

for r in 8.8.8.8 1.1.1.1 9.9.9.9; do echo -n "$r: "; dig +short example.com @$r | head -1; done

Expected: the new IP from all three; mixed old/new means TTL has not expired everywhere yet.

Step 4: Check the TTL on the record

dig +noall +answer example.com | head -2

Expected: the second field is the remaining TTL in seconds; that number is literally how long the wait is.

Step 5: Verify from multiple geographies

curl -s 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' -H 'accept: application/dns-json' | head -c 400

Expected: JSON with the new IP; this queries from Cloudflare's edge, a different vantage point than your local resolver.

Variant phrasings

"How long does DNS propagation take"

As long as the old TTL; if the TTL was 3600, expect up to an hour. Lower the TTL to 300 a day before a planned change.

"DNS checker shows different results worldwide"

Normal during the TTL window; worry only if the authoritative server (step 1) shows the wrong value.

"Changed DNS but nothing happened"

You almost certainly edited records at a provider that is not authoritative; step 2 catches this in ten seconds.

Why it happens

Resolvers cache records for the TTL duration, so "propagation" is just caches expiring one by one. It feels stuck when the TTL was long, when someone cached the old value just before your change, or when the change went to the wrong nameserver entirely.

Edge cases and pitfalls

• Browsers and OSes cache DNS too; a correct dig plus a broken browser means clear the local cache, not the DNS.
• Negative caching: a failed lookup gets cached too, so a typo'd record poisons resolvers for the negative TTL.
• Some ISPs ignore TTLs and cache longer; you cannot fix that, only wait or ask users to switch resolvers.
• CNAME at the apex is invalid; if the root domain "propagates" everywhere except some resolvers, check for that.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ME2quoDDh69krQzoKhyE9g