Global DNS Propagation

What it does

DNS Propagation sends the same query (A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, CAA or PTR) to 29 public recursive resolvers operated by networks in North and South America, Europe, Africa, Asia and Oceania, using dig with a 5-second timeout and a single try per resolver. Each row shows the answer that resolver currently holds in its cache, the remaining TTL and the response time, and the page flags whether all resolvers agree, highlights rows with a different value, and looks up the ASN and holder of every returned IP.

Technical background

The term propagation is misleading: DNS never pushes changes outward. When you edit a record, your authoritative servers start answering with the new data within seconds (or after the zone's NOTIFY and transfer, RFC 1996, reaches secondaries). Everyone else learns about it only when their recursive resolver's cached copy expires. Each answer carries a Time To Live (RFC 1035, clarified in RFC 2181), and a resolver that fetched www.example.com A 203.0.113.10 with TTL 86400 is entitled to keep returning it for up to 24 hours. What this tool shows is therefore a snapshot of cache state across many independent resolvers, each counting down its own TTL from the moment it last asked.

That is why planning matters more than waiting. Lower the TTL of the records you will change to 300 seconds at least as long before the change as the old TTL, typically 24 to 48 hours, so every cache picks up the short value. Make the change, confirm it here, and raise the TTL again afterwards. Some resolvers apply minimum or maximum TTL caps, and a few large ones prefetch popular names, so expect small deviations, but the TTL is the governing factor.

Negative answers are cached too. If someone queried a name before you created it, resolvers stored the NXDOMAIN or NODATA response for the duration defined by RFC 2308: the lesser of the SOA record's TTL and its MINIMUM field. A zone with SOA minimum 3600 means a freshly created TXT record can stay invisible to some resolvers for up to an hour. Check it with dig SOA example.com; the last number in the answer is the negative-caching value.

Changing name servers at your registrar is slower and works differently. The registry updates the delegation in the TLD zone quickly, but the NS records in the parent zone carry the TLD's TTL: 172800 seconds (two days) for .com and .net, and similar values for many ccTLDs. Resolvers that cached the old delegation keep using the old name servers until that expires, so keep the old provider serving identical records for at least 48 hours. If the zone is DNSSEC-signed, update the DS record in coordination with the new provider (RFC 6781 describes the rollover procedures) or validating resolvers will return SERVFAIL.

Because the queries come from the epcybertools server, large anycast resolvers answer from their instance nearest to that server; the location column describes the operator, not necessarily the physical node. Combined with independent ISP resolvers in different countries, the result is a reliable picture of whether stale caches remain.

Common errors and how to fix them

Problem The new IP is live on your DNS host, but half the resolvers still return the old one hours later.

Fix The old record had a long TTL such as 86400. Nothing can force remote caches to expire; keep the old server running or redirecting until the old TTL has fully elapsed, and next time lower the TTL to 300 a day or two before the change.

Problem A newly added TXT verification record shows 'No records found' on several resolvers.

Fix Those resolvers cached a negative answer from an earlier lookup. Wait for the SOA negative-caching time (the SOA MINIMUM or the SOA TTL, whichever is lower) to pass, and avoid testing the name before creating it.

Problem Records edited in the DNS panel never appear anywhere.

Fix The domain is probably delegated to different name servers than the panel you edited. Compare dig NS example.com with the provider's assigned name servers and either update the delegation at the registrar or make the change at the provider that is actually authoritative.

Problem After changing name servers, some resolvers return SERVFAIL.

Fix The domain is DNSSEC-signed and the DS record at the registrar still references the old provider's key. Add the new provider's DS (or remove DS before migrating), wait for the parent TTL, then retire the old key.

Problem A CNAME at the apex (example.com) breaks MX or TXT records.

Fix RFC 1034 forbids a CNAME coexisting with other records, and the apex always has SOA and NS. Use an A/AAAA record or your provider's ALIAS/flattening feature at the apex, and keep CNAME for subdomains like www.

Do it from the command line

# Same query the tool runs, against one resolver
dig @8.8.8.8 example.com A +noall +answer
# Ask the authoritative server directly (no cache involved)
dig @$(dig +short NS example.com | head -1) example.com A +norecurse
# Flush the local macOS resolver cache
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Query a specific public resolver
Resolve-DnsName example.com -Type A -Server 1.1.1.1 -DnsOnly
# Show the SOA (last value = negative caching TTL)
Resolve-DnsName example.com -Type SOA
# Clear the Windows DNS client cache
ipconfig /flushdns

# Follow the delegation from the root to the answer
dig +trace example.com A
# See the NS delegation held by the .com servers (parent TTL)
dig @a.gtld-servers.net example.com NS +norecurse
# Flush systemd-resolved cache
resolvectl flush-caches

Frequently asked questions