Public resolvers are serving different answers
What this check looks for
Resolvers around the world do not agree on your records, and the difference is not a change still spreading. Which answer a visitor gets depends on which resolver they use.
Why it matters
Some of your visitors are being sent somewhere different from the others, with no pattern you can predict. It usually means your own nameservers disagree with each other, so the wrong answer is being served authoritatively rather than merely cached.
When the check passes, your report says: “Public resolvers around the world return the same answers”.
What it costs your score
When this check fails it removes 12 points from your DNS score, before the status, confidence and repeat multipliers are applied. DNS carries a weight of 10 in the overall score.
It shares the dns.propagation.consistency family ceiling of 25 points: however many findings that family produces, together they cannot remove more than that from DNS. One underlying problem showing up in several places is still one problem.
- Severity
- medium
- Default confidence
- confirmed
- Status when triggered
- fail
- Deduction
- 12 points
- Family cap
- dns.propagation.consistency · 25
- Category
- DNS
- Module
- Dns propagation
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Find out why your nameservers are serving different data, and make them agree.
While they disagree, a share of your visitors is being sent to the wrong place.
Query each of your authoritative nameservers directly and compare the answers — the disagreement almost always starts there.
Compare the SOA serial on each; a lagging secondary means zone transfers are failing.
If your nameservers agree with each other, the difference is a resolver-side cache and will clear on its own within the record's TTL.
Re-test after the longest TTL you publish has elapsed before concluding it is not simply caching.
How to confirm it worked
dig +short ‹type› ‹domain› @<each of your nameservers> — every answer must be identical
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
For ‹type› at ‹domain›, these resolvers returned an answer that is not what the zone publishes: ‹resolver list›. ‹explanation› Resolvers that failed to answer are excluded from this comparison: a SERVFAIL is a failure to observe, not an observation of a different value, and counting it would report somebody else's outage as your misconfiguration. When the minority answer is the *previous* value and still has time left on its TTL, this is reported as a change in progress instead — see the stale-answers finding.
Standards and references
- RFC 2181 §5.4.1 — Ranking data § 5.4.1
Test this on your domain
Run the check that produces this finding, on its own, against any domain.