Multi-Region A Record Propagation Checker

Test A DNS propagation across multiple worldwide DNS servers in North America, Europe, Asia, and Oceania.

Quick select:
Countries:
Select at least one country.
Your IP: 216.73.216.246
Domain Type Primary NS Responsible Person Serial Refresh Retry Expire Minimum TTL
Name Server IP Address TTL
Domain Type TTL Record Value
Trace Result
Domain Type Record Status
Domain Type Record Status

A Record Propagation Checker

An A record maps a hostname to an IPv4 address. Browsers use it to find your website, so it is the first record to check after moving a site to new hosting, replacing a load balancer or pointing a domain at a different server.

This checker asks your domain's authoritative name servers for the A record from eight regions and lists every IPv4 address each region receives. The answer comes straight from those servers, so you see what your DNS provider is publishing right now, before any ISP cache is involved.

What the A Record Results Tell You

Every region shows the new IP

The change is published everywhere. If some visitors still reach the old server, their ISP's resolver is holding a cached copy. It expires when the old record's TTL runs out.

One region still shows the old IP

Your authoritative servers are not answering the same way. Usually one name server has missed the zone update, often a secondary server whose zone transfer failed. Run the NS check to see which servers the domain uses, and ask your DNS provider to resync them.

Regions return different IPs on purpose

Geo-DNS and latency-based routing, such as AWS Route 53 routing policies or Azure Traffic Manager, and many CDNs hand each visitor an address close to them. Different IPs per region are expected for these services and do not mean the change is stuck.

Several IPs, or no record at all

Several A records are normal for round-robin or redundant hosting, and every region should list the same set. If every region reports no record, check whether the name is an alias: a name with a CNAME has no A record of its own. Look it up with the CNAME check instead.

Moving a Site Without Downtime

Lower the record's TTL to a few minutes at least one full old-TTL period before the move, then switch the IP. When all eight regions show the new address, raise the TTL again. Keep the old server running until the old TTL has passed, so nobody with a cached answer lands on a dead address.

How This Check Works

Eight Regions Across Six Continents

Every check is run from South Asia (Mumbai), Southeast Asia (Singapore), East Asia (Tokyo), the Middle East (Dubai), Europe (London), North America (N. Virginia), South America (São Paulo) and Oceania (Sydney). Each location reports on its own, so one slow or unreachable region never hides the results from the others.

Response Time and Fastest Region

Each region asks the authoritative name servers directly and times only that one exchange. Authoritative servers do not answer from a cache, so every figure is a fresh lookup from that part of the world. The Fastest Region in the summary panel is the lowest of those times in the current check.

Ticks, Crosses and the Map

A green tick means the region received an answer and shows it. A red cross means it got none; hover the marker to see why, such as NXDOMAIN, a timeout or no record of that type. The world map below the results marks each region with its outcome, so you can tell whether a problem is limited to one continent.

Global Propagation Troubleshooting & Common Fixes

After migrating to a new server or hosting provider, some global locations resolve the new IP while others return the old address. When authoritative nameservers answer with conflicting data, it usually means secondary (slave) nameservers have not received zone updates due to delayed AXFR/IXFR zone transfers, firewall restrictions, or an unchanged SOA serial number.

How to fix: Inspect your domain's SOA Record to verify that the serial number has incremented on all authoritative nameservers. If you manage your own BIND or PowerDNS cluster, force a zone notification and reload across all secondary nameservers. If using a managed cloud DNS provider, confirm that all assigned nameservers show identical zone versions.

When six or seven regions return green checkmarks with valid responses, but one region (such as São Paulo, Sydney, or Dubai) displays a red cross or connection timeout, this indicates regional packet loss, firewall geo-blocking, or routing blackholes between that region's network and your authoritative nameservers.

How to fix: Verify that your DNS provider or firewall does not geo-block specific countries or ASN IP ranges on UDP and TCP port 53. If using anycast DNS (Cloudflare, AWS Route 53, NS1), this can indicate a localized routing flap at a specific regional point of presence (PoP). Check your DNS provider's status page for regional degradation.

Seeing different IP addresses across North America, Europe, and Asia is frequently expected behaviour rather than an error. Modern Content Delivery Networks (Cloudflare, Fastly, Akamai) and cloud load balancers use latency-based routing, Geo-DNS, or Anycast BGP to deliver traffic to the nearest geographic edge node.

How to fix: If you use a CDN, WAF, or geo-routing policy, disparate IP addresses confirm that geographic traffic steering is functioning correctly. If you do not use a CDN and only own a single web server, check whether an erroneous round-robin A record was accidentally left configured in your DNS management console.

Check Another Record Type

DNS Info extension for Chrome is now available

Install