Why do I get different results from different DNS servers?

Understanding DNS Result Variations

When querying different DNS servers for the same domain, you sometimes get different results. This variation is normal during DNS propagation but can also indicate misconfiguration or specific routing scenarios. Understanding why results differ helps you troubleshoot issues and maintain DNS consistency.

Common Reasons for Different Results

1. DNS Propagation in Progress

Most common cause when changes are recent.

Scenario:

• You change DNS record
• Different servers have new vs. old data
• Some show updated IP, others show old IP

Timeline:

Time 0: Change made at authoritative nameserver
  ↓
Time 0-1 hour: Some resolvers see new data
  ↓
Time 1-4 hours: Most resolvers see new data
  ↓
Time 4-24 hours: Majority see new data
  ↓
Time 24-48 hours: All resolvers see new data (complete propagation)

Example:

$ dig @8.8.8.8 example.com A +short
192.0.2.2  # New IP

$ dig @1.1.1.1 example.com A +short
192.0.2.1  # Old IP still cached

$ dig @authoritative.ns.example.com example.com A +short
192.0.2.2  # Authoritative has new data

# All three are correct—propagation in progress

Resolution: Wait for propagation to complete (24-48 hours)

2. TTL (Time To Live) Differences

How TTL works:

• Each DNS response includes TTL (time until data expires)
• Each resolver respects TTL before refreshing
• Different resolvers may have cached at different times

Scenario:

Resolver A cached record 10 minutes ago, TTL=3600 (expires in 3590 seconds)
Resolver B cached record 1 hour ago, TTL=3600 (expires in 2590 seconds)
Resolver C cached record just now, TTL=3600 (expires in 3600 seconds)

Record changed 30 minutes ago, but:
- Resolver A still has old cached data (2 hours 50 min left)
- Resolver B just refreshed and has new data
- Resolver C will get new data on next expiration

Resolution: Wait for all TTLs to expire (determined by the TTL value set on the record)

3. Resolver-Specific Caching Behavior

Different resolvers have different cache strategies:

• Google Public DNS (8.8.8.8): Relatively quick cache refresh
• Cloudflare (1.1.1.1): Balanced caching strategy
• OpenDNS: Custom caching based on usage
• ISP Resolvers: Often cache more aggressively
• Corporate DNS: May override TTL or cache custom records

Scenario:

ISP DNS server: Caches for 6 hours regardless of TTL
Public DNS: Honors TTL exactly
Authoritative: Always has current data

Result: Different answers from different servers

4. Authoritative Nameserver Misconfiguration

Multiple nameservers, not all synchronized:

Setup:

example.com    NS    ns1.example.com
example.com    NS    ns2.example.com
example.com    NS    ns3.example.com

Problem:

• ns1 has new data
• ns2 and ns3 have old data (zone transfer failed)

Result:

$ dig @ns1.example.com example.com
192.0.2.2  # New data

$ dig @ns2.example.com example.com
192.0.2.1  # Old data

$ dig @ns3.example.com example.com
192.0.2.1  # Old data

Resolution: Ensure zone transfers working properly:

# Check zone transfer
dig @ns1.example.com axfr example.com

# If fails, check nameserver logs
# Verify TSIG keys if using signed transfers
# Manually trigger zone transfer
rndc retransfer example.com

5. Split-horizon DNS

Intentional configuration to return different answers based on query origin.

Scenario:

Internal networks: Receive 10.0.0.1
External networks: Receive 192.0.2.1
Same domain, different IPs

Configuration:

# Internal view
zone "example.com" {
  view "internal" {
    match-clients { 10.0.0.0/8; };
    record { example.com A 10.0.0.1; };
  };
};

# External view
zone "example.com" {
  view "external" {
    match-clients { any; };
    record { example.com A 192.0.2.1; };
  };
};

Expected behavior:

From internal network:
$ dig example.com
192.0.2.1  # WRONG - outside

$ dig example.com
10.0.0.1   # CORRECT - inside

Note: This is intentional and correct for your network

6. Resolver Geographic Distribution

Different servers in different locations:

Large DNS networks (Google, Cloudflare) have servers worldwide.

Scenario:

Google DNS in US:  Returns Server A's IP
Google DNS in EU:  Returns Server B's IP  (load balancing)
Google DNS in Asia: Returns Server C's IP

Same domain, different IPs (on purpose)

This is intentional: Load balancing and geographic optimization

# Check from different locations
# Use GeoDNS checker tools
# All results are correct for their respective regions

7. Conditional Forwarding

Organization forwards certain domains to specific servers:

Scenario:

ISP resolver:
  - example.com → forward to example.com's authoritative
  - internal.example.com → forward to 10.0.0.1

Result: Different servers used for different queries

8. DNS Caching at Multiple Levels

Caching happens at multiple layers:

Browser cache
  ↓
OS resolver cache
  ↓
ISP resolver cache
  ↓
Recursive resolver cache (8.8.8.8, 1.1.1.1, etc.)
  ↓
Authoritative nameserver (no cache, always current)

Each layer can have different data:

dig example.com  # Uses browser/OS cache (likely old)
dig @8.8.8.8 example.com  # Uses Google's resolver (may be old)
dig @authoritative.ns example.com  # Hits authoritative (always current)

When Different Results Indicate Problems

Problem 1: Authoritative Servers Diverged

Symptom:

• Different answers from different authoritative nameservers
• Not propagation-related (been more than 48 hours)

Diagnosis:

# Query each authoritative nameserver
dig @ns1.example.com example.com A
dig @ns2.example.com example.com A

# Results should match
# If they don't: Zone transfer problem

Fix:

# Trigger zone transfer
rndc retransfer example.com

# Check zone sync status
dig example.com SOA  # Check serial numbers match

# Verify nameserver communication
# Check logs on secondary nameservers
tail -f /var/log/named.log

Problem 2: Persistent Stale Data

Symptom:

• Some resolvers return old data 24+ hours after change
• Propagation should be complete

Diagnosis:

# Check authoritative nameserver (should have new data)
dig @authoritative.ns example.com A
# Should show new IP

# Check problematic resolver
dig @stale.resolver.com example.com A
# Shows old IP

# Check TTL on authoritative
dig example.com A
# Look at TTL value

Possible causes:

• Resolver overriding TTL (caching longer than specified)
• Resolver bug or misconfiguration
• Manual cache entry that won't expire

Fix:

• Contact resolver operator (ISP, corporate IT)
• Clear cache on resolver (if you manage it)
• Use different resolver temporarily

Problem 3: Inconsistent Zone Files

Symptom:

• Same record exists in zone file but with different values
• Queries show varying results

Diagnosis:

# Check zone file directly
cat /etc/named.zones/example.com.zone

# Look for duplicate records with different values
grep "example.com A" example.com.zone

Fix:

• Remove duplicate records
• Verify zone file syntax
• Reload zone
• Verify propagation

Investigating Different Results

Diagnostic Steps

Step 1: Verify authoritative has current data

dig @ns1.example.com example.com A +short

Step 2: Check multiple public resolvers

dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short
dig @208.67.222.222 example.com A +short

Step 3: Check TTL values

dig example.com A
# Look for TTL in response
# High TTL means caching delays

Step 4: Clear local cache and retry

# Clear browser cache
# Clear OS DNS cache (ipconfig /flushdns on Windows)
# Re-query

Step 5: Check propagation globally

# Use online propagation checkers
# Shows results from 200+ locations worldwide
# What's My DNS, WhatsMyDNS, etc.

When Different Results Are Expected

1. During DNS Changes

Normal: Different results during 24-48 hour propagation window

2. Geographic Load Balancing

Normal: Different IPs returned for different locations (intentional)

3. With TTL Expiration

Normal: Some resolvers see new data before others expire their cache

4. Round-Robin Balancing

Normal: Multiple A records return in different order:

$ dig example.com A
# First query returns: 192.0.2.1, 192.0.2.2
# Second query returns: 192.0.2.2, 192.0.2.1

Best Practices

1. Check authoritative first: Always verify authoritative has data you expect
2. Use multiple public resolvers: Check with Google, Cloudflare, and OpenDNS
3. Monitor global propagation: Use online tools for geographic verification
4. Lower TTL before changes: Speeds up propagation
5. Allow 24-48 hours: Don't assume problem until propagation window passes
6. Document expectations: Record original data before changes
7. Test locally first: Make changes in test environment before production

Tools for Investigating

# Compare resolvers
for ns in 8.8.8.8 1.1.1.1 208.67.222.222; do
  echo "=== $ns ==="
  dig @$ns example.com +short
done

# Check authoritative
dig @authoritative.ns example.com A

# Trace DNS path
dig +trace example.com

# Check global propagation
# Use: whatsmydns.net, dns.google, etc.

Conclusion

Different results from different DNS servers are usually temporary and normal during propagation. By understanding the causes—TTL caching, propagation in progress, and geographic distribution—you can:

• Distinguish between normal variation and actual problems
• Diagnose real DNS inconsistencies
• Plan DNS changes to minimize disruption
• Monitor propagation effectively
• Troubleshoot DNS issues systematically

Most importantly: always check the authoritative nameserver to verify what the "truth" is, then allow time for changes to propagate globally before declaring a problem.