SERVFAIL (Server Failure) is DNS response code 2, returned when a recursive resolver attempts to look up a domain but encounters an error during the resolution process. Unlike NXDOMAIN (which definitively states "this domain does not exist"), SERVFAIL means "I tried to find the answer but something went wrong." The domain might be perfectly fine. The resolver just could not complete the lookup.
SERVFAIL is one of the most frustrating DNS errors to troubleshoot because it does not tell you what went wrong. It is a catch-all failure code. The domain's authoritative server might be down, DNSSEC validation might have failed, the delegation chain might be broken, or the resolver itself might be having issues. The response looks the same in every case.
What a SERVFAIL Response Looks Like
$ dig example.com A
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54321
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;example.com. IN A
The key indicator is status: SERVFAIL in the header. The answer section is empty. The resolver has no answer to give you.
Common Causes of SERVFAIL
1. DNSSEC Validation Failure
This is the most common cause of SERVFAIL in modern DNS. When a domain has DNSSEC enabled but the signatures are invalid, expired, or the chain of trust is broken, a validating resolver returns SERVFAIL rather than serving unverified data.
Common DNSSEC issues that trigger SERVFAIL:
- Expired RRSIG signatures: DNSSEC signatures have an expiration date. If your DNS operator does not re-sign the zone regularly, signatures expire and validation fails.
- Mismatched DS records: The DS record at the parent zone (e.g.,
.com) must match the DNSKEY in your zone. After a key rollover, if the DS record is not updated, the chain of trust breaks. - Unsupported or unmatched algorithms: The parent's DS must identify and digest an actual DNSKEY in your zone's apex DNSKEY RRset (RFC 4035 Section 5.2), and the validating resolver must support every algorithm the chain requires. There is no requirement that the parent zone and your zone be signed with the same algorithm, which is a common misreading.
# Test if DNSSEC is causing the SERVFAIL
dig example.com A @8.8.8.8 # Returns SERVFAIL
dig example.com A @8.8.8.8 +cd # Returns answer (checking disabled)
+cd sets the Checking Disabled bit, asking that server not to validate. If the plain query fails and the +cd query succeeds, you have narrowed the failure to DNSSEC validation at that resolver. That is not the same as proving your domain's DNSSEC is broken: the cause could equally be that resolver's trust anchors, its cached state, or its local validation policy. Confirm before you go changing DS records, using Extended DNS Error codes in the response, delv for an independent chain walk, or a second validating resolver. See What Is DNSSEC and Why Should You Enable It for configuration guidance.
2. Unreachable Authoritative Nameservers
If all authoritative nameservers for a domain are down, unreachable, or not responding, the resolver cannot complete the lookup and returns SERVFAIL.
# Check if nameservers are responding
dig example.com NS +short
# Returns: ns1.example.com ns2.example.com
dig example.com A @ns1.example.com +timeout=5
dig example.com A @ns2.example.com +timeout=5
If neither nameserver responds, the domain is effectively offline until they are restored.
3. Broken Delegation
Delegation is broken when the NS records at the parent zone point to nameservers that do not serve the domain. This happens when:
- You changed DNS providers but did not update the NS records at your registrar
- The nameservers listed at the registrar are decommissioned
- A typo in the NS record points to a nonexistent server
# Trace the delegation chain
dig example.com A +trace
If the trace shows a referral to nameservers that then fail to respond or return errors, the delegation is broken.
4. Zone File Errors
A syntax error in the zone file can prevent the authoritative server from loading the zone entirely. When it cannot load the zone, it cannot answer queries for any name in that zone, and resolvers receive errors or timeouts that result in SERVFAIL.
5. Resolver Overload
If the resolver itself is overloaded, too many concurrent queries, insufficient memory, or under a DDoS attack. It may return SERVFAIL for queries it cannot process in time. A resolver that answers recursive queries for anyone on the internet is especially prone to this, since strangers can drive its load far beyond what its own users would generate. A deliberate flood of lookups for nonexistent domains is one common way attackers push a resolver into this overloaded, SERVFAIL-returning state.
6. Network Issues
Firewalls, routing problems, or packet loss between the resolver and authoritative servers can prevent queries from completing. This is particularly common when:
- A firewall blocks DNS traffic to certain nameservers
- TCP fallback is needed (large responses) but port 53 TCP is blocked
- IPv6 nameservers are listed but IPv6 connectivity is broken
SERVFAIL vs. Other DNS Errors
| Response | Meaning | The Domain... |
|---|---|---|
| NOERROR | Success | Exists. Check the answer section. |
| NXDOMAIN | Non-Existent Domain | Does not exist, per the authoritative data consulted. |
| SERVFAIL | Server Failure | Might exist, but something went wrong during lookup. |
| REFUSED | Query Refused | May exist, but the server will not answer you (access control). |
| TIMEOUT | No response | Unknown. The server did not respond at all. |
The critical distinction: NXDOMAIN is an answer. It says the name does not exist according to the authoritative data the resolver consulted. SERVFAIL is not an answer at all: the resolver could not determine whether the name exists or what its records are. (NXDOMAIN reaching your client is usually served from a resolver's negative cache, so the message itself normally lacks the AA bit even though the underlying fact came from authoritative data.)
How to Troubleshoot SERVFAIL
Step 1: Test with DNSSEC Checking Disabled
dig example.com A @8.8.8.8 +cd
If this returns a valid answer, the failure is in DNSSEC validation at that resolver. Check your DNSSEC configuration, DS records, RRSIG expiration, and key rollover state, and cross-check with delv or another validating resolver before concluding the fault is yours rather than that resolver's.
Step 2: Query Multiple Resolvers
dig example.com A @8.8.8.8 # Google
dig example.com A @1.1.1.1 # Cloudflare
dig example.com A @9.9.9.9 # Quad9
If all resolvers return SERVFAIL, the problem is with the domain's authoritative infrastructure. If only some return SERVFAIL, the issue may be resolver-specific (caching a previous failure) or network path-specific.
Step 3: Query Authoritative Servers Directly
dig example.com NS +short
# Returns: ns1.example.com ns2.example.com
dig example.com A @ns1.example.com
dig example.com A @ns2.example.com
If the authoritative servers respond correctly, the problem is between the resolver and the authoritative server (network issue, DNSSEC issue at the resolver level, etc.).
If the authoritative servers do not respond, they are down or unreachable.
Step 4: Trace the Resolution Path
dig example.com A +trace
This shows every step of the resolution process, starting at the DNS root servers and following the delegation down. Look for where the chain breaks: which server returns an error or fails to respond.
Step 5: Check with DNS Inspector
Use the DNS Inspector to query the domain across all record types. It queries authoritative servers directly, so you can see whether the domain's records exist independently of any resolver issues.
Step 6: Check DNSSEC Validity
# Check if DNSSEC records exist
dig example.com DNSKEY +dnssec
dig example.com DS +dnssec
Verify that DNSKEY records are present and that the DS record at the parent zone matches. Look for RRSIG records and check their expiration dates.
Fixing SERVFAIL
The fix depends on the cause:
| Cause | Fix |
|---|---|
| Expired DNSSEC signatures | Re-sign the zone or contact your DNS provider |
| Mismatched DS record | Update the DS record at your registrar to match current DNSKEY |
| Unreachable nameservers | Restore nameserver availability or switch providers |
| Broken delegation | Update NS records at your registrar to point to active nameservers |
| Zone file errors | Fix syntax and reload the zone |
| Resolver overload | Scale resolver infrastructure |
Emergency Fix: Remove DNSSEC
If DNSSEC is causing SERVFAIL and you cannot fix the signatures quickly, removing the DS record from the parent zone will stop validation failures. This is a last resort. It removes DNSSEC protection entirely, and it is not instant. The registrar still has to get the removal published in the parent zone, and validating resolvers keep serving the old DS RRset until it expires from their caches. RFC 8078 Section 4 is explicit that you must wait a sufficient amount of time, dictated by the parental TTLs, before the delegation is treated as insecure.
1. Remove DS record at your registrar
2. Wait for the parent zone DS TTL to expire everywhere
3. Resolution is restored (without DNSSEC protection)
4. Fix the underlying DNSSEC issue
5. Re-add DS record once DNSSEC is working correctly
When SERVFAIL Is Expected
Not every SERVFAIL indicates a problem with your domain:
- Intentionally broken DNSSEC test domains (like
sigfail.verteiltesysteme.net) return SERVFAIL by design. They are used to test resolver validation - Domains under active DDoS may intermittently return SERVFAIL as nameservers are overwhelmed
- Brand new domains may briefly return SERVFAIL while delegation propagates, though much of what people call propagation is really cache expiry
For more DNS troubleshooting, see Troubleshooting Common DNS Issues and DNS Troubleshooting Tools. For DNSSEC-specific guidance, see What Is DNSSEC?.