Support Library

DNS SERVFAIL Explained

What DNS SERVFAIL means, its common causes, and how to tell DNSSEC failures from broken name servers with paired dig, +cdflag, delv and EDE checks.

Author
CategoryDNS Failure Modes & Misconfigurations
Length6 minute read
UpdatedOctober 24, 2026

The short answer

SERVFAIL (response code 2) means the resolver you asked could not produce an answer. It says nothing about whether the name exists. The resolver tried and failed, usually because the domain's DNSSEC did not validate, because none of the domain's name servers gave a usable reply, or because of a problem in the resolver itself.

The fastest way to tell these apart is to ask a validating resolver twice, once normally and once with checking disabled:

$ dig @1.1.1.1 example.com A

$ dig @1.1.1.1 example.com A +cdflag

If the first fails and the second answers, DNSSEC validation is the most likely cause. If both fail, look at the delegation and the authoritative servers.

Common causes

CauseWhat is going onTypical clue
DNSSEC validation failureThe parent publishes a DS record, but the zone's keys or signatures do not match it, have expired, or are missingOnly validating resolvers fail; +cdflag answers
Unreachable or lame name serversEvery listed server times out, refuses, or answers without authority for the zoneFails with and without +cdflag; direct queries to the servers fail
Broken delegationParent NS records point at names that do not resolve, or glue is wrongFails everywhere; dig +trace stops at the referral
Malformed or oversized responsesResponses that fail over UDP and cannot be retried over TCP, often because of a firewallWorks with +tcp from some networks only
Resolver policy or faultThe resolver's upstream is down, or it is configured to fail certain namesOnly one resolver fails; others answer

Requesting DNSSEC data is not validating it

Two dig options are often mistaken for DNSSEC checks. +dnssec sets the DO bit, which asks the server to include signatures (RRSIG records) in the reply. dig does not check those signatures. +trace follows the delegation from the root, which is useful for finding a broken referral, but it does not validate anything either.

Validation is done by a validating resolver, or by delv, which ships with BIND and validates the answer itself using the root trust anchor. When a validating resolver succeeds, it sets the AD (Authenticated Data) flag. AD is the resolver's statement that it validated the answer. Its absence on its own does not mean DNSSEC is broken: the zone may simply be unsigned, or the resolver may not validate.

CommandWhat it tells you
dig @1.1.1.1 example.com A +dnssecThe answer from a validating resolver, with signatures, and the AD flag if it validated
dig @1.1.1.1 example.com A +dnssec +cdflagThe same question with validation turned off for this query
delv example.com AValidates locally and prints ; fully validated or the reason it failed
dig +trace example.com AEach referral from the root down, to find where the delegation breaks

A query that answers with +cdflag while the normal query returns SERVFAIL is strong evidence of a validation problem, not final proof. Confirm it by looking at the DS, DNSKEY and RRSIG records, as described in Debugging DNSSEC validation errors.

Extended DNS Errors tell you why

Many resolvers now attach an Extended DNS Error (EDE), defined in RFC 8914, to a SERVFAIL. Recent dig versions print it in the OPT pseudo-section, and DoH JSON interfaces show it in a comment. Cloudflare's answer for dnssec-failed.org, a domain that is broken on purpose for testing, looks like this:

$ curl --silent --header 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=dnssec-failed.org&type=A'
{"Status":2,"AD":false,"CD":false,
 "Comment":["EDE(9): DNSKEY Missing no SEP matching the DS found for dnssec-failed.org."]}
EDE codeMeaning
6 DNSSEC BogusValidation failed for a reason not covered by a more specific code
7 Signature ExpiredAn RRSIG's validity window has ended, often because re-signing stopped
9 DNSKEY MissingNo DNSKEY in the zone matches a DS at the parent
10 RRSIGs MissingThe zone is expected to be signed but the answer has no signatures
22 No Reachable AuthorityNone of the domain's name servers answered
23 Network ErrorThe resolver hit a network error talking to an authoritative server

Checking the authoritative servers

If +cdflag does not help, ask each of the domain's name servers directly. First get the delegation from the parent, then query every server for the zone's SOA:

$ dig +norecurse +noall +authority @a.gtld-servers.net example.com NS

$ dig +norecurse @ns1.dns-provider.example.net example.com SOA

Use the parent server for your own TLD and the server names it returns. A healthy server replies with the aa (authoritative answer) flag set and the zone's SOA. A timeout, REFUSED, or a reply without aa points at a lame or unreachable server, covered in Lame Delegation. Check each server's IPv4 and IPv6 address, because a resolver can fail on one and not the other.

Fixing it

  • DNSSEC: make the DS at the parent match a key the zone publishes, or remove the DS through your registrar if the zone is no longer signed. Then wait for the old DS TTL before expecting every resolver to recover.
  • Name servers: fix or remove the servers that do not answer for the zone, and make the NS records at the parent and in the zone agree.
  • Transport: allow DNS over TCP on port 53 to the authoritative servers, and keep responses below about 1,232 bytes where possible.
  • Resolver: if only one resolver fails, contact its operator, or flush its cache if it is yours.

A resolver may cache a SERVFAIL for a short time, so a fix can take a few minutes to show even after the cause is gone.

How DNS Panopticon helps

Domain Visualizer sends its lookups to public resolvers over DNS over HTTPS and requests DNSSEC data. Its DNSSEC findings compare the DS and DNSKEY records it receives with the resolver's AD flag, which separates an unsigned zone from one that is signed but not validating. It does not yet have a dedicated SERVFAIL finding: when a resolver fails a lookup, the affected records simply show as missing. If Visualizer reports no name servers or no SOA for a domain you know exists, run the paired +cdflag test above.

Sources and further reading