What does SERVFAIL mean and how do you fix it?

SERVFAIL is a DNS response code that means "server failure": the DNS server you asked couldn't produce a valid answer. Unlike NXDOMAIN, it doesn't say the name doesn't exist. It says something went wrong while trying to find out. The most common causes are a broken DNSSEC chain (such as an outdated DS record after changing DNS providers), authoritative nameservers that are down or unreachable, nameservers that don't actually host the zone, and expired DNSSEC signatures. To fix it, query with dig +cd to see whether DNSSEC is the cause, check the Extended DNS Error code if the resolver provides one, and test each authoritative nameserver directly.

A SERVFAIL is frustrating because the error itself carries so little information. One resolver returns it while another answers normally, or it appears for one domain on a network where everything else works. This guide explains what SERVFAIL really means, how resolvers decide to return it, how to get far more detail using Extended DNS Errors, and a step-by-step method for finding and fixing the cause, whether you own the domain or run the resolver.

What SERVFAIL Means

Every DNS response carries a response code (RCODE) in its header. The common ones are:

RCODE	Name	Meaning
0	NOERROR	The query succeeded. There may or may not be records in the answer.
2	SERVFAIL	The server couldn't process the query or get a valid answer.
3	NXDOMAIN	The name doesn't exist.
5	REFUSED	The server won't answer this query, usually by policy.

You see it in the header line of dig output:

dig broken.example A

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

In practice, almost every SERVFAIL you'll encounter comes from a recursive resolver. The resolver tried to follow the delegation to the domain's authoritative nameservers and either couldn't reach them, couldn't get a usable answer from them, or got an answer that failed DNSSEC validation. Rather than return something it can't trust, it returns SERVFAIL.

Authoritative servers can return SERVFAIL too, typically when a zone they're configured to serve failed to load, or when a secondary server's copy of the zone has expired.

How SERVFAIL Shows Up for Users

Users rarely see the word SERVFAIL. Instead, they see:

• In browsers: "This site can't be reached" with a DNS error, or a generic failure to load.
• In nslookup: ** server can't find example.com: SERVFAIL, or on Windows, Server failed.
• In applications and logs: "Temporary failure in name resolution", EAI_AGAIN, or "SERVFAIL" in resolver logs.

Because operating systems treat SERVFAIL as a temporary condition, applications often retry, which can make it look like slowness rather than a hard failure.

The Main Causes of SERVFAIL

1. DNSSEC Validation Failure

This is the most common cause for domains that use DNSSEC. A validating resolver checks the signatures on every answer. If the chain of trust from the root down to your domain is broken, it treats the answer as bogus and returns SERVFAIL.

Typical reasons include:

• A DS record at the registrar that doesn't match any key in the zone, usually left over after changing DNS providers.
• Expired RRSIG signatures, common on self-hosted servers where re-signing has stopped.
• A zone that's missing its DNSKEY or RRSIG records while the parent still publishes a DS record.
• An algorithm mismatch between the DS record and the zone's keys.

The key characteristic is that validating resolvers (Google, Cloudflare, Quad9 and many ISPs) fail while non-validating resolvers answer normally.

2. All Authoritative Nameservers Unreachable

If every nameserver listed for the domain is down, blocked by a firewall, or too slow, the resolver eventually gives up and returns SERVFAIL. This also happens if the nameserver hostnames themselves don't resolve, for example when they're inside a domain that has expired.

3. Lame Delegation

If the parent zone delegates your domain to nameservers that aren't configured to serve it, they respond with REFUSED or with non-authoritative answers. When all the listed nameservers behave like this, the resolver has nowhere to get an answer and returns SERVFAIL.

4. Zone Failed to Load on the Authoritative Server

On self-hosted BIND, Knot, NSD or PowerDNS servers, a syntax error in the zone file can stop the zone loading. The server is then not authoritative for it and may return SERVFAIL or REFUSED for every query. A secondary server whose copy of the zone has passed the SOA expire time without a successful refresh also stops answering for it.

5. Resolver Problems

Sometimes the resolver itself is at fault. It may have lost upstream connectivity, be misconfigured, have a broken trust anchor, or have a clock so wrong that every DNSSEC signature looks expired or not yet valid. In this case SERVFAIL appears for many unrelated domains at once, not just one.

Step 1: Get More Detail with Extended DNS Errors

Modern resolvers can attach an Extended DNS Error (EDE), defined in RFC 8914, that explains why a query failed. Recent versions of dig display it automatically. Cloudflare's 1.1.1.1 and several other public resolvers include EDE codes in their responses:

dig @1.1.1.1 dnssec-failed.org A

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

dnssec-failed.org is a domain deliberately kept with broken DNSSEC for testing, which makes it useful for checking your own resolver's behaviour.

The EDE codes you're most likely to see with SERVFAIL are:

EDE code	Name	Likely cause
6	DNSSEC Bogus	Signatures don't validate
7	Signature Expired	RRSIG records have passed their expiry time
8	Signature Not Yet Valid	Signatures are dated in the future, or the resolver's clock is wrong
9	DNSKEY Missing	No key in the zone matches the parent's DS record
10	RRSIGs Missing	The zone is expected to be signed but signatures are absent
22	No Reachable Authority	None of the authoritative nameservers responded
23	Network Error	A network problem prevented resolution

If you have an EDE code, it often tells you exactly what to fix. If not, work through the following steps.

Step 2: Test Whether DNSSEC Is the Cause

The +cd (checking disabled) flag tells the resolver to skip DNSSEC validation. Compare a normal query with one using +cd:

dig @8.8.8.8 example.com A +noall +comments | grep status
dig @8.8.8.8 example.com A +cd +noall +comments | grep status

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7124
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32988

If the normal query fails and the +cd query succeeds, the problem is DNSSEC. Next, find out exactly where the chain breaks.

Compare the DS and DNSKEY Records

The DS record in the parent zone must match one of the keys (normally the KSK) in your zone:

dig example.com DS +short
dig example.com DNSKEY +multi +noall +answer

2371 13 2 1F987CC6583E92DF0890718C42A1D2D4EE4C5A5D8F2F8EE5E3D1A5D24A9B7C2E

example.com.		3600 IN DNSKEY 257 3 13 (
				mdsswUyr3DPW132mOi8V9xESWE8jTo0d
				xCjjnopKl+GqJxpVXckHAeF+KkxLbxIL
				fDLUT0rAK9iUzy1L53eKGQ== ) ; KSK; alg = ECDSAP256SHA256 ; key id = 9481

In the DS record, the first number (2371) is the key tag of the key it refers to. In this example the zone's only KSK has key id 9481, so the DS record points at a key that no longer exists. That's the classic signature of a DNS provider change where the old DS record was never removed.

Use delv for a Validation Trace

delv ships with BIND's utilities and performs DNSSEC validation itself, explaining what it finds:

delv @1.1.1.1 example.com A +vtrace

Look for lines mentioning no valid signature found, insecurity proof failed or broken trust chain. For a visual view of the whole chain, DNSViz (dnsviz.net) shows every DS, DNSKEY and RRSIG relationship and highlights the broken link in red.

Fixing DNSSEC Failures

Problem	Fix
DS at registrar doesn't match any key	Replace it with the DS record your current DNS provider shows, or remove it to disable DNSSEC
Signatures expired	Re-sign the zone and fix automatic signing on your server
Zone unsigned but DS present	Enable DNSSEC at the DNS provider, or remove the DS record
Algorithm mismatch	Use the algorithm number your provider gives when creating the DS record

After changing the DS record, resolvers may keep the old DS cached for its TTL, often one or two days at large TLDs. The domain will start resolving on each resolver as its cached copy expires.

Step 3: Test Each Authoritative Nameserver

If +cd doesn't help, the problem is getting an answer at all. Find the nameservers the parent zone delegates to, then query each one directly with recursion off:

dig +trace example.com A | tail -n 12

for ns in ns1.example.net ns2.example.net; do
  echo "== $ns"
  dig @"$ns" example.com SOA +norecurse +time=3 +tries=1 +noall +comments +answer | grep -E "status|flags|SOA"
done

A healthy nameserver returns status: NOERROR, the aa (authoritative answer) flag, and an SOA record:

== ns1.example.net
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4412
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
example.com.		3600	IN	SOA	ns1.example.net. hostmaster.example.com. 2026101801 7200 3600 1209600 300
== ns2.example.net
;; communications error to 198.51.100.53#53: timed out

Here, ns2 isn't responding. One failing nameserver usually causes slowness rather than SERVFAIL, because resolvers try the others. If all of them fail, return REFUSED, or answer without the aa flag, you've found the cause.

Also make sure the nameserver names themselves resolve:

dig ns1.example.net A +short
dig ns2.example.net A +short

Step 4: Check the Zone on Self-Hosted Servers

If you run your own authoritative DNS with BIND, validate the zone file and check that it loaded:

sudo named-checkconf
sudo named-checkzone example.com /etc/bind/zones/db.example.com
sudo rndc zonestatus example.com

When the zone is valid, named-checkzone prints:

zone example.com/IN: loaded serial 2026101801
OK

A failure tells you the line number and the problem, such as a CNAME alongside other records, a missing trailing dot, or an invalid TTL. Fix it, increment the serial, and reload:

sudo rndc reload example.com

For DNSSEC-signed zones on BIND, check signing status and key timing:

sudo rndc dnssec -status example.com

Step 5: If You Run the Resolver

When users report SERVFAIL for many unrelated domains, look at the resolver itself.

1. Check the clock: DNSSEC depends on accurate time. A server whose clock is hours or days off will fail validation for signed domains.

timedatectl status

2. Check upstream connectivity: Can the resolver reach root and TLD servers over UDP and TCP port 53?

dig @a.root-servers.net . NS +norecurse +time=3
dig @a.root-servers.net . NS +norecurse +tcp +time=3

3. Turn up logging to see the reason: In Unbound, val-log-level logs why validation failed:

server:
    val-log-level: 2
    log-servfail: yes

Reload Unbound and watch the log. Each failure is logged with the name, type and reason.

4. Clear cached failures once you've fixed the cause:

sudo unbound-control flush_bogus
sudo unbound-control flush_zone example.com

On BIND, use rndc flushtree example.com.

Negative Trust Anchors

If a domain your users need has broken DNSSEC and the owner can't fix it quickly, a resolver operator can temporarily disable validation for that domain alone with a negative trust anchor. In BIND:

sudo rndc nta -lifetime 1d example.com

In Unbound, add domain-insecure: "example.com" to the server: section. Use this sparingly and remove it once the domain is fixed, because it switches off DNSSEC protection for that name.

SERVFAIL Diagnostic Summary

Observation	Probable cause
Fails on validating resolvers, works with +cd	DNSSEC chain broken
EDE 9 or DS key tag doesn't match DNSKEY	Stale DS record after changing providers
EDE 7	Expired signatures
EDE 22, all nameservers time out	Authoritative servers down or blocked
Nameservers return REFUSED or no aa flag	Lame delegation
Only one domain fails on self-hosted DNS	Zone failed to load
Many unrelated domains fail on one resolver	Resolver clock, connectivity or configuration

---

FAQ: SERVFAIL

---

Conclusion

SERVFAIL means a DNS server tried and failed to get a valid answer. For domain owners, the cause is usually a broken DNSSEC chain or nameservers that can't or won't answer for the zone. A quick comparison with dig +cd, any Extended DNS Error code, and a direct query to each authoritative nameserver will usually reveal which.

Fix DNSSEC problems by making the DS record at your registrar match your current DNS provider's keys, fix delegation problems by making sure every listed nameserver actually serves your zone, and fix self-hosted servers by validating the zone and checking signing. If you run the resolver, check its clock and connectivity, use validation logging to see the reason, and keep negative trust anchors as a short-term workaround only.