DNSSEC Troubleshooting: Fix SERVFAIL & DNSKEY Errors
DNSSEC Troubleshooting: How to Fix SERVFAIL, DS, DNSKEY and RRSIG Errors
A website can have correctly configured A, AAAA, and CNAME records and still be unreachable to users. One possible cause is a broken DNSSEC configuration.
When a DNSSEC-validating resolver cannot authenticate a DNS response, it may return SERVFAIL rather than the expected IP address. The authoritative name servers might be online, the zone might contain valid-looking records, and the hosting server might be healthy. Yet clients using validating resolvers cannot resolve the domain.
These failures frequently appear after changing DNS providers, migrating authoritative name servers, rotating DNSSEC keys, or allowing DNS signatures to expire.
Effective DNSSEC troubleshooting requires understanding the relationship between DS, DNSKEY, and RRSIG records, how recursive resolvers validate DNS answers, and how to identify the exact point where the chain of trust breaks.
This guide provides a practical diagnostic workflow using dig, DNSViz, Google Public DNS, and authoritative DNS queries.
If you need a foundation before investigating DNSSEC failures, read our DNS Explained and DNS Record Types Explained guides.
What Is DNSSEC?
DNS Security Extensions, or DNSSEC, add cryptographic authentication to the Domain Name System.
Traditional DNS can resolve a hostname to an IP address, but ordinary DNS responses do not inherently provide end-to-end cryptographic proof that the returned information is authentic.
DNSSEC addresses that problem by allowing DNS zones to publish signed resource-record sets.
A DNSSEC-validating recursive resolver can use public keys, signatures, and authenticated delegation information to determine whether DNS data is trustworthy.
The foundational protocol is described in RFC 4035 — Protocol Modifications for DNSSEC.
DNSSEC helps provide two essential properties:
- Data origin authentication: Evidence that DNS information comes from the expected signed zone.
- Data integrity: Protection against undetected modifications to signed DNS information.
DNSSEC does not encrypt DNS queries, hide browsing activity, or replace HTTPS.
It solves a different security problem from DNS over HTTPS (DoH) and DNS over TLS (DoT).
How the DNSSEC Chain of Trust Works
DNSSEC validation depends on a chain of trust connecting the DNS root to the authoritative zone.
Consider a signed domain such as example.com.
A simplified trust relationship looks like this:
Root trust anchor → TLD DNSSEC information → Parent DS record → Child DNSKEY → RRSIG → Signed DNS data
The resolver starts with trusted DNSSEC information and follows cryptographic relationships through the DNS hierarchy.
For a signed child zone, the parent normally publishes a DS record associated with a suitable DNSKEY in that child.
The child zone publishes its DNSKEY records and signatures over its resource-record sets.
The validating resolver checks the relevant cryptographic relationships before treating the data as authenticated.
If part of this chain is inconsistent, expired, missing, or unsupported, validation may fail.
That is why the parent zone and the authoritative DNS provider must be coordinated during DNSSEC migrations.
Essential DNSSEC Records
DNSKEY: Public keys for DNSSEC validation
The DNSKEY record publishes a public key associated with a DNSSEC-signed zone.
Resolvers use appropriate DNSKEY records to verify signatures.
A DNSKEY includes fields such as flags, protocol, algorithm, and public-key data.
DNSKEY records commonly represent keys used for zone signing or for establishing trust with the parent zone.
An operational design may distinguish between a Zone Signing Key (ZSK) and a Key Signing Key (KSK), although the exact key-management architecture can vary.
DS: The link between parent and child zones
The Delegation Signer (DS) record is normally published in the parent zone.
It provides information that connects a child’s DNSSEC key material to the parent’s authenticated delegation.
A typical DS record contains:
- Key tag
- Algorithm identifier
- Digest type
- Digest value
The parent DS information must correspond to the intended child-zone DNSKEY.
If a domain migrates to a new DNS provider with different keys while its parent retains an incompatible DS record, validating resolvers may reject the DNS responses.
RRSIG: Digital signatures over DNS data
An RRSIG record contains a DNSSEC signature covering a resource-record set.
It contains metadata including the covered record type, signing algorithm, key tag, signer name, and signature validity interval.
A validating resolver checks whether the signature is cryptographically valid and falls within the permitted time interval.
An expired RRSIG, an RRSIG that is not yet valid, or a signature that cannot be verified with the appropriate key may cause DNSSEC validation to fail.
The structures of DS, DNSKEY, and RRSIG records are defined in RFC 4034.
What Does DNSSEC SERVFAIL Mean?
SERVFAIL is a DNS response code indicating that a server could not successfully process or complete a query.
A DNSSEC validation failure is one possible reason a recursive resolver may return SERVFAIL.
However, SERVFAIL does not automatically mean DNSSEC is broken.
Other causes can include unavailable authoritative servers, incorrect delegation, transport problems, resolver errors, or other resolution failures.
A reliable diagnosis must establish whether DNSSEC validation is the actual failure point.
For example, query a public recursive resolver:
dig @1.1.1.1 example.com A +dnssec
Then compare its response with a diagnostic query using the checking-disabled flag:
dig @1.1.1.1 example.com A +dnssec +cd
The +cd option requests that the resolver disable validation checking for the query, subject to resolver behavior.
If the normal query returns SERVFAIL while the checking-disabled query returns usable DNS data, this is strong evidence of a DNSSEC validation problem.
It is not, by itself, proof of which DNSSEC record is incorrect.
Cloudflare describes this troubleshooting technique in its official DNSSEC troubleshooting documentation.
Important: The CD flag is a diagnostic tool, not a production fix. Do not permanently disable DNSSEC validation merely to hide broken configuration.
Step 1: Confirm the DNS Resolution Failure
Start with the exact hostname and record type that users cannot resolve.
For example:
dig example.com A
Inspect the DNS response code.
Relevant results include:
| Response | General meaning |
|---|---|
| NOERROR | Query processing succeeded; inspect the answer |
| NXDOMAIN | The queried DNS name does not exist |
| SERVFAIL | The server could not successfully complete the query |
| REFUSED | The server refused to process the request |
A SERVFAIL should trigger further investigation rather than an immediate DNS configuration change.
Also determine whether the problem affects all record types or only certain names.
For example:
dig example.com A
dig example.com AAAA
dig example.com MX
If failures affect multiple record types throughout the signed zone, investigate common dependencies such as zone signing, delegation, and authoritative name servers.
Step 2: Compare Validating Recursive Resolvers
Query more than one recursive resolver.
Google Public DNS:
dig @8.8.8.8 example.com A +dnssec
Cloudflare Public DNS:
dig @1.1.1.1 example.com A +dnssec
Inspect whether both return the same response code.
Different results may be caused by caching, resolver configurations, temporary network problems, or DNSSEC validation behavior.
Do not assume that one successful response proves the authoritative zone is healthy everywhere.
For operational context on cached DNS information, see DNS Caching and TTL Explained.
Step 3: Test with the Checking-Disabled Flag
Repeat a failing query using +cd.
For example:
dig @1.1.1.1 example.com A +dnssec +cd
Compare the result with:
dig @1.1.1.1 example.com A +dnssec
Consider this hypothetical result:
Normal query: SERVFAIL
Checking-disabled query: NOERROR with the expected address
This pattern suggests that DNS information may be available, but the resolver is unable to authenticate it.
Common causes include:
- A stale parent DS record
- Missing or incorrect DNSKEY data
- Expired or premature RRSIG signatures
- Inconsistent signed zone data
- Problems with the DNSSEC chain of trust
The next step is to inspect those components directly.
Step 4: Check the Parent DS Record
A stale DS record is one of the most important issues to investigate when a domain becomes unreachable after a DNS provider migration.
Query:
dig example.com DS +dnssec
You can also inspect the delegation path:
dig +trace example.com DS
The important question is whether the parent zone currently publishes DS information for the child.
If a DS record exists, determine whether it corresponds to a DNSKEY currently served by the intended authoritative DNS provider.
A mismatched DS is particularly likely when:
- DNSSEC was enabled with the previous provider.
- The domain’s authoritative name servers were changed.
- The new provider uses different DNSSEC signing keys.
- The registrar or registry still has the previous DS record.
Do not assume that changing the NS records automatically updates the DS record.
The parent delegation and DNSSEC chain of trust are separate but related configuration elements.
Google Public DNS documents this failure mode in its domain troubleshooting guide.
Should you delete the DS record?
Not automatically.
If DNSSEC is intentionally enabled, the DS record is an essential part of the chain of trust.
Deleting it changes the security status of the delegation and may be inappropriate for the intended configuration.
A correct repair may involve updating the DS record to match the appropriate DNSKEY, restoring the correct signing configuration, or carrying out a carefully planned DNSSEC migration.
Always determine the intended DNSSEC state before making changes.
Step 5: Inspect Authoritative DNSKEY Records
Next, identify the authoritative name servers responsible for the zone.
Use:
dig example.com NS
Then query an actual authoritative server directly:
dig @AUTHORITATIVE_SERVER example.com DNSKEY +dnssec +norecurse
Replace AUTHORITATIVE_SERVER with a real authoritative name server.
This reveals the DNSKEY data served by the zone.
For reliable troubleshooting, compare the responses from all intended authoritative servers.
Look for inconsistencies such as:
- One server returning a different DNSKEY RRset
- Missing expected DNSKEY records
- Outdated signing information
- Different DNSSEC configurations across providers
An important limitation: merely seeing a DNSKEY record does not prove it matches the parent DS record.
Validation depends on the correct cryptographic relationships and supported algorithms.
A DNSSEC-aware validation tool can help check those relationships rather than relying only on visual inspection.
Step 6: Investigate RRSIG Signatures
If the parent DS and child DNSKEY information appear consistent, inspect the signatures associated with the failing RRset.
Run:
dig @AUTHORITATIVE_SERVER example.com A +dnssec +norecurse
A signed DNS response may contain the requested record set and its associated RRSIG.
Review:
- Signature inception time
- Signature expiration time
- Signing algorithm
- Key tag
- Signer name
One possible failure involves an expired signature.
Another involves a signature that is not yet valid according to the resolver’s clock.
Different signatures can coexist during planned rollover operations, so the presence of one expired signature does not necessarily mean the entire RRset is invalid if another valid signature satisfies the requirements.
The applicable validation rules are documented in RFC 4035.
Check system time
DNSSEC signatures depend on time validity.
A resolver with an inaccurate clock may reject signatures that would otherwise be valid.
On Linux systems using systemd, inspect synchronization with:
timedatectl status
If the clock is inaccurate, investigate time synchronization and the environment’s NTP configuration before changing DNSSEC keys or signatures.
Step 7: Read Extended DNS Errors
A normal SERVFAIL response provides limited diagnostic information.
Some recursive resolvers support Extended DNS Errors (EDE), which can expose additional information about the reason a query failed.
For example, an EDE might indicate a missing DNSKEY or an expired signature.
Useful DNSSEC-related EDE conditions include:
| EDE code | Meaning |
|---|---|
| 6 | DNSSEC Bogus |
| 7 | Signature Expired |
| 8 | Signature Not Yet Valid |
| 9 | DNSKEY Missing |
| 10 | RRSIGs Missing |
| 12 | NSEC Missing |
These error codes are defined in RFC 8914 — Extended DNS Errors.
EDE information may appear in the additional or OPT-related diagnostic output of compatible resolvers.
For example:
dig @8.8.8.8 example.com A +dnssec
Inspect the complete response instead of displaying only the short answer.
Not every resolver returns the same diagnostics, and the absence of an EDE does not rule out DNSSEC problems.
Step 8: Use DNSViz for Chain-of-Trust Analysis
Manual DNSSEC investigation can become complicated when multiple keys, signatures, and delegations are involved.
DNSViz is a useful diagnostic service for visualizing DNSSEC dependencies and identifying validation problems.
It can help reveal issues such as:
- Broken DNSSEC trust relationships
- Incompatible parent and child information
- Missing or problematic signatures
- Delegation inconsistencies
- DNSSEC authentication failures
For advanced problems, compare DNSViz findings with authoritative DNS answers and resolver diagnostics.
Do not rely solely on a single visual indicator without understanding which part of the DNS configuration is responsible.
Step 9: Investigate DNS Provider Migrations
A common DNSSEC outage scenario occurs when a domain moves to a new DNS hosting provider.
Imagine this sequence:
- The domain is signed by Provider A.
- The parent zone contains a DS record associated with Provider A’s DNSSEC keys.
- The domain changes to Provider B.
- Provider B serves the zone using different DNSKEY records.
- The parent still publishes the previous DS information.
- DNSSEC-validating resolvers cannot establish a valid chain of trust.
The result may be widespread SERVFAIL responses.
Safe migration approaches
Two broad approaches may be appropriate depending on provider support.
Coordinated DNSSEC transition: Update or temporarily remove the relevant DS information following a documented procedure, coordinate DNSSEC state changes, and allow for caching effects before completing the migration.
Multi-signer DNSSEC: Maintain coordinated signing and trust information across the old and new providers during migration.
Multi-signer transitions are more complex and require both providers to support the necessary procedures.
Cloudflare provides an advanced DNSSEC migration tutorial covering multi-signer coordination.
Because key and delegation changes can temporarily break the entire domain, production migrations should have a tested rollback plan.
Avoid treating DS deletion or DNSSEC deactivation as a universal one-click solution.
Step 10: Check Network and Authoritative Server Availability
Not every SERVFAIL is caused by DNSSEC.
If the checking-disabled diagnostic query also fails, broaden the investigation.
Start by confirming that authoritative DNS servers are reachable and respond correctly.
Check the delegation:
dig +trace example.com
Then inspect authoritative responses directly.
DNSSEC can increase DNS response sizes because signatures and keys add additional data.
Consequently, DNS transport issues can become visible during signed DNS queries.
Compare UDP and TCP
Run:
dig @AUTHORITATIVE_SERVER example.com DNSKEY +dnssec
Then try:
dig @AUTHORITATIVE_SERVER example.com DNSKEY +dnssec +tcp
If signed responses fail over UDP or TCP, investigate network filtering, DNS message truncation, EDNS configuration, and authoritative-server connectivity.
A properly configured authoritative DNS service should support required DNS transport behavior, including TCP fallback when necessary.
Google’s DNS troubleshooting documentation provides further guidance on diagnosing these failures.
For command-line networking diagnostics, see our Linux Network Tools Guide.
DNSSEC Troubleshooting Decision Table
Use the following table to narrow down the problem.
| Symptom | Possible cause | Next investigation |
|---|---|---|
SERVFAIL on validating resolvers, but successful response with +cd |
DNSSEC validation failure | Check DS, DNSKEY, RRSIG |
| Failure shortly after DNS provider migration | Stale or incompatible DS | Compare parent DS with child keys |
| EDE indicates DNSKEY Missing | Missing or incompatible key information | Inspect authoritative DNSKEY |
| EDE indicates Signature Expired | Invalid signature validity period | Check RRSIG and signing process |
| EDE indicates Signature Not Yet Valid | Signature timing or clock issue | Verify signing time and resolver clock |
| Some authoritative servers serve different DNSKEY data | Inconsistent provider or server configuration | Compare authoritative servers |
| Signed responses fail over TCP | Transport or firewall problem | Inspect DNS TCP/53 connectivity |
Both normal and +cd queries fail |
DNSSEC may not be the primary cause | Check delegation, DNS service, transport |
This structured approach helps avoid unnecessary changes to working DNS records.
DNSSEC Troubleshooting on Linux
Linux administrators often need to distinguish between local resolver failures and problems affecting the domain globally.
Start with the configured resolver:
dig example.com A
Then compare public recursive resolvers:
dig @1.1.1.1 example.com A +dnssec
dig @8.8.8.8 example.com A +dnssec
Inspect the host’s DNS resolver configuration:
resolvectl status
For systems using systemd-resolved, view resolver statistics:
resolvectl statistics
Inspect time synchronization:
timedatectl status
For further DNSSEC validation, systems with suitable tools installed can use delv, which is designed for DNSSEC-aware DNS queries and validation.
For example:
delv example.com A
The command’s exact behavior depends on the installed implementation and its trust-anchor configuration.
When comparing results, remember that a successful dig +dnssec response does not, by itself, establish that DNSSEC cryptographic validation was performed successfully. The option requests DNSSEC information; validation is a separate process.
For Linux administration fundamentals, continue with Linux Server Administration.
Understanding the AD, CD and DO Flags
Three DNS concepts are especially useful in DNSSEC diagnostics.
AD: Authenticated Data
The AD flag may indicate that the responding recursive resolver authenticated relevant DNS data according to its validation policy.
Its presence must be interpreted in the context of the resolver and query.
CD: Checking Disabled
The CD flag requests that the resolver not enforce DNSSEC validation checking for the query.
It is useful for diagnosing suspected validation failures.
The CD flag is not evidence that the response is trustworthy.
DO: DNSSEC OK
The DO bit, carried through EDNS, indicates DNSSEC support and requests relevant DNSSEC records in responses.
The dig +dnssec option enables this behavior.
DO does not mean that the client independently validated the DNS data.
Confusing these flags can lead to misleading conclusions during troubleshooting.
Preventing DNSSEC Outages
DNSSEC should be managed through documented operational procedures.
A reliable process includes monitoring signature expiration, coordinating changes between registrars and authoritative DNS providers, and maintaining appropriate key rollover procedures.
Before changing authoritative name servers, determine whether the domain is currently signed and whether the parent publishes DS records.
During a DNSSEC key rollover, ensure the necessary records and signatures remain available for the applicable caching and validation periods.
Monitor authoritative DNS health as well as recursive validation results.
For high-value production domains, periodically test validation through more than one independent resolver.
These operational principles are discussed in RFC 6781 — DNSSEC Operational Practices.
DNSSEC configuration should also be protected by the broader identity, access-control, and change-management practices described in Network Security Basics.
Frequently Asked Questions
What causes DNSSEC SERVFAIL?
A DNSSEC-related SERVFAIL can occur when a validating resolver cannot authenticate DNS data. Causes include broken DS-to-DNSKEY relationships, invalid signatures, missing keys, and other DNSSEC configuration problems. SERVFAIL can also have non-DNSSEC causes.
How do I check whether DNSSEC is broken?
Compare a normal query using a validating resolver with a diagnostic query using +cd. If the normal query fails and the checking-disabled query succeeds, investigate the DNSSEC chain of trust.
What is a DS record mismatch?
A DS mismatch occurs when the parent-zone DS information does not correspond to the intended child-zone DNSSEC key material. It can cause DNSSEC validation failures.
What is the difference between DS and DNSKEY?
DNSKEY publishes DNSSEC public keys in a zone. DS is normally published in the parent zone and establishes an authenticated relationship with relevant child-zone key material.
Can an expired RRSIG break DNS resolution?
Yes. If no acceptable, valid signature is available for data that requires authentication, a validating resolver may reject the answer.
Does dig +dnssec validate DNSSEC automatically?
No. It requests DNSSEC-related data. Use a validating resolver or suitable validation software to establish whether the chain of trust is valid.
Should I disable DNSSEC to fix SERVFAIL?
Not as a default response. First identify whether DNSSEC is responsible and determine the specific configuration error. Repair the key, signature, or delegation problem using a documented process.
Does DNSSEC encrypt DNS traffic?
No. DNSSEC provides authentication and integrity for signed DNS information. DNS over HTTPS and DNS over TLS address transport confidentiality.
Conclusion
DNSSEC failures can make otherwise healthy websites and applications unreachable.
The most effective troubleshooting process starts by separating ordinary DNS resolution failures from cryptographic validation failures.
Query multiple recursive resolvers, compare normal and checking-disabled responses, inspect the parent DS record, and verify that authoritative DNSKEY and RRSIG information is consistent.
When possible, use Extended DNS Error diagnostics and tools such as DNSViz to identify the failing component.
Be particularly careful during DNS provider migrations and key rollovers. A stale DS record, missing DNSKEY, or invalid signature can break the DNSSEC chain of trust even when all ordinary A and AAAA records appear correct.
Above all, diagnose before changing DNSSEC settings. The objective is to restore a valid and reliable trust chain, not simply to suppress validation failures.
Continue learning with DNS Record Types Explained, DNS Caching and TTL Explained, and Linux Network Tools Guide for the DNS and networking skills required to investigate complex infrastructure problems.