How to Check DNS from Different Locations

Updated

To check DNS from different locations, query the same hostname against resolvers in multiple regions and compare the returned A, AAAA, and PTR records along with their TTL values. This matters because the same domain can legitimately return different IP addresses depending on where the resolver sits — CDNs, geo-DNS, and anycast routing all produce location-dependent answers. Use a multi-location lookup tool such as Check-Host.net's DNS function when you need to confirm whether a DNS change has propagated, or to tell an intentional geo-routed answer apart from a stale cache.

Why the same domain resolves differently by location

A single DNS query only tells you what one resolver, in one place, currently believes. Several mechanisms make answers diverge:

  • Geo-DNS / latency-based routing — authoritative servers return different records based on the resolver's apparent location, sending users to the nearest datacenter.
  • CDNs and anycast — the same hostname maps to different edge IPs per region, and anycast advertises one IP from many locations.
  • Propagation delay — after you change records, resolvers worldwide update at different times, so some still serve the old answer.
  • Caching and TTL — each resolver holds records until the TTL expires, so a low TTL propagates faster than a high one.

Because of this, "the DNS is wrong" is usually one of three things: intentional geo-routing, a not-yet-expired cache, or a genuine misconfiguration. Multi-location lookups are how you tell them apart.

Running a multi-location DNS lookup

Check-Host.net provides a DNS tool that retrieves A, AAAA, and PTR records with TTL from nameservers around the world — the stated purpose is checking updates on DNS servers. The general workflow:

  1. Enter the hostname you want to resolve (for example, example.com).
  2. Select the DNS check rather than ping or HTTP, so you get records and TTL instead of reachability or page timing.
  3. Choose multiple check nodes across different countries or datacenters.
  4. Run the check and wait for each node to report.
  5. Compare the results — look at the returned IPs and the TTL on each.

Expected result: a table of per-node answers. Identical IPs everywhere suggest a single global answer; differing IPs suggest geo-routing or partial propagation; a mix of old and new IPs points to caching in progress.

Reading the output

Field What it tells you
A record IPv4 address the resolver returned
AAAA record IPv6 address, if published
PTR record Reverse lookup, useful for confirming what an IP maps back to
TTL Seconds remaining before that resolver re-queries — a countdown toward propagation

A TTL that is counting down toward zero on a node still serving the old IP tells you that node will refresh soon. A node already serving the new IP confirms the change has reached that region.

Interpreting differing answers

Once you have results from several locations, classify the pattern:

  • All nodes return the same IP — a single, globally consistent answer. No geo-routing in play.
  • Nodes return region-appropriate IPs consistently — intentional geo-DNS or CDN behavior. Not a fault.
  • Some nodes return the old IP, others the new one — propagation still in progress. Watch the TTLs; the laggards will catch up as caches expire.
  • One node returns something no other node does, and it persists — possible stale cache or a misconfigured authoritative server for that region.

The key distinction is between consistent regional differences (by design) and inconsistent answers for the same region (a problem).

Verifying a DNS change

After updating records, use multi-location lookups to confirm rollout:

  1. Note the TTL you set before the change — a lower TTL means faster global refresh.
  2. Query from several regions immediately after the change; expect a mix of old and new.
  3. Re-query periodically and watch nodes flip from old to new IP as their TTLs expire.
  4. When every node returns the new answer, propagation is effectively complete.

If a node still serves the old IP well past its TTL, that resolver may be holding a stale entry or ignoring the TTL — worth investigating separately.

Common pitfalls

  • Confusing DNS with ping or HTTP. A ping test measures reachability and latency; an HTTP check measures page response. Neither tells you which records a resolver holds. Use the DNS check specifically when the question is about records.
  • Assuming one lookup is representative. A single resolver's answer says nothing about what users elsewhere see.
  • Mistaking geo-routing for an error. Different IPs per region are often correct by design.
  • Ignoring TTL. Without checking TTL, you cannot tell whether a stale answer is about to expire or stuck.
  • Split-horizon DNS. Internal and external resolvers can intentionally return different answers for the same name — expected in some setups, confusing if you compare them without knowing.

For a broader view of whether a site is reachable versus merely slow, pair the DNS check with the site's ping and HTTP tools, since each answers a different question.