A resolver is serving an address your nameservers did not give us
Updated
What this check looks for
Most resolvers return the address your own nameservers served us; a few return something else. That is usually a cache that has not expired yet — but it can also be a resolver answering with an address that is not yours, and one query cannot tell the two apart.
Why it matters
The benign reading is the common one and it needs no action. The other reading does: a resolver that substitutes an address is sending everyone who uses it somewhere you do not control. Which of the two this is decides whether there is anything to do, so the address is worth thirty seconds of your attention rather than a reassurance from us.
What it costs your score
This check never deducts. It reports a fact — or reports that something could not be verified — and is shown on the report without moving the score.
- Severity
- info
- Default confidence
- confirmed
- Status when triggered
- info
- Deduction
- 0 points
- Family cap
- none
- Category
- DNS
- Module
- Dns propagation
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Check whether the address that resolver returned is one of yours, then act on the answer.
A cache clears by itself and a substituted address never will, and only you can say which of your addresses is which.
Compare the address above with your own records, including any you have recently changed away from.
If it is a value you used to serve, it is a cache: wait for the time shown and it clears on its own.
If it is not an address of yours, that resolver is answering with something other than what your zone serves. Raise it with the operator; nothing in your zone will change what it returns.
For the next change, lower the record's TTL to 300 seconds a full old-TTL period in advance, then restore it afterwards.
How to confirm it worked
dig +short ‹type› ‹domain› @<that resolver> — compare the answer with dig +short ‹type› ‹domain› @<each of your nameservers>
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
Your nameservers served ‹published› for ‹type› at ‹domain› when asked directly. These resolvers returned something else: ‹resolver list›. The cached copies they hold expire in ‹clears in›.
Two things look exactly like this from here. A resolver still holding a value your zone served earlier — in which case the address is one of yours, it will clear by itself at the TTL, and RFC 1035 §3.2.1 makes that TTL a promise no one can shorten: no mechanism exists to invalidate a third party's cache. Or a resolver answering with an address of its own, whether by filtering policy, by a hijacked or poisoned entry, or because it is a captive network's resolver. Nothing in a single query distinguishes them, so this finding does not pick one.
Check whether the address above is yours. If it is, you are waiting, and to make the *next* change faster, lower the record's TTL a full TTL period before you make it. If it is not, the resolver operator is the one to raise it with; your zone is not the problem, and nothing you change in it will alter what that resolver answers.
Standards and references
- RFC 1035 §3.2.1 — Format § 3.2.1
Test this on your domain
Run the check that produces this finding, on its own, against any domain.