SERVFAIL Errors — Causes and Fixes

SERVFAIL is the DNS error you don't want to see in production. Unlike NXDOMAIN (which is a clean "no"), SERVFAIL means something went wrong — and identifying which something requires structured diagnosis. This page walks through it.

What SERVFAIL actually means

SERVFAIL is DNS response code RCODE 2 ("server failure"). It signals that a resolver attempted to answer the query and couldn't complete it successfully. The protocol is deliberately vague — it doesn't tell you whether the problem is at the resolver, at the authoritative nameserver, in the network between them, or in DNSSEC validation.

Compare to other error states:

• NXDOMAIN: name definitely doesn't exist. See NXDOMAIN explained.
• REFUSED: server explicitly refused to answer (often access-control or wrong server).
• timeout: server didn't respond at all.
• SERVFAIL: server tried, failed, gave up.

The three most common causes in 2026

1. DNSSEC validation failure (by far the most common)

If your zone is DNSSEC-signed and the signature chain is broken, validating resolvers refuse to serve the answer. Most modern public resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9, most ISP resolvers) validate by default. Result: SERVFAIL to the end user.

Specific failure modes:

• Missing or wrong DS record at the registrar. After a KSK rollover, you must update the DS record with your registrar so the parent zone (.com etc.) attests to the new key. If the DS doesn't match the published DNSKEY, validation breaks.
• Expired RRSIG signatures. Each signature has an expiry date. If the zone isn't re-signed in time, signatures expire and resolvers reject them. Most managed providers (DNScale included) handle re-signing automatically, but home-rolled DNSSEC setups break here.
• Algorithm mismatch. Old algorithms (RSA-SHA1, algorithm 5/7) are increasingly rejected by validating resolvers. Modern best practice is ECDSA P-256 (algorithm 13) or RSA-SHA256 (algorithm 8).
• Broken chain of trust above your zone. Rare, but if a TLD's DNSSEC chain breaks, every signed zone under it goes SERVFAIL.

Diagnose:

dig +cd www.example.com @8.8.8.8     # checking-disabled — bypasses DNSSEC validation
dig www.example.com @8.8.8.8          # default — validates

If the first works and the second returns SERVFAIL, DNSSEC is the cause. Drill in with:

dig DS example.com @8.8.8.8           # what DS does the parent publish?
dig DNSKEY example.com @ns1.dnscale.eu # what DNSKEY does the authoritative server publish?

The DS hashes must match the published KSK. Tools like delv and dnssec-debugger sites give richer error messages.

See DNSSEC key management.

2. Broken NS delegation

The parent zone has NS records pointing at nameservers that aren't responding, or your authoritative nameservers don't know they're authoritative for this zone. Result: the resolver hits the listed nameservers, gets nothing useful, and returns SERVFAIL.

Diagnose:

dig +trace example.com

Watch the trace output. The .com TLD nameservers should hand off to the nameservers your registrar configured. Each of those nameservers should respond with the authoritative answer (AA flag set in dig output). If any nameserver in the delegation set fails to respond or doesn't admit it's authoritative, that's the issue.

Common scenarios:

• You changed nameservers at the registrar but the old NS records are still in the parent zone (registrar slow to publish).
• One of the listed NS records points at a hostname that doesn't resolve (typo, deleted A record).
• Your authoritative server is configured but the zone wasn't fully loaded (provisioning lag).

3. Authoritative server is unreachable or broken

The nameservers themselves are down, network-partitioned, or running into capacity issues. This is rare on managed providers but can happen during incidents.

Diagnose:

dig www.example.com @ns1.dnscale.eu @ns2.dnscale.eu @ns3.dnscale.eu

Query each authoritative server explicitly. If all return SERVFAIL or timeout, the provider is having an incident — check their status page. If only some respond, the others may be having localised issues; resolution still works as long as one nameserver is healthy, but you should report it.

Less common causes

• Resolver bug or stale state. Try a different resolver. If dig @1.1.1.1 works but dig @8.8.8.8 doesn't, the resolver is the problem. Stale trust anchors, ongoing internal incidents, or buggy validators can cause this.
• Truncation + no fallback. Very old resolvers (pre-EDNS0) can't handle large DNS responses. DNSSEC-signed answers are often large. Modern resolvers handle this fine; an extremely old one might not.
• Rate limiting. Some authoritative servers rate-limit aggressive resolvers. If a recursive resolver is sending unusually high query volumes, it may be temporarily blocked. Surfaces as SERVFAIL to clients of that resolver.
• Network blackholing or filtering. Firewalls or middleboxes between resolver and authoritative server dropping DNS packets.

The systematic SERVFAIL diagnostic

Run in order. The first divergence tells you the cause.

# 1. Authoritative direct (no caching, no validation)
dig www.example.com @ns1.dnscale.eu
# expect: returns the record (NOERROR)
 
# 2. Public resolver, checking-disabled
dig +cd www.example.com @8.8.8.8
# expect: returns the record (NOERROR)
# if SERVFAIL here: authoritative server has a problem
 
# 3. Public resolver, normal
dig www.example.com @8.8.8.8
# expect: returns the record (NOERROR)
# if SERVFAIL but step 2 succeeded: DNSSEC validation is failing
 
# 4. Different public resolver
dig www.example.com @1.1.1.1
# expect: same answer
# if differs from 8.8.8.8: resolver-specific issue
 
# 5. Trace from root
dig +trace example.com
# look for: each delegation hop succeeds; AA flag set on final answer
 
# 6. DNSSEC inspection
dig DS example.com @8.8.8.8
dig DNSKEY example.com @ns1.dnscale.eu
# DS hashes must match the published KSK

Decision matrix

Common pitfalls when fixing

1. Forgetting to update DS at the registrar after a KSK change. The most common DNSSEC SERVFAIL cause. Always coordinate KSK rollover with the registrar.
2. Disabling DNSSEC mid-incident. Tempting, but disabling DNSSEC on a zone that resolvers have learned is signed produces a worse failure (resolvers may treat unsigned responses as bogon). Better: fix the underlying signature issue.
3. Stale DNSKEY cache after rollover. Resolvers cache DNSKEY records for the DNSKEY TTL. After a rollover, validation may fail until the old DNSKEY ages out. Wait the TTL.
4. Querying the wrong resolver. Your machine's default resolver may differ from what your users hit. Replicate the user's environment when reproducing SERVFAIL — use the same OS, same VPN state, same browser.
5. Treating one resolver's SERVFAIL as universal. Resolver-specific issues exist. Always cross-check with at least two independent resolvers (8.8.8.8 + 1.1.1.1).

When SERVFAIL is genuinely the provider's problem

If step 1 of the diagnostic returns SERVFAIL — the authoritative nameserver itself is failing — escalate to your DNS provider. Provide:

• Exact name and record type queried.
• The full dig output including timing.
• The list of nameservers queried (use @ns1.X, @ns2.X, etc.).
• Your timezone and timestamp.

A good DNS provider (DNScale included) will treat authoritative SERVFAILs as P0 incidents and respond quickly. Cite their status page if relevant.

Related guides

• NXDOMAIN errors — causes and fixes
• DNSSEC key management
• DNS server types
• DNS propagation explained
• DNS attacks and threats

References

• IETF RFC 1035 — DNS basic specification (RCODE definitions)
• IETF RFC 4035 — DNSSEC validation requirements
• IETF RFC 8914 — Extended DNS Errors (gives richer SERVFAIL diagnostics when supported)