Diagnose a DNS SERVFAIL response

SERVFAIL is DNS response code 2: the server could not complete the request successfully. It covers many failure modes. Treat it as a symptom to localize, not as proof that DNSSEC, the authoritative provider, or the domain owner is at fault [1].

Scope the symptom

Record:

• exact name, type, and class;
• full response, including flags and any Extended DNS Error;
• resolver or server queried;
• whether recursion was requested;
• timestamp, network, and DNS view;
• whether every query fails or only some names or types; and
• the last known successful observation.

The recursive-resolver owner controls validation, caching, forwarding, and policy. The DNS provider controls authoritative publication. The registrant or registrar path controls parent NS, glue, and DS data.

Read-only checks

1. Review the DNS Lookup pathway and compare the exact query across named recursive resolvers.
2. Capture any Extended DNS Error code and text. Treat it as diagnostic context, not authenticated proof.
3. Obtain the parent referral and query every listed authoritative server directly for SOA, NS, and the failing name and type.
4. Compare UDP and TCP results where your diagnostic client supports both.
5. Capture parent DS, child DNSKEY, relevant RRSIG, and denial-of-existence records when DNSSEC validation is a supported hypothesis.
6. If the entire registered domain may be suspended or delegated incorrectly, review the Domain Registration Lookup pathway without treating registration data as authoritative DNS evidence.

RFC 8914 defines Extended DNS Errors because SERVFAIL alone cannot identify whether a failure came from DNSSEC, reachability, cached error, network behavior, or another cause [3].

Interpret the observations

Observation	Supported interpretation	Responsible owner
One resolver fails while others answer	The failure is scoped to a resolver, network path, view, policy, or cache	Resolver or network owner
All validating resolvers fail, but direct authorities answer consistently	DNSSEC validation is a supported hypothesis, not yet a conclusion	Parent DS and child signing owners
Authorities time out or refuse from multiple paths	Reachability, service, or delegation is a supported hypothesis	DNS provider or nameserver network owner
Authorities disagree	Zone load or publication is inconsistent	DNS provider
EDE identifies DNSSEC Bogus or DNSKEY Missing	The resolver reports a more specific validation result	Resolver plus DNSSEC control-plane owners
EDE identifies Cached Error	The observed resolver is serving a cached SERVFAIL	Recursive-resolver owner

A validating resolver must classify DNSSEC data according to the chain it can build. A bogus result commonly reaches a stub as SERVFAIL, but the same response code is used for other failures [2].

Likely causes

• stale or incorrect parent DS data relative to child DNSKEYs;
• missing, expired, not-yet-valid, or unsupported signatures or keys;
• unreachable, refusing, overloaded, or misconfigured authoritative servers;
• a lame delegation or missing nameserver address dependency;
• truncated responses that fail during TCP retry;
• malformed or internally inconsistent zone data;
• recursive forwarding, filtering, rate limits, or local policy;
• a cached failure; or
• a transient network path problem.

In-bailiwick nameserver targets can require glue in the parent referral to avoid a circular dependency [4].

Safe next actions

• Read-only: preserve the failing response, EDE, server, time, and comparison results before retrying.
• Reversible: if one resolver alone fails, report the evidence to its operator or review its forwarding and policy configuration. Do not alter the authoritative zone to accommodate one unexplained cache.
• Availability-impacting: if authoritative servers disagree or are unreachable, stop unrelated DNS changes and have the DNS provider restore a consistent, reachable zone.
• Availability-impacting: if the DNSSEC chain is demonstrably mismatched, use a reviewed DNSSEC recovery plan that coordinates parent DS and child signing. Do not delete DS or disable signing as an improvised first step.

Stop before changing state when the parent DS, active DNSKEYs, current zone export, or rollback owner is unknown.

Verification

Repeat the same name and type:

1. every intended authoritative server answers consistently;
2. delegation and glue lead to those servers;
3. DNSSEC validation is secure or intentionally insecure according to the reviewed plan;
4. named recursive resolvers return the expected response after any cached failure window; and
5. the original user journey succeeds at the next protocol layer.

Retain the before-and-after response codes, EDE values, server identities, and timestamps.

What this evidence does not prove

SERVFAIL alone does not prove:

• DNSSEC is enabled or broken;
• the domain is expired;
• every authoritative server is down;
• changing to a non-validating resolver is safe;
• an EDE statement is authenticated; or
• the website, email service, or origin caused the DNS response.

Next protocol layer

If resolvers disagree, continue with resolver disagreement diagnosis. If the symptom began after changing delegation, use website failure after a nameserver change. When DNS returns the expected address or alias, move to TLS, redirect, HTTP, CDN, and origin checks.