Understanding NXDOMAIN vs SERVFAIL starts with one distinction: a negative answer differs from a failed lookup. NXDOMAIN says the queried name does not exist in the DNS view answering your request. SERVFAIL says the server could not complete the request successfully. Neither response, by itself, identifies which setting needs changing.
For business operators, that difference matters. Adding a record will not fix every failure. Switching resolvers can also hide a problem without correcting it. This guide explains what each response establishes, what remains uncertain, and which evidence helps you choose the next step.
What Each DNS Response Actually Tells You
The Domain Name System, or DNS, maps names to records that applications use. A recursive resolver follows DNS referrals and collects answers for clients. An authoritative server holds answers for a particular DNS zone, an administrative portion of the namespace.
A DNS response contains a response code. Tools may display that code even when a browser shows only a vague connection error.
| Result | Meaning | What It Does Not Prove |
|---|---|---|
| NXDOMAIN | The answering DNS view reports that the queried name does not exist. | The name is absent from every internal or external DNS view. |
| SERVFAIL | The server could not complete the query successfully. | The queried name or record is missing. |
| NOERROR with no requested data | The lookup succeeded but returned no records of the requested type. | The name does not exist. |
| Timeout | The client received no response within its waiting period. | A DNS server returned SERVFAIL. |
For background on these roles, see Cloudflare’s overview of DNS resolution. Keep server roles separate when interpreting results: a resolver’s failure and an authoritative answer carry different evidence.
NXDOMAIN Means Nonexistence, Not a Missing Record Type
Suppose a name has an address record but no mail-routing record. A query for its mail-routing record normally returns NOERROR with no matching data. Technicians often call this NODATA. It differs from NXDOMAIN, which concerns the name itself.
That distinction prevents unnecessary changes. Creating a new hostname does not address a missing record type at an existing name.
Aliases add another wrinkle. A CNAME record points one name to another name. A response can include that alias and report NXDOMAIN because its target does not exist. Read the answer section before concluding that the original alias is absent.
Also consider the DNS view. An internal resolver may know a private business hostname that public resolvers cannot see. Public NXDOMAIN can therefore be correct, while internal NXDOMAIN indicates a different problem.
Filtering services may deliberately return NXDOMAIN for blocked names. In that case, the response reflects policy rather than ordinary authoritative nonexistence. For a focused missing-name investigation, use the subdomain NXDOMAIN diagnostic guide.
SERVFAIL Means Resolution Failed, Not That the Domain Is Gone
SERVFAIL covers several failure conditions. A resolver may exhaust reachable authoritative servers, encounter broken delegation, or reject DNSSEC data. Its own resource limits or upstream failures can also prevent completion.
A resolver can return SERVFAIL even when an authoritative server holds the correct address record. The resolver still needs a usable path and, when required, valid security evidence.
Likewise, an authoritative server can return SERVFAIL when it cannot answer from its own zone data. Always record which server produced the response.
A timeout is different. It means your test received no answer. Network filtering, an unavailable resolver, or packet loss may explain that silence. A recursive resolver might experience upstream timeouts and eventually return SERVFAIL to your client.
When comparing NXDOMAIN vs SERVFAIL, treat the first as a negative assertion and the second as an unresolved failure. Then check whether policy, caching, aliases, or DNS views change that interpretation.
How Delegation and Authoritative Availability Change the Result
Delegation tells resolvers which nameservers handle a child zone. The parent publishes nameserver records for that zone. Sometimes it also supplies glue records: address records needed to reach nameservers within the delegated namespace.
Incorrect referrals can send requests to servers that no longer host the zone. Missing or stale glue can prevent a resolver from reaching the intended servers. Neither condition automatically means the requested name is nonexistent.
Authoritative availability creates another distinction:
- A reachable authority may return a valid negative answer for a missing name.
- Unreachable authorities may leave the resolver unable to complete the query.
- Inconsistent authorities may return different answers for the same name and type.
- A cached answer may temporarily hide an upstream outage.
One working authoritative server can allow resolution to succeed while another remains broken. Different resolvers may select different servers or retry at different times.
Compare the parent’s delegation with the intended hosting setup. Then compare each listed authority’s responses. Do not replace nameservers merely because one client displays a generic DNS error.
Why DNSSEC Can Turn Available Records Into SERVFAIL
DNSSEC adds signatures that let validating resolvers check DNS data against a chain of trust. It authenticates DNS data; it does not encrypt the lookup.
A parent zone can publish a DS record that links to the child zone’s signing key. If that relationship breaks, a validating resolver may reject answers and return SERVFAIL.
Possible causes include expired signatures, mismatched keys, or an outdated parent DS record after a DNS provider change. Incorrect validator time can also affect signature checks.
Meanwhile, a nonvalidating resolver may return the address successfully. That difference suggests a validation issue, but it does not prove one. Compare equivalent queries and inspect supporting evidence.
DNSSEC can also authenticate nonexistence. Signed denial records let a validator confirm that a name or requested record type is absent. Thus, valid DNSSEC can support NXDOMAIN rather than prevent it.
Read Cloudflare’s explanation of the DNSSEC trust chain for additional context. Do not disable validation as a routine fix. Coordinate signing and parent-record changes with the responsible DNS administrators.
Why Different Resolvers Give Different Answers
Resolvers do not necessarily share caches, policies, or upstream paths. Their answers can differ even when you query the same name seconds apart.
Negative caching stores nonexistence or missing-data answers for a limited period. A resolver may therefore continue returning NXDOMAIN after an administrator creates a record. The zone’s SOA record helps determine negative-cache timing. SOA means Start of Authority and contains zone administration data.
Some resolvers also cache failures briefly or serve stale data under configured conditions. These behaviors can make an outage look different across locations.
Split DNS gives internal and external users different answers intentionally. Browsers may also use encrypted DNS instead of the operating system’s configured resolver. A command-line test might therefore follow a different path than the failing browser.
Compare resolver behavior without changing production settings first. An alternate public resolver is not a suitable reference for private names. The guide to internal DNS over VPN explains that boundary in more detail.
Collect Comparable Evidence Before Choosing a Fix
Use a small, repeatable evidence set rather than unrelated screenshots. Record the full name, record type, resolver address, timestamp, and network location.
- Query the affected client’s configured resolver.
- Capture the response code, answer records, and authority section.
- Repeat the same name and type through an approved comparison resolver.
- Check whether a VPN, browser setting, or filtering service changes the DNS path.
- For domains you manage, compare delegation and responses from each authoritative server.
If dig is available, use a query shaped like this:
dig @RESOLVER_ADDRESS host.example.com. AReplace the resolver placeholder and example name with approved values. The final dot makes the name absolute. This query requests data without changing DNS configuration, but it can expose the queried name to that resolver.
A direct authoritative query needs that server’s address and usually the +norecurse option. Check the authoritative-answer flag before trusting the result as authoritative. Such a query does not establish that a recursive resolver can validate the complete trust chain.
Choose the Next Step From the Evidence
The practical lesson of NXDOMAIN vs SERVFAIL is to match action to evidence. Confirmed authoritative nonexistence points toward the name, alias target, or intended DNS view. SERVFAIL calls for checking completion: delegation, server reachability, validation, and resolver health.
Keep the original test results before flushing caches or making changes. After a correction, repeat identical queries through the affected path. A successful answer from one unrelated resolver does not establish recovery for business users.
Professional remote assistance may help when several DNS providers, private resolvers, or signing settings interact. Tech Rescue Ops LLC can help compare the evidence and plan a targeted correction without treating every DNS error as a missing record.