Your nameservers disagree about whether this record exists
Updated
What this check looks for
Some of the nameservers your domain is delegated to serve this record and others say it does not exist. Which answer a visitor gets depends on which of your nameservers their resolver happened to ask.
Why it matters
An answer of "does not exist" is worse than a wrong address: browsers and mail servers stop immediately rather than trying elsewhere, and the answer is cached, so the outage outlasts the fix. A share of the internet will be told your domain has no such record for as long as this lasts, and which share is a matter of chance.
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 the nameserver that has not got this record, and get the zone onto it.
Every visitor whose resolver asks that server is told the record does not exist, and that answer is cached.
Query each of your nameservers directly for the name; the ones answering NODATA or NXDOMAIN are the ones missing the record.
On each of those, confirm the zone is loaded and that the transfer from the primary is succeeding — a secondary that has expired the zone stops answering for it.
Compare the SOA serial on every nameserver. A serial behind the others is a failing zone transfer and is the usual cause.
After the fix, the negative answer stays cached for as long as your SOA minimum, so allow that time before re-testing.
How to confirm it worked
dig +short ‹type› ‹domain› @<each of your nameservers> — every one must return the record
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
Every nameserver the zone is delegated to was asked for ‹type› at ‹domain› directly, from one machine, at one moment. ‹explanation› These reported the record absent: ‹resolver list›.
That comparison is made between your own nameservers deliberately, and it is the only comparison here that can carry a verdict. Public resolvers in different countries are different clients, and a zone behind a CDN or routed by geography answers each of them differently and correctly, so a difference between two *resolvers* is not evidence of a fault and is not reported as one. A difference between two of your own nameservers answering the same client in the same second is: no address pool, anycast edge or routing policy makes a record exist on one server and not on another.
Two of your nameservers returning *different addresses* is not this finding. That is what a lagging secondary looks like and equally what one provider's address pool looks like beside another's, and one query to each cannot tell them apart; where that happens this check reports that it reached no verdict and says why. The lagging secondary is caught where it can be proved: dns.health compares the SOA serial on every one of your nameservers, and a serial is a version stamp no address pool rotates.
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.