SERVFAIL means the DNS resolver tried to answer your query and something upstream went wrong, so it gave up. It is not "this name does not exist" (that is NXDOMAIN). It is closer to "I could not get a trustworthy answer," and the three usual reasons are a DNSSEC validation failure, a broken or lame delegation, or authoritative nameservers that are unreachable or misconfigured.
This guide shows you how to read a SERVFAIL, run two quick tests that split the causes apart, and fix each one.
What SERVFAIL is telling you
When you run a lookup and see status: SERVFAIL in the header, the resolver is reporting a server-side failure during its own work, not a problem with your typing. A recursive resolver returns SERVFAIL when it cannot complete resolution: the signatures did not validate, every authoritative server it tried failed or timed out, or the zone it reached is broken.
The important mental model is that SERVFAIL is often about the path to the answer, not the answer itself. The name may be perfectly valid; the resolver just could not stand behind a reply.
The single most useful test: dig +cd
The fastest way to tell whether DNSSEC is the culprit is the checking disabled flag. Run the query normally, then again with +cd:
dig example.com
dig example.com +cd
The +cd flag tells the resolver to skip DNSSEC validation. If the normal query returns SERVFAIL and the +cd query returns a real answer, DNSSEC validation is failing. If both return SERVFAIL, the problem is delegation or reachability, not signatures.
That one comparison decides which half of this guide you need.
Cause and fix at a glance
| Symptom | Likely cause | How to confirm | Fix |
|---|---|---|---|
Fails normally, works with +cd |
DNSSEC validation failure | dig DS example.com at parent vs dig DNSKEY example.com at authoritative |
Publish or correct the DS record, or re-sign the zone |
Fails even with +cd |
Broken or lame delegation | Query each NS directly for the SOA | Repair the NS set so every server answers authoritatively |
| Intermittent SERVFAIL | One unreachable nameserver | Test reachability on UDP and TCP port 53 | Restore the server or remove it from the delegation |
| SERVFAIL only for large answers | TCP 53 blocked by a firewall | dig example.com +tcp |
Allow TCP 53 through the firewall |
| SERVFAIL right after a change | Expired or mismatched signatures | Check RRSIG expiry in the answer | Re-sign the zone and confirm serials match |
Fixing a DNSSEC SERVFAIL
If +cd proved that DNSSEC is failing, the chain of trust is broken somewhere. The common breakages:
- The DS record at the parent does not match the current DNSKEY in your zone. This happens when you change providers or roll keys but forget to update the DS record at the registrar. Compare
dig DS example.com(parent) against the key set fromdig DNSKEY example.com(authoritative). If they do not correspond, update or remove the DS record at your registrar. - The signatures (RRSIG records) have expired. Each RRSIG has a validity window, often seven to thirty days. If your signer stopped renewing them, every validating resolver rejects the answers at once. Re-sign the zone and confirm fresh expiry dates.
- DNSSEC is enabled at the registrar but the zone is no longer signed (or vice versa). Either finish signing or remove the DS record so the domain is treated as insecure rather than broken.
A domain that is signed but broken is worse than one that is unsigned, because validating resolvers hard fail with SERVFAIL. If you are mid migration, the safe order is to remove the DS at the parent first, then change signing. For the concepts behind these records, see DNSSEC and CAA records explained.
Fixing a delegation or reachability SERVFAIL
If +cd still returns SERVFAIL, DNSSEC is not the issue. Now the resolver simply could not get a good answer from your authoritative servers.
- Test each nameserver directly. For every server in your NS set, run
dig SOA example.com @thatserver +norecurseand confirmstatus: NOERRORwith theaaflag set. A server that returns SERVFAIL or REFUSED is lame, and a resolver that lands on it will hand you SERVFAIL. Our nameserver delegation trace tests the whole chain for you and points at the failing server. For a deeper walkthrough, see lame delegation explained. - Check reachability on both protocols. Nameservers must answer on UDP and TCP port 53. A firewall that allows UDP but blocks TCP 53 causes SERVFAIL on large responses and on DNSSEC, which relies on TCP fallback.
- Confirm the zone itself is valid. A syntax error or a missing SOA on the authoritative server makes it fail to load the zone, so it returns SERVFAIL for everything in that domain.
- Verify the answers once resolution is restored. A quick DNS lookup confirms the A, MX, and TXT records are correct from every server, and a DNS propagation check confirms resolvers worldwide are now getting NOERROR instead of SERVFAIL.
SERVFAIL versus NXDOMAIN
These two get confused constantly, and they lead to opposite fixes. SERVFAIL is a server or validation failure on a name that may well exist. NXDOMAIN is a definitive "this name does not exist" from an authoritative server. If you are actually chasing a NXDOMAIN in the browser, that is a different problem covered in fixing DNS_PROBE_FINISHED_NXDOMAIN.
FAQ
Is SERVFAIL a problem on my computer or on the server? Usually the server side. SERVFAIL comes from the resolver failing to complete resolution, most often due to DNSSEC or authoritative server issues. Trying a second resolver can confirm it: if a public resolver also returns SERVFAIL, the fault is in the domain, not your machine.
Why does the same domain work on one network and fail on another?
Different resolvers validate DNSSEC differently and cache different states. A validating resolver will SERVFAIL on a broken signature while a non-validating one returns the answer, which is exactly why dig +cd is such a useful test.
Can a lame delegation cause SERVFAIL? Yes. If a resolver tries an authoritative server that does not answer authoritatively, and the others also fail or time out, the resolver returns SERVFAIL. Fixing the delegation removes the error.
How long does a SERVFAIL last after I fix it? Resolvers cache SERVFAIL for a short time, typically up to five minutes, separate from record TTLs. After a real fix, most resolvers recover within minutes, though the underlying record change still follows its own TTL.
Does re-signing the zone fix expired RRSIGs immediately? It fixes them at the authoritative server immediately, but validating resolvers may hold the old failing state briefly. Confirm fresh RRSIG expiry dates in the answer, then recheck after the negative cache window clears.
The habit that prevents most SERVFAILs is simple: whenever you touch DNSSEC keys or nameservers, verify DS against DNSKEY and test every authoritative server for an authoritative SOA before you consider the change done.