Why DNS Works in One Location but Fails in Another

DNS resolves fine from your browser. A user in a different country, or on a different ISP, can't reach your site. Or your uptime monitor — which checks from Frankfurt — shows the site up, while your US customers report errors.

Geographic DNS inconsistency is common and has several distinct causes. Here's how to identify which one you're dealing with.

The DNS Resolution Chain

Before diagnosing the issue, it's worth understanding why geographic differences occur at all. When someone looks up your domain, the query goes through:

1. Their local DNS cache (machine or router)
2. Their ISP's recursive resolver (or a public resolver like Google/Cloudflare if they've configured one)
3. The root nameservers → TLD nameservers → your authoritative nameserver

Each step in this chain is specific to that user's location and ISP. Different resolvers have different cached values, different cache ages, and different network paths to your nameservers.

Cause 1: DNS Propagation Still in Progress

The most common cause of geographic inconsistency after a DNS change: propagation isn't complete. Some resolvers have updated to the new record; others are still serving the old one based on their cached TTL.

# Test from multiple resolvers to see who has the new record
for resolver in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
    echo -n "$resolver: "
    dig yourdomain.com A @$resolver +short
done

If you see different IPs from different resolvers, propagation is in progress. This is expected and resolves on its own as TTLs expire. See DNS propagation taking too long? What to check first if the discrepancy persists beyond the TTL.

Cause 2: GeoDNS Serving Different Answers by Region

GeoDNS (geographic DNS) intentionally returns different IP addresses depending on where the query comes from. If you have a CDN, load balancer, or GeoDNS setup, this is by design — users in Europe hit EU servers, users in the US hit US servers.

If one of those regional endpoints is down while others are fine, DNS will appear to work from some locations and fail from others.

# Check what IP a specific DNS resolver returns
# Using a VPN or a resolver in the target region:
dig yourdomain.com A @resolver-in-affected-region +short

# Compare with your local result
dig yourdomain.com A +short

If they return different IPs, GeoDNS is operating. Check whether the IP serving the affected region is reachable:

curl -I --max-time 10 http://REGIONAL_IP --header "Host: yourdomain.com"

Cause 3: Resolver Caching a NXDOMAIN or Stale Record

Some ISP resolvers are poorly behaved — they cache NXDOMAIN (domain not found) responses longer than the specified TTL, or they refuse to re-query after a failed lookup within a certain window. Users on those ISPs continue getting failures even after the underlying issue is fixed.

You can't force a specific ISP's resolver to flush its cache. Options:

1. Wait for TTL expiry — the resolver will eventually re-query
2. Contact the ISP — in practice, not feasible for most operators
3. Ask affected users to switch to a public resolver — 8.8.8.8 or 1.1.1.1 as a workaround while the ISP resolver catches up

Cause 4: DNSSEC Validation Failure

If DNSSEC is enabled for your domain and there's a misconfiguration — expired signatures, wrong DS record after a nameserver migration — DNSSEC-validating resolvers return SERVFAIL. Non-validating resolvers continue working fine.

The result: users whose ISP or chosen resolver validates DNSSEC see failures, while everyone else is fine. Roughly 30–35% of global DNS traffic uses DNSSEC-validating resolvers, so this can affect a significant portion of users without obvious pattern.

# Check if DNSSEC is causing failures
dig yourdomain.com A +dnssec
# Look for: status: SERVFAIL and no 'ad' flag

# Test with DNSSEC validation disabled
dig yourdomain.com A +cd
# If this succeeds but the above fails, DNSSEC is the issue

See DNSSEC explained for website owners for the diagnostic and fix process.

Cause 5: Split-Horizon DNS (Internal vs External)

Corporate networks and VPNs sometimes run internal DNS servers that override public DNS. Users inside the corporate network get internal IP addresses; users outside get public IPs.

If a developer or IT administrator working inside the network changes internal DNS without updating external DNS (or vice versa), users inside and outside see different behaviour.

# Test from outside corporate VPN
dig yourdomain.com A @8.8.8.8 +short

# Test from inside VPN or office network
dig yourdomain.com A +short

If results differ, split-horizon DNS is in play. Coordinate the change between internal and external DNS configurations.

Cause 6: Anycast Routing Issues

Large DNS providers (Cloudflare, Route 53, Google) use anycast — the same IP address routes to different physical servers depending on where you are. If there's a routing issue affecting one anycast node in a specific region, users near that node see failures while everyone else is fine.

This is outside your control, but it's worth checking your DNS provider's status page when you see geographically isolated failures.

How to Check DNS From Multiple Locations Simultaneously

The fastest way to understand the scope of geographic DNS inconsistency is to check from multiple global locations at once. This is exactly what uptime monitoring does — but it needs to be running before the issue occurs to give you historical data.

Domain Monitor checks your domain from multiple global locations every minute and stores the results. When a DNS issue affects users in one region, you see exactly which monitoring locations are failing and which are passing — giving you the geographic scope immediately. Create a free account.

See why your domain points to the wrong server for a related diagnostic guide when DNS resolves but points to the wrong IP.

Also in This Series

• Nameservers vs DNS Records: What's the Difference?
• How to Change Nameservers Without Downtime
• DNSSEC Explained for Website Owners
• CAA Records Explained and Why They Matter for SSL
• How to Monitor Nameserver Changes Across Client Domains
• Registrar Lock vs Transfer Lock: What's the Difference?
• How to Prevent Domain Hijacking With Registrar Security