Why a DNS Checker Shows Different IPs in Different Locations

You run a global DNS check and the results come back inconsistent: New York sees one IP, Frankfurt sees another, Singapore a third. Your first instinct is that something is broken or that the record has not finished propagating. Usually it is neither. A well-run service deliberately hands out different addresses in different places. This guide explains the four main reasons a lookup legitimately varies by location, and how to tell an intentional difference from a real problem.

DNS was built to give context-specific answers

A DNS query does not have to return the same value every time. An authoritative nameserver can inspect where a request appears to come from and tailor the response. Layered on top is caching: every resolver between you and the origin may hold a slightly different snapshot. Together these produce the regional variation a global checker surfaces. The four causes below account for nearly all of it.

1. CDN and anycast routing

Content delivery networks are the most common reason. When you put a site behind a CDN such as Cloudflare, Fastly, or Akamai, the CDN answers DNS queries with the address of a nearby edge location. A user in Paris is steered to a European edge; a user in Tokyo to an Asian one. The goal is to shorten the round trip, so a lower latency connection wins.

# Same hostname, different edge IPs depending on where you ask from
$ dig +short cdn-hosted-site.com   # from US
151.101.1.57

$ dig +short cdn-hosted-site.com   # from EU
151.101.65.57

Many CDNs combine this with anycast, where the same IP address is announced from many data centers at once and the network routes you to the closest one. In that case the checker may show the same IP everywhere, yet each region is actually talking to a different physical server. Both patterns are healthy.

2. GeoDNS

GeoDNS is DNS that chooses its answer based on the geographic location of the resolver asking. Instead of one A record for everyone, the zone holds several, each mapped to a region or country, and the nameserver returns the one that matches.

Companies use GeoDNS to send visitors to the nearest data center, to serve region-specific content, or to comply with data residency rules. The result on a global checker looks like scattered IPs, but each is correct for its region.

One subtlety: GeoDNS decides based on the resolver's location, not the end user's. If someone in Spain uses a US-based public resolver without EDNS Client Subnet, GeoDNS may hand them a US answer. This is normal and expected behavior, not a fault.

3. Load balancing and weighted records

Some zones return multiple A records and rotate or weight them to spread traffic across servers. With simple round-robin, the order of the returned addresses changes between queries. With weighted DNS, a larger server gets a larger share of answers. A global checker sampling many resolvers at once will naturally capture different members of the pool.

$ dig +short example.com
198.51.100.10
198.51.100.11
198.51.100.12
# A later query reorders the same set, or returns a weighted subset

Here the differences are not really about geography; they are about distribution. Each IP in the set is a valid destination.

4. Propagation lag after a change

The one cause that is a transient issue: you recently changed a record, and the old value is still cached somewhere. Resolvers hold the previous answer until its TTL expires, so for a window of time some regions show the new IP and others show the old one.

This looks similar to GeoDNS at a glance, but there is a clear tell. With propagation lag, the "different" IPs are specifically your old and new values, and the split resolves itself as the TTL runs out. With GeoDNS or a CDN, the differences are stable and persist indefinitely.

How to tell intentional from broken

Work through these questions and the cause is usually obvious.

1. Did you just change the record? If yes and you are seeing exactly two distinct values (old and new), it is propagation. Wait for the TTL and recheck.
2. Are the IPs in a known CDN range? Look them up. Addresses belonging to Cloudflare, Fastly, Akamai, or a cloud provider point to CDN or anycast routing, which is expected.
3. Are the differences stable over repeated checks? Stable, region-correlated differences mean GeoDNS or a CDN. Differences that shrink over time mean propagation.
4. Do all regions still reach a working site? If every returned IP serves your site correctly, the variation is by design, even if it surprised you.

A quick way to classify an IP

A reverse lookup or a WHOIS on the returned address often names the network operator, which tells you immediately whether you are looking at your own origin or a CDN edge.

$ dig -x 151.101.1.57 +short
# Returns a Fastly-controlled name, confirming CDN routing

$ whois 151.101.1.57 | grep -i orgname
# Names the owning network

When different IPs really are a problem

Variation is only a genuine fault in a few cases:

• One region returns an address that does not respond at all, while others work. That points to a dead pool member or a stale record that should have been removed.
• A change has sat for far longer than its TTL and some resolvers still show the old value. That suggests a TTL that was never lowered before the change, or a misconfigured record at one nameserver.
• Your nameservers disagree with each other. If two authoritative servers for the same zone return different answers, the zone is out of sync, not geo-aware.

Reading your results with confidence

The key mindset shift is that a global DNS check is meant to show variation when the architecture creates it. The job is interpreting the pattern, not eliminating it. Run your domain through the Valla DNS propagation checker to see every region's answer at once, then use the questions above to classify what you find. If the split traces to a CDN, our guide on Cloudflare proxied versus DNS-only explains why you see edge IPs; if it traces to a recent change, our guides on TTL strategy and flushing your cache will tell you how long the lag should last. Different IPs in different places is often the sign of a system working exactly as designed.