A DNS query that returns SERVFAIL tells you that the server could not complete the resolution process. The domain may exist and its records may be configured, but something prevented the responding resolver from producing a reliable answer. Because several different failures share this response code, the useful question is not simply “Is DNS down?” but “At which step did resolution fail?”

Effective troubleshooting compares resolvers, queries authoritative servers directly, checks delegation, reviews DNSSEC validation, and looks for timeouts or inconsistent data. This guide presents a repeatable process for narrowing the problem without changing records blindly.

What does DNS SERVFAIL mean?

SERVFAIL is DNS response code 2, meaning the name server encountered a failure while processing the request. It differs from NXDOMAIN, which says the queried name does not exist, and from NOERROR with an empty answer, which may mean the name exists but has no record of the requested type.

A recursive resolver can return SERVFAIL when it cannot reach an authoritative server, receives unusable responses, detects a broken delegation, fails DNSSEC validation, reaches a query limit, or encounters another internal error. The short response does not identify the cause by itself, so the next task is to collect evidence.

Start with a reproducible query

Use a command-line DNS tool so you can see the response code, flags, answering server, timing, and record sections. For example:

dig example.com A
dig example.com A @1.1.1.1
dig example.com A @8.8.8.8

The site’s existing Dig command guide explains the output and common query forms. Another beginner-friendly reference is this Dig command walkthrough. Both are useful before interpreting differences between recursive and authoritative answers.

Record the exact name, type, resolver, time, and result. A failure for an AAAA query does not prove that the A record fails, and a cached answer from one resolver does not prove that every resolver sees the same state.

Compare multiple recursive resolvers

Ask at least two independent recursive resolvers for the same name and type. If one returns a valid answer while another returns SERVFAIL, the zone may be healthy and the problem may involve cached state, DNSSEC validation, transport behavior, or a resolver-specific issue. If every resolver fails, focus on delegation and the authoritative service.

Also compare the failing network with a different connection. A local firewall, filtering product, VPN, or router can affect DNS traffic. Testing from another network helps separate a domain-wide fault from a client or access-network problem.

Trace the delegation path

The +trace option follows delegation from the root toward the target zone:

dig +trace example.com A

Look for the point where useful responses stop. Common delegation problems include nameservers listed at the parent that do not serve the child zone, missing glue for in-bailiwick nameservers, unreachable server addresses, and inconsistent NS sets between parent and child.

A delegation can appear correct in a control panel while the live parent zone contains older or different data. Query the parent-side information and each delegated nameserver rather than relying only on the provider interface.

Query authoritative servers directly

After identifying the delegated nameservers, resolve their addresses and query each one:

dig example.com A @ns1.example.net
dig example.com SOA @ns1.example.net
dig example.com NS @ns1.example.net

A healthy authoritative server should answer consistently and set the authoritative-answer flag for data in its zone. If one server times out or has an older SOA serial while the others respond correctly, investigate synchronization, firewall rules, routing, and service health on that server.

Test over both UDP and TCP when the symptoms suggest truncation or transport filtering:

dig example.com A @ns1.example.net
dig +tcp example.com A @ns1.example.net

DNS normally begins with UDP for many queries, but TCP is required in several situations and must not be blocked indiscriminately. Large responses, DNSSEC data, and retry behavior can expose a firewall that permits UDP while dropping TCP.

Check DNSSEC validation

A DNSSEC-validating resolver returns SERVFAIL when it cannot build a valid chain of trust or verify signed data. Typical causes include an incorrect DS record at the parent, expired signatures, missing signatures, a key rollover performed in the wrong order, or inconsistent signed responses across authoritative servers.

Compare a normal query with one that disables validation checking at the diagnostic client:

dig example.com A +dnssec
dig example.com A +dnssec +cdflag

If a validating lookup fails but the checking-disabled query returns data, investigate DNSSEC rather than treating the returned data as proof that the zone is healthy. Review the site’s guide on how to use DNSSEC securely for the purpose of signatures and the chain of trust.

Do not remove the parent DS record as an unplanned first response. A DNSSEC repair must coordinate the child-zone keys, signatures, and parent delegation. Improper changes can extend the outage or remove the intended protection.

Inspect the zone for structural problems

Authoritative data can be reachable yet still lead resolvers into failure. Check for:

  • CNAME loops: One alias ultimately points back to itself through one or more names.
  • Excessive alias chains: Long chains consume resolver work and introduce more failure points.
  • Broken dependencies: An NS, MX, or CNAME target depends on a name that cannot be resolved.
  • Inconsistent zone copies: Authoritative servers publish different records or SOA serials.
  • Invalid server configuration: The service loads an incomplete zone, rejects queries, or is not authoritative for the expected name.

Validate the zone file with the authoritative server software’s checking tools before loading it. After a change, query each authoritative server directly to confirm that the intended version is active everywhere.

Separate propagation from failure

DNS caches can temporarily preserve older positive or negative answers after a planned change. That behavior is often described as propagation, but an actual SERVFAIL usually indicates that a resolver could not complete or validate resolution, not merely that it retained an old value.

The article Understanding DNS propagation explains TTL-driven cache timing. Use TTL and cache history to interpret different answers, but continue investigating when resolvers consistently return a failure code.

Look for Extended DNS Error details

Some resolvers attach an Extended DNS Error option that provides a more specific reason, such as DNSSEC bogus data, no reachable authority, a network error, or a response considered stale. Recent versions of dig may display this information in the response.

Extended error text is diagnostic context rather than a replacement for the DNS response code, and support varies. The standardized codes and their intended use are defined in RFC 8914: Extended DNS Errors.

A practical SERVFAIL checklist

  1. Repeat the exact query and save the full output.
  2. Compare at least two independent recursive resolvers.
  3. Run a trace and verify the parent delegation and glue.
  4. Query every authoritative nameserver directly for A, SOA, and NS data.
  5. Test UDP and TCP reachability.
  6. Compare DNSSEC-validating and checking-disabled diagnostic results.
  7. Inspect aliases, dependencies, SOA serials, signatures, and server logs.
  8. Fix the identified layer, then retest authoritative and recursive paths.

Conclusion

DNS SERVFAIL is a symptom, not a root cause. The fastest route to a repair is to divide resolution into layers: client and network, recursive resolver, delegation, authoritative servers, zone data, and DNSSEC validation. Controlled queries at each layer reveal whether the fault is local, cached, unreachable, inconsistent, or cryptographically invalid—allowing you to correct the real problem instead of making speculative DNS changes.