Using dig to Confirm If DNSSEC Validation Failures Cause SERVFAIL

A domain name suddenly stops resolving for users on public recursive resolvers like Google Public DNS or Cloudflare, returning a generic SERVFAIL status, while visitors on local corporate resolvers or legacy ISP connections report no issues at all. In web hosting and infrastructure support, this symptom frequently appears right after moving nameservers, changing DNS providers, or running an uncoordinated key rollover. When recursive resolvers enforce DNSSEC validation and encounter broken cryptographic proofs, they refuse to return the bad data and drop the response to a server failure. The challenge with SERVFAIL is that it is an umbrella response code. A resolver returns SERVFAIL when authoritative nameservers time out, when a CNAME target points to a non-existent loop, when network packets are dropped, or when cryptographic signatures fail validation. In another article, we explored How to Test If a Broken CNAME Target Is Causing DNS SERVFAIL, but when the domain structure itself looks completely healthy on the surface, DNSSEC is usually the silent culprit. Determining whether the issue is genuinely DNSSEC validation requires asking the resolver to bypass validation using targeted flags in dig.

Understanding the Mechanics of DNSSEC SERVFAIL

To understand why a domain disappears, we need to trace how validating recursive resolvers interact with DNSSEC. DNSSEC protects resolvers from forged responses by introducing digital signatures (RRSIG records) for resource record sets, public signing keys (DNSKEY records) to verify those signatures, and a delegation signer (DS record) placed in the parent zone registry to bridge trust between the parent and the child zone. We touched upon the security motivations behind this chain in Why HTTPS Alone Does Not Protect Your Visitors from DNS Spoofing. When a recursive resolver has DNSSEC validation enabled by default, it does not merely fetch an A or AAAA record. It also requests the corresponding RRSIG signature, validates it against the zone's Zone Signing Key (ZSK), validates the ZSK against the Key Signing Key (KSK), and finally hashes the KSK to verify that it matches the DS record published by the top-level domain (TLD) registry. If any link in that chain fails—if the DS record at the registrar points to an old key tag that no longer exists on the authoritative nameserver, if the RRSIG timestamp has expired, or if nameservers were migrated to a provider that does not possess the private keys—the recursive resolver considers the response tampered with. By design, RFC specifications require the resolver to return SERVFAIL (RCODE 2) to the end-user. It intentionally hides the data because, from the validator's perspective, an attacker might be attempting cache poisoning.

The Decisive Test: Querying with the Checking Disabled Flag

The quickest diagnostic test to isolate DNSSEC from general resolver network failure involves using the +cd flag in dig. The +cd flag stands for Checking Disabled. When sent in a DNS query header, it instructs a validating recursive resolver not to perform cryptographic validation on the answer before returning it to the client. If a normal query to a validating resolver produces SERVFAIL, but repeating the exact same query with the +cd flag produces NOERROR along with the expected IP address, you have definitive proof that DNSSEC validation failure is the sole blocker. The authoritative server is alive, the network path is clear, and the records exist, but the cryptographic chain is invalid. Here is how to run both queries side by side against a validating resolver (such as Google at 8.8.8.8 or Cloudflare at 1.1.1.1):

BASH

# Step 1: Standard query against a validating resolver
dig @8.8.8.8 example.com A +noall +comments +ans

# Step 2: Repeat the query with Checking Disabled (+cd)
dig @8.8.8.8 example.com A +cd +noall +comments +ans

In a broken DNSSEC scenario, the first command returns status: SERVFAIL in the header comments and an empty answer section. The second command returns status: NOERROR and shows the actual A record in the answer section. This diagnostic takes two seconds and immediately cuts out speculative troubleshooting around web server uptime, firewall rules, or routing issues.

Inspecting the Chain of Trust: DS and DNSKEY Records

Once +cd confirms the validation failure, the next task is finding where the chain broke. In hosting support, the breakdown almost always happens at the boundary between the parent registry (the TLD) and the child zone (the domain's authoritative nameservers). Commonly, an administrator migrates DNS hosting to a new provider. The new provider generates fresh DNSKEY records, but the domain owner forgets to delete the old DS record at the registrar. The parent zone continues publishing a DS record that references the discarded key, so every validating resolver fails the digest check. To diagnose this, query the parent zone for the domain's DS record, and query the domain's authoritative nameservers for its DNSKEY records. You can compare the key tag numbers and digest algorithms directly:

BASH

# Query the parent registry resolver for the current DS record
dig example.com DS +noall +ans

# Query the authoritative nameserver directly for the active DNSKEYs
dig @ns1.example.com example.com DNSKEY +noall +ans +multiline

In the output of the DS query, you will find four fields: the key tag (a numeric identifier, such as 2371), the algorithm number, the digest type, and the cryptographic hash digest itself. In the DNSKEY query output, look at the flags: key type 257 represents the Key Signing Key (KSK), while 256 represents the Zone Signing Key (ZSK). If the key tag reported in the DS record does not match any of the KSK records active on the authoritative nameserver, the chain of trust is severed. The parent zone is vouching for a key that does not exist on the child server. If the keys match, the next item to check is the expiration date on the RRSIG records using dig example.com A +dnssec. Expired signatures (Inception and Expiration fields in the RRSIG) cause identical SERVFAIL symptoms.

Practical Misconceptions and Safe Verification Notes

A frequent misconception among junior engineers and site owners is assuming that removing an invalid DS record at the registrar will immediately restore traffic worldwide. It does not. DS records in top-level domains typically carry long Time-to-Live (TTL) values, often between 12 and 24 hours. Validating resolvers cache the old DS record for that full duration. Even after clearing or correcting the record in the registrar portal, resolvers that have already cached the broken DS record will continue serving SERVFAIL until their local cache TTL expires. Another common trap is testing DNSSEC exclusively from a server or local machine whose upstream resolver does not enforce validation. When an engineer says, "It resolves fine on my machine," they are often querying a local router or an unconfigured forwarding resolver that ignores DNSSEC entirely. Always test against known validating resolvers (8.8.8.8, 1.1.1.1, or 9.9.9.9) to reproduce what modern external visitors see. If you want to practice identifying this pattern safely without risking production infrastructure, you do not need to configure a broken production domain. You can use intentionally broken test domains maintained by the Internet infrastructure community for validation testing, such as dnssec-failed.org. Running a standard dig against that domain on a validating resolver yields SERVFAIL, while appending +cd instantly produces NOERROR and an answer. Practicing on such test domains helps build the reflex of checking the resolver flags systematically whenever a mysterious domain outage lands on your desk. When a domain suddenly fails to resolve for a broad portion of users after an infrastructure change, do not waste time cycling web server daemons or altering firewall rules until you have evaluated DNSSEC. Running a quick comparison between a standard query and one with the +cd flag gives an unambiguous answer in seconds. If +cd brings back the answer, inspect the DS record at the registrar and ensure its key tag matches the authoritative KSK.