Why DNS Results Differ by Location

A domain can return different DNS answers to people in different places without either answer being wrong. DNS providers and CDNs can use geographic or latency-aware routing to direct users toward regional infrastructure. Recursive resolvers may also have different cached values, and corporate networks can use split-horizon DNS to give employees an internal answer while the public internet receives a different one. The address you see is therefore a result of hostname, record type, resolver, location, and time. A single lookup cannot represent every possible view, so comparisons should preserve that context.

Geographic and latency-based DNS

A geo-aware provider evaluates each query and selects an answer according to configured regions, network measurements, or policies. It may return a nearby CDN edge or a regional application endpoint. The provider generally sees the recursive resolver that sent the query; that resolver may be far from the end user or serve many users. Some systems use EDNS Client Subnet to include partial network context, but support and privacy behavior vary. Consequently, a lookup from one location does not always describe what a particular person in that location receives through their chosen ISP or corporate resolver.

Caching creates another source of variation. One resolver may still hold a previous answer while another has already fetched the new one. Lowering a TTL does not retroactively shorten a value already cached with an older TTL. Local operating systems and applications can add their own cache behavior as well. If a record was changed recently, note the previous TTL and when the change was published. Give caches time to expire, and query the authoritative nameservers to verify the zone itself before concluding that an update failed.

How to investigate a discrepancy

Compare the exact same hostname and record type through named resolvers, and write down where each query ran and when. Check the authoritative nameservers to see what the zone currently publishes. If only recursive answers differ, consider cache age, resolver policy, or geography. If authoritative servers disagree, inspect provider synchronization and delegation. If internal and external users see different values, ask whether split-horizon DNS is intentional. Finally, test the service endpoint itself; different DNS addresses can both lead to healthy application copies, or identical answers can both fail for reasons unrelated to DNS.

• Record resolver, query location, hostname, record type, answer, and timestamp.
• Compare authoritative data before changing records again.
• Allow for TTL caching and negative caching after DNS edits.
• Check for CDN and geo-routing rules that intentionally vary answers.
• Test actual service health independently of name resolution.

What different answers do not prove

Different public answers do not by themselves mean DNS is hijacked, a domain is compromised, or an origin server has moved. They can be normal design behavior. Likewise, matching answers do not prove that all visitors use the same path, because caches and application layers may differ. Look for corroborating evidence: provider configuration, published maintenance notices, known CDN ranges, and application telemetry. Describe findings narrowly, especially when the address is shared infrastructure serving many customers.

To understand the mechanisms behind distributed answers, see how CDNs use DNS and DNS load balancing. The domain lookup tool provides a useful public DNS snapshot; repeat the same query from a second resolver if you are comparing views. Keeping the query context alongside the result transforms an apparent contradiction into evidence about routing policy, caching, or configuration.

Compare answers without erasing the context

A useful comparison table should include query time, resolver address, location or network, hostname, record type, response code, TTL, and answer values. If the results differ, add whether the resolver is public, corporate, or provider-managed and whether the domain uses a CDN. Repeat the query later to determine whether the difference is stable policy or a temporary cache split. If the same resolver returns different answers at different times, check for load balancing and health-based failover. If two resolvers differ consistently, investigate geolocation or split-horizon settings. This context turns “DNS is inconsistent” into a specific observation that the DNS provider can reproduce and explain. When reporting the comparison, avoid saying that one answer is globally correct unless you have confirmed the domain's routing policy. Explain whether each answer came from an authoritative server or a recursive cache, and preserve the TTL shown with it. If a CDN intentionally returns regional endpoints, the right question is whether each endpoint is healthy for its region, not whether every resolver returns one identical address. This distinction keeps an expected routing design from being escalated as a DNS outage.