NXDOMAIN means the requested domain name does not exist, while SERVFAIL means the DNS system could not complete the lookup. That difference matters because one error points to a missing or mistyped name, and the other points to broken resolution, DNSSEC trouble, an unavailable nameserver, or a timeout. In DNS response codes, RCODE 3 means Name Error, often shown as NXDOMAIN, and RCODE 2 means Server Failure, often shown as SERVFAIL [source: IETF].
TLDR: NXDOMAIN usually means the domain or subdomain is not in DNS, such as app.example.invalid returning “no such name.” SERVFAIL means the resolver tried but failed, often because authoritative DNS is down, DNSSEC validation failed, or the resolver timed out. In a support queue of 500 DNS tickets, a team might find that 62% of NXDOMAIN cases are simple spelling or record mistakes, while 71% of SERVFAIL cases need provider, zone, or DNSSEC checks. NXDOMAIN is often a content problem; SERVFAIL is often an infrastructure problem.
What NXDOMAIN Really Means
NXDOMAIN stands for “non-existent domain.” It appears when a DNS resolver asks for a name and receives a clear answer that the name does not exist.
That does not always mean the whole domain is gone. It may mean only the requested hostname is missing. For example, example.com can work while api2.example.com returns NXDOMAIN because no record exists for that subdomain.
Common causes include:
- Typos: A user enters gmai.com instead of gmail.com.
- Missing DNS records: A new subdomain was deployed, but no A, AAAA, or CNAME record was created.
- Deleted zones: A DNS zone was removed or not loaded by the provider.
- Expired domains: The domain passed its renewal deadline and was removed from normal DNS service.
- Internal DNS split errors: A private name works inside one network but fails elsewhere.
NXDOMAIN is useful because it is firm. The resolver is not saying, “Something broke.” It is saying, “This name is not present.” The catch is that cached NXDOMAIN answers can stick around, so a fixed record may still fail until the negative cache expires.
What SERVFAIL Really Means
SERVFAIL means “server failure.” It is less tidy. The resolver could not produce a valid answer, but it is not confirming that the name is absent.
This error can happen when the recursive resolver cannot reach the authoritative nameserver. It can also happen when the authoritative server responds badly, times out, or has a damaged zone file. DNSSEC can cause it too. If validation fails, many resolvers return SERVFAIL instead of passing along a risky answer.
Common causes include:
- Authoritative nameserver outage: The domain’s DNS servers are unreachable.
- DNSSEC failure: Signatures, DS records, or keys do not match.
- Lame delegation: The parent zone points to nameservers that are not authoritative for the domain.
- Timeouts: Resolver queries wait too long and give up.
- Rate limiting: DNS servers reject or slow heavy query traffic.
- Bad zone data: A provider loads a broken or incomplete zone.
Honestly, it feels like SERVFAIL was built to annoy operators. It gives a failure signal, but not enough detail. The same visible error can come from a firewall, a bad DNSSEC chain, a dead nameserver, or a resolver bug.
NXDOMAIN vs SERVFAIL: The Practical Difference
The fastest way to separate the two is to ask what the DNS system is claiming.
| Error | Meaning | Best First Check |
|---|---|---|
| NXDOMAIN | The requested name does not exist. | Check spelling, zone records, and domain status. |
| SERVFAIL | The lookup failed before a valid answer was produced. | Check nameservers, DNSSEC, timeouts, and delegation. |
For a help desk, NXDOMAIN often starts with the user input and zone config. SERVFAIL starts with the DNS path. That path includes the recursive resolver, root servers, TLD servers, authoritative nameservers, and sometimes DNSSEC validation.
For a site owner, the business risk is different. NXDOMAIN can make a new app endpoint vanish. SERVFAIL can make a working domain appear broken at random. That randomness is worse for trust because one visitor may connect while another sees an error.
How a Technician Should Test NXDOMAIN
A technician should test from more than one resolver. Public resolvers, local resolvers, and authoritative queries can show different results.
Useful checks include:
- Run
dig hostname.example.comand inspect the status line. - Run
dig @8.8.8.8 hostname.example.comto test Google Public DNS. - Run
dig @1.1.1.1 hostname.example.comto test Cloudflare DNS. - Query the authoritative nameserver directly with
dig @ns1.provider.com hostname.example.com. - Check whether the parent domain itself resolves.
If the authoritative nameserver returns NXDOMAIN, the record likely does not exist. If only one recursive resolver returns NXDOMAIN, it may have stale negative cache. Negative caching behavior is defined for DNS so resolvers can remember failed answers for a period instead of asking again on every request [source: IETF].
How a Technician Should Test SERVFAIL
SERVFAIL needs a wider check. The name may exist, but resolution breaks before the answer reaches the requester.
- Check authoritative nameservers. If all are down, the cause is obvious.
- Check delegation. The parent zone must point to the right nameservers.
- Check DNSSEC. A wrong DS record can break the whole domain for validating resolvers.
- Compare resolvers. If only validating resolvers fail, DNSSEC is a prime suspect.
- Review firewall rules. UDP and TCP port 53 both matter.
Expect to waste time on partial failures. A domain may resolve from one office but fail from another. That can happen when one resolver has a cached good answer while another performs fresh validation and hits a broken chain.
Why Browsers and Apps Make This More Confusing
Browsers rarely show clean DNS labels. A browser may display “This site can’t be reached,” while the underlying DNS result is NXDOMAIN. Another app may show “temporary failure in name resolution,” even when the root cause is SERVFAIL.
Operating systems add more noise. They may try search suffixes, local hosts files, VPN DNS, encrypted DNS, or enterprise filtering. A user thinks one lookup happened. In reality, several lookups may have occurred.
This is why raw DNS tools matter. Browser messages are for users. DNS status codes are for diagnosis.
Common Fixes
For NXDOMAIN, the fix is usually direct:
- Create the missing A, AAAA, CNAME, MX, TXT, or SRV record.
- Correct the hostname in the app config.
- Renew or restore the domain.
- Lower confusion by documenting internal-only names.
For SERVFAIL, the fix depends on the failed part:
- Restart or repair authoritative DNS service.
- Fix broken DNSSEC keys, signatures, or DS records.
- Correct nameserver glue and delegation.
- Allow DNS traffic over UDP and TCP port 53.
- Ask the DNS provider to inspect logs and zone loading errors.
FAQ
Is NXDOMAIN always bad?
No. NXDOMAIN is normal when a name truly does not exist. It becomes a problem when a valid service returns it by mistake.
Is SERVFAIL temporary?
Sometimes. It can clear after a timeout, provider recovery, or DNSSEC repair. It can also persist until a zone or delegation issue is fixed.
Can DNSSEC cause NXDOMAIN?
DNSSEC can prove that a name does not exist, but broken DNSSEC more often appears as SERVFAIL on validating resolvers.
Why does one resolver show NXDOMAIN while another works?
One resolver may have cached an old negative answer. Another may have fresh data. Split DNS and filtering can also cause different results.
Which error should be fixed first?
SERVFAIL usually needs faster attention because it can affect many users and may point to broken DNS infrastructure. NXDOMAIN is often narrower and tied to a missing name or typo.