If you have spent time on a troubleshooting bridge, you have heard the line: “It’s always DNS.”
It is not always DNS. Sometimes the database is down. Sometimes the load balancer is out of pool members. Sometimes a firewall rule changed at 4:57 p.m. and nobody wants to make eye contact.
But DNS earns its reputation because it sits near the beginning of almost every connection. Before a browser can connect to a web server, it needs an address. If two people ask for the same hostname and get different answers, the rest of the conversation gets messy fast. One user reaches an endpoint in Virginia. Another gets an address in Frankfurt. Someone else gets NXDOMAIN, SERVFAIL, or an address that should have disappeared yesterday.
That does not always mean DNS is broken. Different DNS answers can be expected, useful, and intentional. They are how many sites send users to nearby infrastructure, shift traffic away from unhealthy regions, and support private network paths. The hard part is that healthy DNS steering and broken DNS configuration can look similar from the outside.
If you are comparing answers, run the hostname through MakeTheInternetGo DNS Check. DNS is easier to reason about when you can see the exact answer, record type, resolver, region, and timing.
The short version
DNS can resolve differently around the world for a few good reasons:
- Recursive resolvers cache answers until the time to live, or TTL, expires.
- Negative answers, such as
NXDOMAIN, can also be cached. - DNS platforms can steer answers by geography, latency, weight, health, or failover policy.
- Anycast can send the same resolver or nameserver IP to different physical locations.
- EDNS Client Subnet can give authoritative DNS systems a partial view of the client network for better location-based answers.
- Split-horizon DNS can return one answer inside a private network and another answer outside it.
DNS can also differ because something is wrong:
- The parent zone and child zone do not agree about nameservers.
- A delegated nameserver is not actually authoritative for the zone.
- One authoritative server is stale while another is current.
- A CNAME is mixed with records that should not exist at the same name.
- DNSSEC validation fails for some resolvers.
- A global load-balancing policy has a bad rule, missing default, or misleading health check.
The question is not simply “why are the answers different?” The better question is “which layer made them different?”
DNS is a chain of decisions
DNS is not one database. It is a distributed naming system. RFC 1034 describes DNS as a system of names, resolvers, and nameservers rather than a single central service (RFC 1034).
In a normal lookup, your laptop or phone usually does not walk the whole DNS tree by itself. It asks a recursive resolver. That resolver might belong to your ISP, your company, your router, your operating system, or a public DNS service.
If the resolver already has a fresh answer, it can return that answer from cache. If it does not, it follows the DNS hierarchy until it reaches the authoritative nameservers for the domain. At the top of that hierarchy are the root nameservers. IANA lists 13 named root server authorities in the root zone, backed by many deployed server instances around the world (IANA Root Servers).
This is where the old joke “DNS is the root of all evil” gets its pun. The root is literally part of the lookup path. The joke is not fair to the root servers, which are usually not the problem, but it is a useful reminder: DNS has layers. A bad answer may come from cache, delegation, an authoritative server, resolver policy, network path, or a steering rule.
That path matters. When two regions disagree, do not jump straight to “propagation.” First ask:
- Did both tests ask the same resolver?
- Did those resolvers reach the same authoritative nameserver?
- Was the authoritative DNS service supposed to return different answers?
- Is one answer old, invalid, filtered, or intentionally regional?
Those questions turn a vague DNS problem into a smaller set of checks.
Cache explains many “it works here but not there” cases
The most common reason DNS looks inconsistent is caching.
DNS records include a TTL. RFC 1035 defines TTL as the number of seconds a resource record may be cached before it should be discarded (RFC 1035). Cloudflare’s DNS documentation explains the operational impact: TTL controls how long records are cached, which affects how long updates can take to reach users (Cloudflare TTL docs).
Suppose www.example.com changes from 192.0.2.10 to 192.0.2.20. The new value may be live at the authoritative DNS provider right away. But a recursive resolver that cached the old value can keep returning 192.0.2.10 until the TTL expires.
That resolver is not necessarily broken. It is doing what the old answer allowed it to do.
This is why “DNS propagation” is often the wrong mental model. In most cases, the new answer is not being pushed across the internet. It is already available from the authoritative side. The old answer is aging out of resolver caches.
Negative caching matters too. If a resolver asks for a hostname before the record exists, it may cache the negative answer. RFC 2308 defines how negative answers such as NXDOMAIN and no-data responses can be cached (RFC 2308). That means creating a missing record may not fix every resolver immediately.
Caching is good. It makes DNS fast and reduces load on authoritative nameservers. It also means DNS changes have a memory. If you need a fast cutover, lower TTLs before the change, not after a bad value is already cached.
Location often means resolver location
When a DNS platform returns location-based answers, it often sees the recursive resolver first, not the user’s device.
That distinction matters. If you use your ISP resolver, the resolver may be close to you. If you use a large public resolver, the authoritative DNS service may see a resolver location that represents a much larger user base. If you are on a VPN, the DNS path may follow the VPN or corporate resolver policy instead of your physical location.
That is how two users in the same city can receive different DNS answers. They are not really asking from the same DNS point of view.
EDNS Client Subnet, or ECS, was created to reduce that mismatch. RFC 7871 defines ECS as an EDNS option that can carry information about the network that originated a query and the scope for which a response can be cached. The same RFC also discusses privacy and operational concerns (RFC 7871). Google Public DNS describes the common use case: CDNs and latency-sensitive services can use partial client network information to return more accurate location-based answers through public resolvers (Google Public DNS ECS guidelines).
ECS is a tradeoff. It can improve routing accuracy. It can also expose more network-location information and create more cache variations. Some resolvers send ECS in some cases. Some do not. Some authoritative DNS systems use it. Some ignore it.
When DNS differs by resolver, ECS support is one of the first things to check.
Global load balancing is supposed to give different answers
Many DNS differences are intentional.
Global load balancing uses DNS as a traffic steering layer. Instead of publishing one address for every user, a domain can return different answers based on a policy. AWS Route 53 documents routing policies such as latency, weighted, failover, geolocation, and geoproximity routing (Route 53 routing policies). Cloudflare Load Balancing documents steering options that can use point-of-presence location, resolver geolocation, health data, and ECS support for DNS-only load balancers (Cloudflare traffic steering).
This is useful for performance. A user in Europe may get a European origin or CDN edge instead of crossing an ocean for every request.
It is useful for resilience. If an origin becomes unhealthy, DNS can stop returning that pool for new lookups and send traffic somewhere else.
It is useful for controlled rollout. Weighted records can send a small percentage of traffic to a new version before a full release.
It is also useful for regional requirements. Some services need traffic to stay in a region or route to infrastructure that matches local policy.
The limits are important. DNS routes the lookup, not the whole user session. It usually sees the recursive resolver, not the exact user. It depends on caches. Its health checks may test a simple endpoint while real users fail on login, checkout, TLS, or an API dependency. A DNS failover rule does not guarantee every client stops using the old endpoint instantly.
This is why DNS-based incidents can feel uneven. A broken origin may only affect users mapped to one region. A bad weighted rule may affect only a slice of users. A missing default in a geolocation policy may work in the countries you tested and fail in the ones you did not.
Different answers are not automatically a bug. But when you use DNS for steering, you need to monitor it from the same kinds of places and resolvers your users actually use.
Anycast changes where the query lands
Anycast is another reason DNS can feel local and global at the same time. Cloudflare describes anycast as a routing method where requests can go to different locations that share an address (Cloudflare Anycast overview).
Many DNS providers use anycast for recursive resolvers and authoritative nameservers. The same IP address can be served from multiple physical locations. Network routing decides which site receives a query.
Usually, this is a strength. Anycast can reduce latency and keep service available when one location has trouble. It is one reason global DNS infrastructure can be fast without asking every user to configure a nearby server.
It can also complicate troubleshooting. Two clients can query the same resolver IP and reach different physical resolver instances. Two recursive resolvers can query the same authoritative nameserver address and land in different sites. If every site has the same zone data and policy state, no one notices. If one site is stale or misconfigured, only part of the world may see it.
So “I queried the authoritative nameserver” is not always enough detail. You still need to know where the query came from, which network path it used, and when it happened.
Split-horizon DNS is different by design
Split-horizon DNS, also called split-brain DNS, returns different answers depending on where the query comes from. A company might return a private address for app.example.com inside the corporate network and a public address for the same name on the internet. Microsoft documents split-brain DNS policies where internal and external clients receive different records from different zone scopes (Microsoft split-brain DNS).
This pattern is common and often useful. Internal users can reach private services directly. Administrators can keep private addresses out of public DNS. Hybrid networks can make the same service name work from the office, VPN, and public internet.
It also creates some frustrating tickets.
A laptop on VPN gets one answer. The same laptop off VPN gets another. A certificate authority sees the public view. A deployment job in a private subnet sees the internal view. A developer tests from home and cannot reproduce what production sees.
No one is necessarily wrong. They are just asking different DNS views.
Split-horizon DNS needs documentation and monitoring from both sides. If the public and private zones drift, the same hostname can quietly become two different services.
Misconfiguration can look regional
Not every regional split is smart routing. Some are ordinary DNS mistakes.
Broken delegation is a common one. RFC 1912 describes a lame delegation as a case where a nameserver is delegated authority for a zone but is not actually serving that zone (RFC 1912). Depending on which delegated nameserver a resolver tries, users may see success, timeout, or failure.
Parent-child mismatch is related. The parent zone may list one set of nameservers while the child zone publishes another. During a nameserver migration, some resolvers may still follow cached delegation data. If the old nameservers are shut down too early, the failure can look regional.
Stale secondary nameservers cause a similar problem. DNS zones use SOA serial numbers and timing fields such as refresh, retry, and expire; RFC 1035 defines those SOA fields (RFC 1035). If a secondary server stops receiving updates but continues answering, some resolvers may receive old data while others receive current data.
CNAME mistakes can also cause trouble. RFC 1912 warns that a CNAME should not coexist with other data at the same name, and it calls out problems with CNAMEs mixed with records such as NS or MX. Some DNS providers prevent these cases. Others handle them in provider-specific ways. During migrations, those differences can show up as inconsistent behavior.
DNSSEC failures often appear as SERVFAIL, not a wrong address. Cloudflare’s DNSSEC troubleshooting guide notes that if a query works with DNSSEC checking disabled but returns SERVFAIL with validation enabled, DNSSEC may be misconfigured, often after authoritative nameservers change without updating DS records (Cloudflare DNSSEC troubleshooting). That means one resolver may appear to work while a validating resolver fails.
There are smaller causes too. A domain may have an A record but no AAAA record. A wildcard may catch one typo but not another. A search suffix may turn a short internal name into a different full name. A resolver may filter certain domain categories.
These are not all global DNS problems. They only look global until you compare the exact hostname, record type, resolver, response code, and authoritative answer.
A practical troubleshooting order
Start with the exact question. DNS is precise. example.com, www.example.com, and api.example.com can all be different. A, AAAA, CNAME, MX, TXT, and NS are different questions.
A useful DNS report says:
- The hostname queried.
- The record type.
- The resolver used.
- The region or network where the query started.
- The response code.
- The answer returned.
- The TTL, if available.
- The time of the test.
Then compare layers.
First, query more than one recursive resolver from the same location. If your ISP resolver, a public resolver, and a corporate resolver disagree, caching, filtering, ECS, or resolver policy may be involved.
Second, query from more than one region. If the answer changes in a way that matches your load-balancing policy, the difference may be expected. If one region gets an answer no policy should return, look for cache state, stale authoritative data, or broken delegation.
Third, query the authoritative nameservers directly. If authoritative servers disagree with each other, stop blaming recursive resolvers. Fix the zone data, secondary sync, provider state, or delegation first.
Fourth, compare parent and child NS records. Make sure every delegated nameserver answers authoritatively for the zone.
Fifth, check DNSSEC when the failure is SERVFAIL. Compare validating and non-validating results. If validation changes the outcome, investigate DS records, DNSKEY records, signatures, and recent nameserver changes.
Finally, respect the TTL. If the old answer had a one-hour TTL, a test five minutes after the change only proves some caches still remember the old answer.
The good and bad of different answers
Different DNS answers are not a hack. They are part of how the internet scales.
The good side is real. Caching keeps lookups fast. Geo and latency steering move users toward better infrastructure. Weighted records help with gradual rollouts. Failover policies can move new lookups away from unhealthy endpoints. Split-horizon DNS can make private and public network paths easier to manage.
The bad side is also real. DNS can hide the cause of an outage behind caches and policy layers. It can send different users into different failure modes. It can make a provider migration last longer than expected. It can turn one missing load-balancing rule into a country-specific incident. It can create privacy tradeoffs when client network hints are used for better routing.
The right conclusion is not “different DNS answers are bad.” The right conclusion is “different DNS answers need an explanation.”
Good DNS operations are boring in the best way. Keep records and delegation clean. Keep TTLs intentional. Keep load-balancing rules simple enough to explain during an incident. Monitor from the regions and resolver types your users depend on. Document split-horizon views. Treat DNSSEC changes like production changes, because they are.
And when someone on the bridge says “It’s always DNS,” do not argue with the joke. Use it as a prompt. Check DNS early, check it carefully, and then let the evidence tell you whether DNS is the cause, the symptom, or just the first place the problem became visible.