SERVFAIL DNS Response Code

What’s actually happening

Unlike NXDOMAIN, this isn't "the name doesn't exist" — it's "I couldn't find out." dig returns status: SERVFAIL (RCODE 2) and no answer section. The same query may succeed against one resolver and fail against another, which is the signature of DNSSEC validation failures: validating resolvers (1.1.1.1, 8.8.8.8) return SERVFAIL while a non-validating one answers fine. Browsers surface it as a generic "can't be reached."

Common causes

• DNSSEC misconfiguration — a bad or expired RRSIG, or a DS record at the parent that doesn't match the zone's current key. Validating resolvers refuse the answer.
• Authoritative nameservers are all unreachable or timing out, so the resolver gives up.
• Broken delegation or missing/incorrect glue records — the parent points at nameservers that don't actually serve the zone.
• A zone file error (syntax problem, failed transfer) leaving the authoritative servers unable to answer.
• Network path between the recursive resolver and the authoritative servers is filtered or down.

How to fix it

1. Confirm it's SERVFAIL and not NXDOMAINdig example.com — look for 'status: SERVFAIL' in the header. SERVFAIL means the lookup failed; NXDOMAIN means the name is confirmed nonexistent. They point at completely different fixes.
2. Isolate DNSSECdig example.com +cd (the +cd flag disables DNSSEC checking). If +cd succeeds while a plain query fails, you have a DNSSEC validation problem. Cross-check at dnsviz.net or dnssec-debugger.verisignlabs.com for the exact broken signature or DS mismatch.
3. Fix the DNSSEC chainRe-sign the zone if signatures expired, or update the DS record at the registrar to match the live DNSKEY. If you can't fix it quickly and the zone doesn't truly need DNSSEC, removing the DS record at the parent (then waiting for TTL) stops validating resolvers from rejecting it.
4. Test the authoritative servers directlyFind them with dig example.com NS, then query each: dig @ns1.provider.com example.com. A timeout or REFUSED from the authoritative server itself means the problem is the delegation or the server, not your resolver.
5. Repair delegation / glueMake sure the NS records at the registrar match the nameservers actually hosting the zone, and that glue records (the A records for in-zone nameservers) are present and correct at the parent.