DNS SERVFAIL Explained: Causes and Step-by-Step Troubleshooting

DNS SERVFAIL Explained: Causes and Step-by-Step Troubleshooting

September 26, 2026

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.

DNS Amplification Attacks: How They Work and How to Reduce the Risk

DNS Amplification Attacks: How They Work and How to Reduce the Risk

September 21, 2026

A DNS amplification attack turns ordinary DNS infrastructure into a source of unwanted traffic aimed at a victim. The attacker sends relatively small queries with a forged source address, and misconfigured or exposed DNS servers send larger responses to that address. When the process is repeated through many servers, the victim receives a flood it never requested.

This attack combines two ideas: reflection hides the true source by directing replies elsewhere, while amplification makes the returned traffic larger than the traffic sent by the attacker. Understanding both parts helps DNS operators avoid becoming reflectors and helps organizations prepare defenses for large inbound floods.

How DNS reflection and amplification fit together

Reflection redirects the reply

Many traditional DNS exchanges use UDP. Because UDP does not establish a connection before data is sent, networks that permit source-address spoofing can allow a packet to claim that it came from the victim’s IP address. A DNS server then sends its answer to the forged address rather than to the attacker.

Amplification increases the traffic volume

A DNS response can be larger than its query. The exact difference depends on the question, the available records, protocol options, and the server’s response. Attackers seek situations where small requests trigger significantly larger replies, multiplying the traffic that reaches the victim.

The underlying resolver role is explained in What is the role of the Recursive DNS server?. A recursive resolver should normally serve an intended group of clients. When it accepts recursive queries from arbitrary Internet addresses, it can become an open resolver and a useful reflector for abuse.

Why DNS is attractive for reflection attacks

  • DNS is widely deployed. Authoritative and recursive servers are essential parts of Internet infrastructure.
  • UDP supports efficient queries. That efficiency also means the server can respond without a connection handshake.
  • Some resolvers are exposed unnecessarily. Incorrect access controls may allow anyone on the Internet to request recursion.
  • Responses vary in size. Some legitimate DNS answers contain multiple records, signatures, or other data and are much larger than the request.
  • Source spoofing still exists. Networks that do not filter packets with implausible source addresses enable reflection.

Large DNS responses are not inherently malicious. DNSSEC signatures, IPv6 records, mail records, and other legitimate data can all increase response size. The security problem is the combination of spoofed traffic, exposed services, and repeated requests designed to create a flood.

Signs that a resolver may be abused

Operators should look for behavior that differs from the server’s normal client and query profile. Possible indicators include:

  • a sudden increase in queries from many unrelated or unexpected addresses;
  • repeated requests for the same names or record types;
  • an unusual ratio of outbound response bytes to inbound query bytes;
  • high UDP response volume without a matching increase in legitimate users;
  • queries arriving on interfaces or from networks that should not use recursion;
  • bandwidth, CPU, or packet-rate alerts on DNS systems and edge devices.

These signals require context. A public authoritative server naturally receives queries from many networks, while a corporate recursive resolver should have a much narrower client population. Baselines and role-specific alerting are more useful than one universal threshold.

How recursive DNS operators can reduce abuse

Disable open recursion

Recursive service should be limited to authorized clients through access-control lists, network boundaries, and firewall policy. If a server is intended only for an internal network, it should not answer recursive requests from the public Internet.

Separate recursive and authoritative roles

Running recursion and public authoritative service on separate systems makes access policy clearer and reduces the chance that a necessary public-facing server accidentally provides recursion to everyone.

Keep DNS software and policy current

Apply supported software updates, remove unnecessary features, review listening interfaces, and test the service externally. Configuration drift can expose recursion even if the original deployment was secure.

Monitor response volume and client eligibility

Track packets, bytes, response sizes, query types, source networks, and rejected requests. Alerts should highlight traffic from outside approved client ranges and sudden changes in the response-to-query ratio.

How authoritative DNS operators can help

Public authoritative servers must answer Internet queries, so they cannot use the same client allowlist as private resolvers. They can still reduce abuse and improve resilience:

  • Use response rate limiting where appropriate. Carefully configured RRL can reduce repeated similar responses without blocking normal traffic.
  • Serve minimal necessary data. Avoid unnecessary additional records and remove obsolete zone content while preserving standards-compliant answers.
  • Distribute capacity. Anycast, multiple locations, and independent authoritative providers can prevent one site from becoming the only bottleneck.
  • Monitor answer correctness as well as availability. A reachable server returning inconsistent data is still unhealthy.
  • Prepare upstream mitigation. Large floods may need filtering or scrubbing before they reach the authoritative network.

A Managed DNS service may provide distributed capacity, monitoring, and mitigation features, but organizations should verify the actual architecture and incident process rather than relying only on a product label.

Source-address validation is essential

Reflection depends on forged source addresses. Network operators can reduce this capability by filtering traffic whose claimed source should not be reachable through the interface where it arrived. This practice is often described as ingress or egress filtering, depending on where the check occurs.

DNS administrators cannot solve global source spoofing alone. Internet service providers, hosting networks, cloud platforms, and enterprise edge operators all contribute by validating source addresses close to where traffic enters their networks.

Protecting an organization that is the target

A victim cannot directly reconfigure the third-party reflectors sending the traffic. Defensive preparation should therefore focus on absorbing, distributing, or filtering the flood before it overwhelms the destination:

  • coordinate DDoS procedures and escalation contacts with network providers;
  • use upstream scrubbing or managed protection sized for realistic attack volumes;
  • distribute public services across independent locations and networks;
  • monitor packet rate and bandwidth, not only application CPU and request logs;
  • maintain tested incident runbooks for routing, filtering, communication, and recovery;
  • preserve evidence and timestamps for provider coordination and later analysis.

The historical examples in 4 DDoS attacks in recent history show why mitigation capacity and coordination must exist before an incident starts.

Controls that address different problems

Several useful DNS controls are sometimes confused with amplification defenses:

  • DNSSEC authenticates DNS data but does not prevent a server from receiving spoofed queries. Its larger signed responses also make careful server policy important.
  • Short TTL values change cache duration; they do not stop reflected traffic.
  • DNS caching improves efficiency for clients but does not secure an open resolver exposed to arbitrary users.
  • Blocking all UDP DNS can break legitimate service and force different failure modes. Defenses should be role-aware and standards-compatible.

A practical defensive checklist

  1. Inventory every DNS server and identify whether it is recursive, authoritative, or both.
  2. Test from outside approved networks to confirm that private recursion is not publicly available.
  3. Restrict recursive clients and separate public authoritative service where possible.
  4. Enable suitable rate controls, logging, and traffic baselines.
  5. Ask connectivity providers how they implement source-address validation.
  6. Confirm DDoS escalation paths, mitigation capacity, and monitoring coverage.
  7. Retest after software, firewall, network, or DNS configuration changes.

Conclusion

DNS amplification attacks succeed when forged queries can reach servers that return larger replies to the victim. No single control solves the entire problem. Restricting recursion, validating source addresses, minimizing unnecessary responses, applying rate controls, distributing authoritative capacity, and preparing upstream mitigation each remove a different part of the attack path.

For an overview of this and other threats, see 5 DNS attacks that could affect you. Detailed guidance for preventing recursive nameservers from becoming reflectors is provided in RFC 5358: Preventing Use of Recursive Nameservers in Reflector Attacks.