DNS SERVFAIL (RCODE 2): Find Whether It Is DNSSEC or a Dead Nameserver

SERVFAIL is DNS response code 2. RFC 1035 defines it as «Server failure - The name server was unable to process this query due to a problem with the name server.» In practice it almost always comes from a recursive resolver (your ISP, 8.8.8.8, 1.1.1.1, a corporate DNS) that could not produce an answer it trusts:

$ dig www.example.com @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31337
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Unlike NXDOMAIN, SERVFAIL says nothing about whether the name exists. It means «I could not find out». RFC 2308 allows resolvers to cache a server failure, but for no longer than five minutes, so a fix shows up quickly.

Modern resolvers often attach an Extended DNS Error (RFC 8914) to the SERVFAIL. Recent dig versions print it in the OPT pseudo-section, and it names the cause directly.

The DNSSEC row is the most common cause for a domain that «worked yesterday». Validating resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9) return SERVFAIL when signatures do not verify, while a non-validating resolver still answers. That split, one resolver failing and another working, is itself a strong DNSSEC signal.

1. Disable validation for one query. The +cd flag asks the resolver not to perform DNSSEC validation:

   dig www.example.com @1.1.1.1 +cd +short

   An answer with +cd and SERVFAIL without it means the zone's DNSSEC chain is broken.
2. Compare the DS record at the parent with the zone's keys:

   dig DS example.com +short
   dig DNSKEY example.com +short @ns1.example.com
   dig www.example.com +dnssec @ns1.example.com | grep RRSIG

   If the DS key tag matches no DNSKEY, publish the new DS at the registrar or remove the DS to turn DNSSEC off while you fix it. Check RRSIG expiry dates too. Walkthrough: how to check DNSSEC.
3. Query every authoritative server directly:

   for ns in $(dig +short NS example.com); do
     echo "== $ns"; dig @"$ns" www.example.com A +norecurse +time=3 +tries=1 | grep -E 'status|flags'
   done

   Each must answer NOERROR (or NXDOMAIN) with the aa flag. A timeout, REFUSED or a missing aa flag marks a dead or lame server: remove it from the delegation or configure the zone on it.
4. Follow the chain from the root with dig +trace www.example.com to see which step stops answering.
5. If only your own resolver fails, check that it can reach the Internet on port 53 over both UDP and TCP and that its root hints and trust anchor are current.

Most DNSSEC outages happen during a provider move. The registry still publishes a DS record that matches the old provider's signing key, the new provider signs with a different key (or not at all), and every validating resolver fails the domain. The safe order: remove the DS record at the registrar, wait for the DS TTL to expire, move the nameservers, then enable DNSSEC at the new provider and publish its DS. Background: DNSSEC.

dig www.example.com @8.8.8.8 | grep status
# status: NOERROR
dig www.example.com @1.1.1.1 +dnssec | grep -E 'status|flags'
# flags: qr rd ra ad;   (ad = validated)

Run it against at least two validating resolvers; a cached failure clears within five minutes. The DNS lookup shows what public DNS returns for the name right now.

• NXDOMAIN — the name does not exist
• ERR_DNS_MALFORMED_RESPONSE — the reply could not be parsed
• getaddrinfo ENOTFOUND — how Node.js reports a failed lookup
• Cloudflare error 1016 — Cloudflare could not resolve the origin
• DNSSEC — the signature chain behind most SERVFAILs