NXDOMAIN vs. SERVFAIL: What Your DNS Error Actually Means

A browser says it can't find your website, maybe with an error like DNS_PROBE_FINISHED_NXDOMAIN. That sounds like one problem, but DNS can fail in several different ways. The name might not exist, the record type you asked for might be missing, or the resolver might be unable to finish the lookup.

Those cases need different fixes. Before changing records or waiting for propagation, look at the answer DNS is actually giving you.

Start with the full response

Run a query against a specific public resolver:

dig @1.1.1.1 www.example.com A

Replace the example hostname with yours. Keep the full output for now: +short is useful when you only want a value, but an empty result hides the distinction between several failures.

Near the top, look for the status:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12345

Also inspect the answer section, authority section, and the server that replied. A response code is the start of the investigation, not a complete diagnosis.

NXDOMAIN: the name does not exist

NXDOMAIN means the lookup reached a conclusion that the queried name does not exist. When aliases are involved, the nonexistent name can be the target of a CNAME chain rather than the hostname you typed.

Start with spelling and the exact name. example.com and www.example.com are separate names. Creating one doesn't automatically create the other. Also watch for a doubled zone name: many dashboards append example.com to whatever you type, so entering www.example.com in the name field can create www.example.com.example.com.

If the record exists in your dashboard, confirm that you edited the provider currently serving the domain. A perfectly configured zone at an old provider has no effect once the delegation points elsewhere.

Finally, compare the authoritative answer with public resolvers. A resolver can temporarily remember an earlier negative answer even after you create the record.

NOERROR with no matching answer: NODATA

Suppose www.example.com has an A record but no AAAA record. Asking for AAAA can return NOERROR with no matching answer. The name exists; there is no IPv6 address record to return.

This is commonly called NODATA. It isn't a separate response code printed in the status field. RFC 2308 distinguishes it from NXDOMAIN and explains how both kinds of negative answer are cached.

An empty answer section alone isn't enough to diagnose NODATA. A referral from a parent nameserver can also have no answer records. The authority section tells them apart: a NODATA response carries the zone's SOA record there, while a referral carries NS records pointing somewhere else.

The practical question is whether the missing type is expected. No AAAA record on an IPv4-only site may be intentional. A missing MX record during a mail migration deserves investigation.

SERVFAIL: the resolver could not complete the lookup

SERVFAIL means resolution failed. It does not establish that the name is absent.

Possible causes include unreachable authoritative nameservers, broken delegation, a CNAME loop, or failed DNSSEC validation. Some resolvers, including 1.1.1.1, attach an Extended DNS Error that narrows it down. In dig output it appears in the OPT pseudosection as a line like ; EDE: 6 (DNSSEC Bogus) or ; EDE: 22 (No Reachable Authority).

For a suspected DNSSEC problem, compare:

dig @1.1.1.1 example.com A +dnssec
dig @1.1.1.1 example.com A +dnssec +cdflag

The second query asks the resolver not to reject the answer because of DNSSEC validation. If it succeeds while the first fails, validation is a useful lead. It isn't a reason to disable validation permanently. Inspect the DS record, DNSKEYs, and signatures instead.

The +dnssec option requests DNSSEC data; it does not turn dig into a validating resolver. Google's domain troubleshooting guide covers validation and delegation failures in more detail.

REFUSED: the server won't answer for that name

REFUSED usually shows up when you query a nameserver directly, as in the comparison below. It typically means that server isn't configured to serve your zone, or it won't answer recursive questions for outsiders.

If one of your listed authoritative nameservers returns REFUSED for your own domain, that's a lame delegation: the registrar points at a server that doesn't have the zone. It's a common leftover after a provider migration, and the fix is to correct the nameserver list or recreate the zone, not to edit records.

A timeout is different again

A timeout means your client didn't receive a usable response in time. There may be no DNS response code to inspect.

The cause could be your network, a blocked port, the chosen resolver, or the authoritative infrastructure behind it. Try another resolver and compare UDP with TCP:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A +tcp

A difference is evidence to investigate, not proof that the resolver returning the preferred answer is correct.

Compare the source with the cached view

Find the nameservers assigned to your domain, then query each directly:

dig @ns1.example.net www.example.com A +norecurse
dig @ns2.example.net www.example.com A +norecurse

Use your actual authoritative nameservers in place of these examples. If they disagree, investigate the provider or zone synchronization. If they agree but public resolvers differ, examine caching and DNSSEC before editing the record again.

The free DNS Lookup tool queries your authoritative nameservers by default, and its resolver comparison view puts several public resolvers side by side, so you can do this comparison without a terminal. Keep the full dig output when you need protocol-level details.

How DNS monitoring fits in

The hardest part of a DNS error is usually answering "what changed?" OneDollarDNS keeps a history of every monitored record, so an NXDOMAIN on a hostname that worked yesterday can be traced to the exact check where its record disappeared, along with the value it used to have.

SERVFAILs and timeouts are often a nameserver problem rather than a record problem. Nameserver reachability monitoring is included with every monitored domain and alerts you when your authoritative servers stop answering, so you hear about it before your users start seeing errors.

Not every DNS error means a record was deleted. Start with the response code, identify which part of resolution failed, and then use the record history to connect it to a change. If an alert prompted the investigation, this walkthrough covers what to check next.