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. - Algorithm mismatch — The DNSSEC algorithms at the parent and child must be compatible.
# 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)
If the +cd (checking disabled) query succeeds, DNSSEC is the problem. 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.
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. Authoritative answer. |
| 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 authoritative answer (the domain definitively does not exist). SERVFAIL is not — it means the resolver could not determine whether the domain exists or what its records are.
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, DNSSEC is the problem. Check your DNSSEC configuration — DS records, RRSIG expiration, and key rollover state.
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. 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 — but it restores resolution for all users immediately.
1. Remove DS record at your registrar
2. Wait for TTL to expire (check parent zone DS TTL)
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
For more DNS troubleshooting, see Troubleshooting Common DNS Issues and DNS Troubleshooting Tools. For DNSSEC-specific guidance, see What Is DNSSEC?.