What this check shows
DNS propagation describes the period during which recursive resolvers do not yet agree on a recently changed answer. It is driven mainly by caching and TTL values rather than a single synchronized global update.
This checker queries independent resolvers in parallel and highlights whether answers are consistent, partially propagated, absent or failing.
When to use it
- Nameserver or DNS provider migrations
- Website and CDN cutovers
- Email infrastructure changes
- Incident response and support evidence
How to read the result
- A mix of old and new answers normally indicates cached data that has not expired everywhere.
- SERVFAIL can point to broken delegation, unreachable authoritative servers or DNSSEC validation problems.
- A timeout from one resolver is less significant than the same failure across many independent providers.
Command examples
Use these dig commands when you need to compare DNSRadar with a terminal check or collect evidence for a DNS provider.
dig example.com A +short
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A +noall +answerTroubleshooting focus
Use this page when a DNS change is visible from one network but not another, after moving hosting, changing nameservers, adding a CDN or updating email records. The useful signal is not only whether a record exists, but whether independent resolvers return the same answer, stale answers or resolver-specific errors.
Practical examples
- After moving a website to a new server, compare the A and AAAA records before turning off the old host.
- After changing nameservers, check NS and SOA records to see whether recursive resolvers still know the previous delegation.
- When a CDN migration appears inconsistent, compare CNAME and A answers and look for old targets in only a subset of resolvers.
- If SERVFAIL appears during propagation, check DNSSEC and authoritative nameservers instead of waiting blindly.
Common mistakes
Treating one successful lookup as global propagation
Your ISP resolver may refresh before the resolvers used by customers, mail senders or monitoring systems.
Changing DNS repeatedly during cache expiry
New changes can make it harder to tell whether old answers are cached or authoritative.
Ignoring IPv6
A stale AAAA record can affect IPv6-capable users while IPv4 appears correct.
Shutting down old infrastructure too early
Users behind stale recursive caches may still be sent to the previous service.
Propagation workflow
Confirm the authoritative answer
Check the nameservers that host the zone first. If authoritative DNS still returns the old value, the issue is not propagation; the zone data is wrong or has not been published.
Compare independent recursive resolvers
Use global public resolvers to see whether the old answer is cached in only some networks or whether every resolver still agrees on the same value.
Separate stale data from failure states
An old A record, NXDOMAIN, SERVFAIL and timeout point to different problems. Treat DNSSEC SERVFAIL or broken delegation as configuration issues, not normal propagation.
Keep the old service online until caches expire
If some resolvers still return the old answer, users behind those caches may still reach the previous host until TTL expiry.
What patterns mean
All resolvers agree
The record is globally consistent for the sampled resolver set. If users still fail, check HTTP, TLS, CDN routing, firewall rules or local resolver policy.
Most resolvers agree, a few differ
This often indicates cached data, anycast policy differences or one resolver holding an older answer. Check the differing resolver, response value and latency.
Mixed old and new values
This is the classic propagation pattern after a planned change. Keep both old and new infrastructure safe until important caches have expired.
SERVFAIL on validating resolvers
Investigate DNSSEC, DS records at the parent zone, unreachable authoritative nameservers or broken delegation. Waiting alone may not fix it.
NXDOMAIN everywhere
The hostname is probably missing, delegated incorrectly or queried at the wrong name. Confirm the exact FQDN and authoritative zone.
Support evidence
When you share a DNSRadar result with a DNS provider, hosting company or client, include the context that explains what changed. A propagation screenshot without the old value, new value and change time is much harder to diagnose.
- Domain or FQDN checked, including whether it is the root domain or a subdomain such as www.
- Record type checked, because A, AAAA, CNAME, MX and TXT can propagate differently after the same migration.
- Expected new value and previous value, so stale resolver answers can be identified quickly.
- Resolver name, IP, location and status for any outlier that disagrees with the majority.
- Approximate time of the DNS change and the previous TTL configured before the migration.
Questions
Can DNS propagation be forced?
You generally cannot flush third-party recursive caches. Lowering TTL before a planned change can shorten the transition.
When is propagation complete?
For practical purposes, it is complete when the resolvers relevant to your users consistently return the intended answer.