DNS SERVFAIL Explained: Causes and How to Diagnose It with dig

SERVFAIL is DNS response code 2, "server failure." You see it in dig output, in nslookup as "server can't find example.com: SERVFAIL" (Windows prints "Server failed"), or in an application as a generic resolution error:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41123
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

It is a deliberately vague answer. It tells you that the resolver you asked could not produce a usable result, not that the name does not exist (that is NXDOMAIN) and not that you are not allowed to ask (that is REFUSED). The comparison is in NXDOMAIN vs SERVFAIL vs REFUSED. The work is to find out which step inside the resolver failed. See also the glossary entry for SERVFAIL.

The usual causes

1. DNSSEC validation failure. The domain is signed, but the signatures do not validate, often because of an expired signature or a DS record at the registrar that no longer matches the zone's keys. Validating resolvers return SERVFAIL; non-validating ones return the answer normally.
2. Authoritative servers do not answer. All the nameservers for the zone are down, firewalled, or timing out.
3. Broken delegation. The parent zone lists nameservers that do not host the zone; see lame delegation.
4. Inconsistent or malformed answers from the authoritative side, such as a CNAME chain that loops or a server returning garbage for certain query types.
5. Resolver trouble. The recursive resolver itself is overloaded, misconfigured, or cannot reach the internet.

Step 1: compare resolvers

dig example.com A @8.8.8.8
dig example.com A @1.1.1.1
dig example.com A @9.9.9.9

If every resolver returns SERVFAIL, the problem is the domain's DNS. If only your ISP or office resolver fails, the problem is that resolver, so switch or fix it. Mixed results (some fail, some work) strongly suggest DNSSEC, since resolvers differ in validation and caching.

Step 2: test whether DNSSEC is the cause

The +cd flag sets "checking disabled," which asks the resolver to skip validation:

dig example.com A @8.8.8.8 +cd

If the plain query returns SERVFAIL and the +cd query returns an answer, DNSSEC validation is the culprit. Confirm with the DNSSEC Checker, which looks at the DS record in the parent and the DNSKEY in the zone. Fix options:

• Re-sign the zone or fix the signing automation that stopped (expired RRSIG records are a classic).
• Update the DS record at the registrar so it matches the current key, or remove it entirely if you no longer sign, and wait out the parent TTL.
• After a DNS provider move, remember that the old provider's keys no longer apply. See DNSSEC explained and change nameservers without downtime.

Do not remove a DS record casually while resolvers still hold cached copies. Follow your registrar's documented sequence.

Step 3: read the extended error

Many modern resolvers add Extended DNS Errors (RFC 8914), and recent dig versions print them:

; EDE: 9 (DNSKEY Missing)
; EDE: 22 (No Reachable Authority)
; EDE: 7 (Signature Expired)

These codes narrow the cause immediately: signature expired points to DNSSEC; no reachable authority points to unresponsive nameservers. If your dig does not print them, query a public resolver that supports EDE and use a newer dig.

Step 4: walk the delegation yourself

dig example.com NS +short
dig +trace example.com A

+trace starts at the root and follows referrals, bypassing your resolver. Look for the first step that fails: a timeout, a referral to servers that return REFUSED, or a parent that lists different nameservers than the zone. Then query each nameserver directly:

dig example.com SOA @ns1.example-dns.com +norecurse
dig example.com SOA @ns2.example-dns.com +norecurse

A healthy authoritative server answers with the aa flag and the same SOA serial on all servers. A timeout, REFUSED, or no aa means that server is the problem. The Nameserver Lookup and DNS Checker show what the world sees, and DNS History shows whether the NS set changed recently.

Step 5: check the domain itself

An expired or suspended domain can lose its delegation or get replaced by registry hold NS records. Run WHOIS Lookup and look at status and expiry. See expired domain recovery if the date has passed.

Step 6: remember caching

If only one app fails, check which resolver it uses (container DNS, VPN split DNS, systemd-resolved) with resolvectl query example.com. Many resolvers also cache SERVFAIL briefly, so a fix may take a few minutes to show up.

How to verify

Re-run the dig commands against several public resolvers and confirm NOERROR with an answer. Check the DNS Checker for a consistent result in multiple regions. Then set up an Uptime Monitor with DNS-change alerts, so an expired DNSSEC signature or lost delegation alerts you before customers do.

Next steps

• Compare codes in NXDOMAIN vs SERVFAIL vs REFUSED.
• Learn about lame delegation.
• Check signatures with the DNSSEC Checker.
• Read DNS explained for website owners.

FAQ

Does SERVFAIL mean the domain does not exist?

No. A nonexistent name returns NXDOMAIN. SERVFAIL means something went wrong while resolving it.

Why does the domain work on one network and SERVFAIL on another?

Different resolvers validate DNSSEC differently or cache different states. Compare them with and without +cd.

Can I fix SERVFAIL as a visitor?

You can switch to another public resolver or flush your local cache. If the cause is the domain's DNS, only the owner can fix it.

How long until a fix works?

It depends on negative-cache and record TTLs at each resolver. Expect minutes in the best case and up to the TTL of the affected records.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.