How do I know if SERVFAIL is caused by DNSSEC?

Query the authoritative nameserver directly, then query a validating resolver with and without DNSSEC checking. If the authoritative server returns the record, the validating resolver returns SERVFAIL, and `dig +cd` returns an answer through that resolver, DNSSEC validation is the likely failure point.

What is the fastest emergency recovery for a broken DNSSEC chain?

If you cannot restore valid signing quickly, remove the DS record at the registrar or parent zone first. That breaks the chain of trust in the safe direction. Do not disable signing while a DS record still exists at the parent.

Can a DNSSEC outage affect only some users?

Yes. Users behind validating resolvers will see failures, while users behind non-validating resolvers may still resolve the domain. Resolver cache timing also means some networks recover earlier than others after the fix.

Does a missing AD flag mean DNSSEC is broken?

Not by itself. The AD flag appears only when the resolver validates and authenticates the answer. Some resolvers do not validate, and some tools do not request DNSSEC data. Treat SERVFAIL, DNSViz errors, or failed validation as stronger signals.

OperationsIntermediate

DNSSEC Failure Troubleshooting

Diagnose DNSSEC SERVFAIL outages caused by DS mismatches, expired signatures, unsigned answers, missing DNSKEY records, and unsafe DNSSEC disable steps.

Updated 29 June 2026

Start free Browse guides

Answer snapshot

DNSSEC failures usually look like SERVFAIL from validating resolvers while the authoritative nameserver can still answer. Compare authoritative and recursive results, retry with checking disabled, inspect the parent DS and child DNSKEY records, and look for expired or missing RRSIG records. If the zone must recover quickly and signing cannot be fixed immediately, remove the DS at the registrar first, wait for parent propagation, then repair or disable signing.

What you'll learn

Confirm whether a SERVFAIL outage is caused by DNSSEC validation
Compare parent DS records with child-zone DNSKEY and DS data
Identify expired signatures, missing signatures, and broken denial-of-existence proofs
Recover safely without making the outage worse

DNSSEC outages are high-impact because the zone can look healthy from the authoritative nameserver while validating resolvers refuse to return answers. The most common visible symptom is SERVFAIL, not NXDOMAIN or an empty answer.

Use this playbook when a signed zone returns SERVFAIL, certificate issuance suddenly cannot check CAA records, or a registrar-side DS change happened near the outage window. For setup and normal enablement, start with DNSSEC Setup Guide for DNScale. For the record mechanics behind the checks below, read How DNSSEC Works.

Confirm DNSSEC Is the Failure Layer

Start by separating four views:

What the authoritative nameserver serves.
What a validating public resolver returns.
What the same resolver returns with DNSSEC checking disabled.
What the parent zone publishes for DS records.

# Authoritative answer from DNScale
dig @ns1.dnscale.eu example.com A +short
 
# Validating resolver result
dig @1.1.1.1 example.com A +dnssec
 
# Same resolver, but disable validation checking for this query
dig @1.1.1.1 example.com A +cd
 
# Trace delegation and DNSSEC path
dig +trace +dnssec example.com A

Interpret the first pass:

Result	Likely meaning
Authoritative answer fails	Fix the zone, delegation, or authoritative service before DNSSEC
Authoritative works, validating resolver SERVFAILs	DNSSEC validation is likely failing
`+cd` returns an answer while normal query SERVFAILs	Strong DNSSEC failure signal
Public resolvers disagree	Cache state or resolver-specific validation timing may be involved

If all authoritative and recursive answers fail the same way, do not assume DNSSEC first. Check delegation, zone existence, record presence, and service health.

Inspect Parent DS Records

The DS record at the parent zone is the chain-of-trust link into your zone. A stale or mistyped DS is the most common human-caused DNSSEC outage.

For .com, query the gTLD server directly:

dig @a.gtld-servers.net. example.com DS +short

For another TLD, use +trace to find the parent nameserver:

dig +trace example.com DS

Compare the parent DS set with the DS record currently shown in DNScale. The key tag, algorithm, digest type, and digest must match an active key for the zone.

Common DS failures:

Failure	Symptom	Fix
Old DS remains after a key rollover	Validators SERVFAIL even though zone is signed	Remove stale DS or publish the matching key again
Registrar copied the wrong digest	DNSViz shows a broken DS to DNSKEY link	Replace the registrar DS with the DNScale DS
Multiple DS records include old keys	Some validators fail depending on cache timing	Keep only DS records that match active keys
DS exists after signing was disabled	Validating resolvers fail the whole zone	Remove DS at the registrar or re-enable signing

Inspect Child DNSKEY Records

The child zone must publish DNSKEY records that match the parent DS.

dig @ns1.dnscale.eu example.com DNSKEY +dnssec

Look for:

DNSKEY records in the answer.
RRSIG records covering the DNSKEY RRset.
Algorithm numbers that match the parent DS.
A key tag that corresponds to the parent DS.

If the parent DS exists but the child DNSKEY response is missing or unsigned, validators cannot complete the chain.

Check RRSIG Validity

Every signed RRset has an RRSIG with inception and expiration timestamps. If signatures expire, validating resolvers reject otherwise-correct answers.

dig @ns1.dnscale.eu example.com A +dnssec
dig @ns1.dnscale.eu example.com SOA +dnssec

Find the RRSIG lines and inspect the timestamp fields. Expired signatures usually mean the signing pipeline stopped, keys were unpublished, or a secondary nameserver is serving stale signed data.

For DNScale-managed signing, verify that DNSSEC is enabled for the zone and that the zone is not in a failed key state. For self-hosted or secondary-provider setups, check the signer logs and ensure all authoritative nameservers serve the same signed zone version.

Check Denial of Existence

DNSSEC also signs negative answers. A broken NSEC or NSEC3 proof can make nonexistent names return SERVFAIL instead of NXDOMAIN.

dig @1.1.1.1 does-not-exist.example.com A +dnssec
dig @ns1.dnscale.eu does-not-exist.example.com A +dnssec

Healthy negative answers should include signed denial data, usually NSEC or NSEC3 plus RRSIG records. If only nonexistent names fail, investigate denial-of-existence signing rather than the normal A, AAAA, MX, or TXT records.

Use DNSViz for a Second Opinion

Command-line checks are fastest during an incident, but a visual chain view helps avoid missing one broken link.

DNSViz highlights parent DS, child DNSKEY, RRSIG, and NSEC/NSEC3 failures.
Verisign DNSSEC Debugger gives a compact chain-of-trust view.

Use these tools after the first triage pass, especially when a registrar or parent zone update is involved.

Safe Recovery Paths

Choose the recovery path based on what is broken.

Situation	Safer recovery
Parent DS is wrong	Replace the DS at the registrar with the current DNScale DS
Parent DS is stale and no matching key exists	Remove the stale DS at the registrar
Signatures expired	Restore signing or re-sign the zone; verify fresh RRSIG timestamps
DNSKEY is missing while DS exists	Re-enable signing with the matching key, or remove DS
Need to disable DNSSEC permanently	Remove DS first, wait for parent TTLs, then disable signing

The dangerous order is disabling signing first while a DS record remains at the parent. That leaves validators with proof that the zone should be signed but no valid signed data to authenticate.

DNScale Incident Checklist

During an incident, record exact outputs and timestamps:

Query the authoritative answer from ns1.dnscale.eu.
Query validating resolvers: 1.1.1.1, 8.8.8.8, and 9.9.9.9.
Retry one failed query with +cd.
Compare DNScale's current DS record with the registrar or parent DS.
Query DNSKEY and RRSIG data from the authoritative nameserver.
Check DNSViz for the chain break.
Apply the smallest fix: correct DS, restore signing, or remove DS.
Re-test authoritative, recursive, and +trace results.

For planned changes, make DNSSEC verification part of the DNS Operations workflow before and after the change window.

Frequently asked questions

How do I know if SERVFAIL is caused by DNSSEC?: Query the authoritative nameserver directly, then query a validating resolver with and without DNSSEC checking. If the authoritative server returns the record, the validating resolver returns SERVFAIL, and `dig +cd` returns an answer through that resolver, DNSSEC validation is the likely failure point.
What is the fastest emergency recovery for a broken DNSSEC chain?: If you cannot restore valid signing quickly, remove the DS record at the registrar or parent zone first. That breaks the chain of trust in the safe direction. Do not disable signing while a DS record still exists at the parent.
Can a DNSSEC outage affect only some users?: Yes. Users behind validating resolvers will see failures, while users behind non-validating resolvers may still resolve the domain. Resolver cache timing also means some networks recover earlier than others after the fix.
Does a missing AD flag mean DNSSEC is broken?: Not by itself. The AD flag appears only when the resolver validates and authenticates the answer. Some resolvers do not validate, and some tools do not request DNSSEC data. Treat SERVFAIL, DNSViz errors, or failed validation as stronger signals.

Related guides

Ready to manage your DNS with confidence?

DNScale provides anycast DNS hosting with a global network, real-time analytics, and an easy-to-use API.

Start free