dotvitals

Some resolvers say the domain does not exist

HighConfirmeddns.propagation.partial-nxdomain

What this check looks for

Some public resolvers report that your domain does not exist, while others return records for it normally. For anyone using one of those resolvers, your site and email are simply gone.

Why it matters

An NXDOMAIN is worse than a wrong answer: browsers and mail servers stop immediately rather than retrying, and the negative answer is cached, so the outage persists for those users even after the cause is fixed.

When the check passes, your report says: “Every resolver we asked knows the domain exists”.

What it costs your score

When this check fails it removes 20 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
high
Default confidence
confirmed
Status when triggered
fail
Deduction
20 points
Family cap
dns.propagation.consistency · 25
Category
DNS
Module
Dns propagation
Fix owned by
dns host
In the ruleset since
2026.09

How the whole score is calculated

How to fix it

Find the nameserver answering NXDOMAIN, or confirm the resolver is filtering you.

For everyone on the affected resolvers the domain does not exist at all.

  1. Query each authoritative nameserver directly for the name; the one returning NXDOMAIN has lost the zone.

  2. On that server, confirm the zone is loaded and the transfer from the primary is working.

  3. If every one of your nameservers answers correctly, check whether the affected resolvers are filtering ones — a blocklisting is a different problem and is resolved with the operator.

  4. 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> — none should return NXDOMAIN

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

These resolvers returned NXDOMAIN for ‹type› at ‹domain›: ‹resolver list›. These returned records: ‹answering list›. Two causes account for almost all cases. Either one of your authoritative nameservers is answering NXDOMAIN — usually because it has lost the zone — and RFC 2308 §5 then has resolvers cache that answer for the SOA minimum. Or the resolver filters answers by policy and is blocking the domain, which is a fact about that operator rather than about your zone; where every dissenting resolver is a filtering one, this finding is reported at reduced confidence and says so.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the dns propagation checker

Other dns propagation checks