Different recursive resolvers can return different answers without either result describing all of DNS. Each resolver has its own cache, refresh time, validation state, policy, upstream path, and network view. Start with the authoritative source, then explain each resolver observation.
Scope the symptom
Keep the query identical:
- exact fully qualified name, type, and class;
- resolver address and transport;
- response code, answer, TTL, and flags;
- Extended DNS Error, if present;
- timestamp and client network;
- whether a VPN, corporate resolver, encrypted DNS, or local override is in use; and
- the intended authoritative nameserver set.
The DNS-zone owner controls authoritative values. Resolver operators control caches, validation, forwarding, and policy. Network owners can select resolvers or expose a private DNS view.
Read-only checks
- Use the DNS Lookup pathway to capture the same query from named public resolvers at approximately the same time.
- Query every intended authoritative server directly. Record answer values, SOA serials, and TTLs rather than relying on a control panel.
- Trace or inspect the parent referral to confirm those are the authorities recursive resolvers should reach.
- Compare remaining recursive TTLs with authoritative TTLs and the known change time.
- Capture DNSSEC validation status and any Extended DNS Error.
- Repeat from the affected network’s configured resolver to test whether the difference is view- or policy-specific.
DNS caching is an intentional part of recursive resolution [1]. Negative answers have their own cache lifetime [2].
Interpret the observations
| Observation | Supported interpretation | Responsible owner |
|---|---|---|
| Authorities agree; old resolver answer has a decreasing TTL | A normal cached answer is supported | Recursive-resolver owner |
| Authorities agree; resolver marks the answer stale | Serve-stale behavior is supported | Recursive-resolver owner |
| Authorities disagree | Publication is inconsistent before recursion is considered | DNS provider |
| Public resolvers agree; corporate resolver differs | Private view, forwarding, local policy, or cache is supported | Network or resolver owner |
| Validating resolvers fail; non-validating resolver answers | DNSSEC failure is a supported hypothesis | Parent DS and child signing owners |
| Answers differ with no explainable TTL or view | More resolver and path evidence is required | Unresolved |
RFC 8767 permits resolvers to serve expired data in defined failure conditions to improve resilience [3]. An EDE can label stale or policy behavior, but may be absent or unauthenticated [4].
Likely causes
- independent positive or negative cache lifetimes;
- authoritative servers publishing different zone versions;
- serve-stale behavior during authoritative failure;
- split-horizon DNS or network-specific private zones;
- recursive forwarding to different upstreams;
- DNSSEC validation differences;
- filtering, blocking, or other resolver policy;
- local hosts-file, browser, operating-system, or application cache; or
- a query that was not actually identical in name, type, transport, or view.
Safe next actions
- Read-only: preserve a matrix of resolver, answer, TTL, flags, EDE, and time. Repeat only as needed to observe the cache lifetime.
- Reversible: if authoritative data is consistent, let explainable caches expire or correct a documented private resolver override.
- Availability-impacting: if authorities disagree, stop new changes and have the DNS provider restore consistent zone publication.
- Availability-impacting: if validating and non-validating behavior differs, complete a DNSSEC chain investigation before editing DS, DNSKEY, or signatures.
Do not flush arbitrary caches, switch users to a weaker resolver, or repeatedly edit authoritative values merely to make observations converge.
Verification
Record success in layers:
- every intended authoritative server returns the intended RRset and TTL;
- the parent delegation reaches those authorities;
- named recursive resolvers return either the intended answer or an understood cached state;
- DNSSEC validation has the intended status; and
- the affected client uses the resolver and DNS view you tested.
State which resolvers converged and when. Avoid “fully propagated.”
What this evidence does not prove
Resolver agreement or disagreement does not by itself prove:
- what every resolver on the Internet returns;
- which answer an untested client receives;
- that the authority is correct merely because several caches agree;
- malicious tampering;
- an application-layer outage; or
- that a low remaining TTL will force every client cache to refresh.
Next protocol layer
If the differing response is NXDOMAIN, continue with NXDOMAIN
diagnosis. If it is SERVFAIL, use the SERVFAIL
path. Once the intended DNS answer is established for the
affected client, investigate TLS, HTTP, CDN, origin, or email behavior instead
of continuing to compare resolvers.