Different DNS servers return different answers for the same domain mainly because each resolver caches records independently and refreshes them on its own schedule — so after a change, some still serve the old value while others already have the new one. The other common causes are entirely intentional: GeoDNS and CDN load balancing deliberately hand different visitors different IPs, round-robin records shuffle their order, and split-horizon setups answer internal and external clients differently. It becomes an actual problem only in two cases — answers still disagree 48+ hours after a change (broken propagation) or your authoritative nameservers disagree with each other (a failed zone transfer). To find the real answer, always query the authoritative nameserver directly: dig @ns1.example.com example.com A +short.
That paragraph is the summary an AI overview will give you. The rest of this article is what it can't: a map of every reason two resolvers diverge, how to tell "normal and temporary" apart from "actually broken," and the exact dig commands to prove which answer is the truth.
Understanding DNS Result Variations
When you query different DNS servers for the same domain, you sometimes get different answers. Most of the time this is normal — the result of independent caching, an in-progress change, or a deliberate load-balancing design. Occasionally it signals a real fault. The skill is telling the two apart, and knowing which server holds the authoritative truth.
The five root causes at a glance
Every "different answers" situation traces back to one of these. Use the table to classify what you're seeing before you start digging:
| Cause | Why the answers differ | Normal or problem? | How to confirm |
|---|---|---|---|
| Caching / TTL | Each resolver cached the record at a different time and holds it until its copy's TTL expires. One has the new value, another still serves the old one. | Normal (temporary) | dig example.com A and read the TTL; compare across resolvers |
| GeoDNS / CDN load balancing | The authoritative side intentionally returns different IPs based on the resolver's location, to steer users to the nearest or least-loaded edge. | Normal (by design) | Query from multiple regions; all answers map to the same service |
| Propagation in progress | A record changed recently; the new value hasn't reached every resolver yet. Different resolvers are at different points in the rollout. | Normal for 24-48h | Query the authoritative NS — it has the final value; wait out the TTL |
| Filtering / split-horizon | A resolver deliberately answers differently by client: internal vs. external views, content filtering, or a captive-portal block page. | Intentional (by policy) | Compare an internal query with an external/public-resolver query |
| ISP hijack / stale override | An ISP resolver caches beyond the TTL, rewrites NXDOMAIN to an ad page, or returns a filtered IP — overriding what the authoritative server says. | Problem | Compare ISP resolver vs. @1.1.1.1 vs. authoritative; enable DNSSEC |
The rest of the article walks each cause in depth, then shows how to diagnose the two genuine failure modes.
Common Reasons for Different Results
1. Caching and TTL: the everyday cause
Every recursive resolver keeps a cache. When it looks up a record, it stores the answer for the number of seconds specified by the record's TTL (Time To Live), then discards it and fetches a fresh copy on the next request. Because resolvers don't all cache at the same instant, their copies expire at different times:
Resolver A cached the record 10 minutes ago (TTL=3600) -> valid ~50 more minutes
Resolver B cached it 59 minutes ago (TTL=3600) -> expires in ~1 minute
Resolver C has never cached it -> fetches fresh on the next query
Record changed 30 minutes ago:
- Resolver A: still serving OLD value (cached before the change)
- Resolver B: about to refresh and pick up the NEW value
- Resolver C: already returns the NEW value
All three are behaving correctly. The old answer isn't "wrong" — it's a still-valid cached copy. This is why the single most useful pre-change action is lowering the TTL (to 300 seconds, say) a day or two ahead of a planned edit: it shrinks the window in which resolvers can disagree.
# The TTL in the answer counts DOWN each second until the resolver refreshes
$ dig @8.8.8.8 example.com A
;; ANSWER SECTION:
example.com. 1784 IN A 192.0.2.9 # 1784s left on Google's cached copy
$ dig @1.1.1.1 example.com A
;; ANSWER SECTION:
example.com. 120 IN A 192.0.2.1 # Cloudflare's copy expires in 120s
2. GeoDNS and CDN load balancing (intentional differences)
Large sites rarely live at a single IP. Content delivery networks and GeoDNS services answer the same query with different IPs depending on where the asking resolver sits, so each user is steered to the nearest or least-loaded edge server. Because Google's resolver, Cloudflare's resolver, and your ISP's resolver are in different data centers, they legitimately receive different edge IPs.
Resolver querying from US-East -> 192.0.2.10 (Virginia edge)
Resolver querying from EU-West -> 198.51.100.7 (Frankfurt edge)
Resolver querying from Asia -> 203.0.113.5 (Singapore edge)
Same hostname, different IPs, all correct.
This is not a fault and there is nothing to "fix." If you're verifying such a domain, don't expect global agreement — expect every answer to route to the same working service.
3. Propagation in progress
The most common cause when a change is recent. After you edit a record at the authoritative nameserver, the new value spreads only as fast as each resolver's cached old value expires. Until then, some resolvers show the new data and others show the old.
Time 0: Change made at authoritative nameserver
Time 0-1h: Some resolvers already show new data
Time 1-4h: Most public resolvers have refreshed
Time 4-24h: Majority worldwide see new data
Time 24-48h: Effectively complete
$ dig @8.8.8.8 example.com A +short
192.0.2.9 # New IP
$ dig @1.1.1.1 example.com A +short
192.0.2.1 # Old IP still cached
$ dig @ns1.example.com example.com A +short
192.0.2.9 # Authoritative has the new value — this is the truth
# All three are correct: propagation is simply mid-flight.
Resolution: wait out the TTL (up to 24-48 hours in the worst case), then re-check. See how long DNS propagation takes for the detailed timeline.
4. Split-horizon DNS and conditional forwarding
Split-horizon (or split-view) DNS is an intentional configuration that returns different answers based on who is asking. A company typically serves a private address to devices inside its network and a public address to everyone else — same hostname, two answers, both correct for their audience.
# BIND views: internal clients get the private IP, everyone else the public one
view "internal" {
match-clients { 10.0.0.0/8; };
zone "example.com" { type master; file "internal/example.com.zone"; }; # A 10.0.0.1
};
view "external" {
match-clients { any; };
zone "example.com" { type master; file "external/example.com.zone"; }; # A 192.0.2.1
};
# Same query, different answer depending on your network:
$ dig example.com +short # from the corporate LAN
10.0.0.1
$ dig @1.1.1.1 example.com +short # from anywhere public
192.0.2.1
Conditional forwarding is a related mechanism: an organization forwards queries for certain zones to specific servers (for example, internal.example.com to an internal resolver while everything else goes to public authoritative servers). Both are by design.
5. ISP caching quirks and hijacking (the one to watch)
Public resolvers like 8.8.8.8 and 1.1.1.1 honor TTLs faithfully. Some ISP resolvers don't: they cache longer than the TTL to save bandwidth, rewrite NXDOMAIN (nonexistent-domain) responses to point at a search or ad page, or apply content filtering that returns a block-page IP instead of the real one. That is why a domain can resolve cleanly on Cloudflare yet fail — or point somewhere unexpected — on your ISP's resolver.
# ISP resolver disagrees with a public resolver AND the authoritative server:
$ dig @192.0.2.53 example.com +short # ISP resolver
198.51.100.99 # a filtering / redirect IP
$ dig @1.1.1.1 example.com +short
192.0.2.9
$ dig @ns1.example.com example.com +short
192.0.2.9 # authoritative agrees with Cloudflare, not the ISP
Fix: switch to a public resolver, and enable DNSSEC validation so tampered answers are rejected rather than trusted. This overlaps with the mechanics of a DNS poisoning attack, where forged answers are injected into a resolver's cache.
6. Multiple caching layers
Caching happens at several levels between you and the authoritative server, and each layer can hold a different value:
Browser cache
|
OS resolver cache (stub)
|
ISP / recursive resolver cache (8.8.8.8, 1.1.1.1, ...)
|
Authoritative nameserver (never caches — always current)
A plain dig example.com (or a browser visit) may read a stale local copy, while dig @8.8.8.8 example.com skips your local caches and asks Google directly. Flushing the OS cache forces a fresh lookup:
ipconfig /flushdns # Windows
sudo dscacheutil -flushcache # macOS
sudo systemd-resolve --flush-caches # Linux (systemd-resolved)
When Different Results Actually Indicate a Problem
Two situations are genuine faults rather than normal variation.
Problem 1: Authoritative servers disagree with each other
A domain lists several nameservers (ns1, ns2, ns3). They stay in sync via zone transfer. If a transfer fails, the primary has the new data and a secondary keeps serving old data — and this never resolves on its own.
# Query each authoritative nameserver directly — they MUST match:
$ dig @ns1.example.com example.com A +short
192.0.2.9
$ dig @ns2.example.com example.com A +short
192.0.2.1 # <- diverged: zone transfer is broken
# Compare SOA serial numbers; the secondary's should equal the primary's:
$ dig @ns1.example.com example.com SOA +short
$ dig @ns2.example.com example.com SOA +short
Fix: repair the transfer. On BIND, force a re-sync and check the logs:
rndc retransfer example.com
tail -f /var/log/named/named.log
# Verify TSIG keys if you use signed transfers; confirm ns2 can reach ns1 on TCP/53
Problem 2: Persistent stale data past the TTL
If a resolver still serves old data well beyond the record's TTL (and 48+ hours after the change), the resolver — not your zone — is at fault: it may be ignoring TTLs, holding a manual cache entry, or simply buggy.
# Authoritative has the new value:
$ dig @ns1.example.com example.com A +short
192.0.2.9
# The problem resolver is still stuck on the old one long after the TTL should have expired:
$ dig @stale.resolver.example example.com A +short
192.0.2.1
Fix: contact the resolver operator (ISP or corporate IT), clear its cache if you manage it, or route users to a compliant public resolver in the meantime.
Diagnostic Playbook
Work these steps in order — they move from "what is the truth" outward to "who disagrees and why":
Step 1 — Establish the truth at the authoritative server. It never caches:
dig example.com NS +short # find the nameservers
dig @ns1.example.com example.com A +short # the source-of-truth answer
Step 2 — Compare public resolvers. Any difference here is caching or GeoDNS, not a zone fault:
for ns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
printf '%-16s ' "$ns"; dig @"$ns" example.com A +short | tr '\n' ' '; echo
done
Step 3 — Read the TTLs. A high remaining TTL explains a slow-to-update resolver:
dig @1.1.1.1 example.com A # look at the number in the ANSWER section
Step 4 — Trace the full delegation path to see where an answer is coming from:
dig +trace example.com
Step 5 — Flush local caches and re-query to rule out browser/OS staleness (commands above).
Step 6 — Check global propagation with an online checker (whatsmydns.net, dns.google) that queries 200+ locations at once — the fast way to see a GeoDNS pattern or an incomplete rollout.
When Different Results Are Expected (not a bug)
- During a change — differences are normal for the 24-48 hour propagation window.
- GeoDNS / CDN — different IPs per region are intentional load balancing.
- TTL expiry timing — some resolvers refresh before others; brief disagreement is normal.
- Round-robin — multiple A records returned in a rotating order to spread load:
$ dig example.com A +short
192.0.2.1
192.0.2.2 # order may swap on the next query — both IPs are valid
- Split-horizon — internal vs. external answers are by design.
Best Practices
- Check the authoritative nameserver first — it is the only cache-free source of truth.
- Compare several public resolvers (Google, Cloudflare, Quad9, OpenDNS) before assuming a fault.
- Lower the TTL before planned changes (to ~300s) to shrink the disagreement window.
- Allow 24-48 hours before declaring a propagation problem.
- Enable DNSSEC so tampered or forged answers are rejected, not trusted.
- Monitor globally with a propagation checker to distinguish GeoDNS from stale caches.
- Record the original values before a change so you can tell old from new at a glance.
Conclusion
Different results from different DNS servers are usually temporary and normal — the product of independent caching and TTL timing, in-progress propagation, or deliberate GeoDNS and split-horizon designs. They point to a real problem in only two cases: your authoritative nameservers disagree with each other (a broken zone transfer), or a resolver serves stale data long past the TTL (an ISP or resolver fault).
The one habit that resolves nearly every "which answer is right?" question: query the authoritative nameserver directly, treat that as the truth, and give changes time to propagate before calling anything broken.