DNSSEC chain of trust: understand it in 5 minutes (2026)

Q: How do I verify that DNSSEC is working on my domain?

Run dig captaindns.com +dnssec | grep flags . If the ad flag (Authenticated Data) is present, the chain of trust is validated. You can also use an online tool that checks the DS record, DNSKEYs, and RRSIG signatures.

TL;DR

The DNSSEC chain of trust links the DNS root to your domain through nested cryptographic signatures
Three record types handle validation: DNSKEY (public keys), RRSIG (signatures), and DS (link to the parent zone)
Each link verifies the next: the root signs the TLD, and the TLD signs your domain
Since October 11, 2026, KSK 38696 has been signing the DNS root: a self-managed resolver that does not have it among its trust anchors may return SERVFAIL
Check that your chain is intact with our DNSSEC Checker (see action plan at the end)

You rotate a DNSSEC key, forget to update the DS record at your registrar, and every visitor gets a SERVFAIL error. Your site is unreachable, not because it's down, but because one cryptographic link broke.

DNSSEC doesn't work like a TLS certificate you install on a server. It's a distributed system. Trust propagates from the DNS root down to your domain, link by link. If a single link breaks, the entire chain collapses.

Why does this happen, and how can you prevent it? This guide covers every component of the DNSSEC chain of trust explained from the ground up, with diagrams and real-world examples.

Why does DNS need a chain of trust?

What stops an attacker from forging a DNS response and redirecting your visitors to a malicious server? In 1983, the answer was: nothing. DNS (RFC 1034) was designed as a directory, not a security protocol. Any server on the path could inject a forged response (DNS spoofing).

DNSSEC (RFC 4033) solves this by adding cryptographic signatures. But a signature alone isn't enough. You also need a way to verify that the signing key is legitimate. That's the role of the chain of trust.

The principle is simple: each level of the DNS hierarchy vouches for the authenticity of the next.

The three levels of the DNS hierarchy

DNS resolution follows a tree structure with three levels. DNSSEC leverages this hierarchy to build the chain of trust.

Level 1: the DNS root

The DNS root is the starting point of every resolution. It's managed by IANA (Internet Assigned Numbers Authority) and distributed across 13 root server clusters. The root signs the DS records for each TLD.

The root's trust anchor is based on its KSK. The validating resolver keeps it in its configuration and must update it when keys change. It is the starting point of the chain, not a key built in once and for all.

Level 2: the TLD (.com, .fr, .org)

The TLD gets its legitimacy from the root via a DS record. The TLD registry (Verisign for .com, AFNIC for .fr) manages the signing of its zone. The TLD in turn signs the DS records for each registered domain.

Level 3: your domain (captaindns.com)

Your domain is the last link. Your DNS provider signs the records in your zone (A, MX, TXT, etc.) and publishes the public keys. The DS record published at the TLD connects your zone to the parent zone.

DNSSEC chain of trust: from the DNS root to the domain, each level signs the next

Cryptographic keys: ZSK and KSK

Each DNSSEC zone uses two key pairs. Separating them allows independent rotation and limits the impact of a compromise.

ZSK (Zone Signing Key)

The ZSK signs the DNS records in your zone. Each record type (A, MX, TXT, AAAA) gets its own RRSIG signature.

Typical size: 1024-2048 bits (RSA) or 256 bits (ECDSA P-256)
Rotation: every 1 to 3 months
Published in: the DNSKEY record in your zone (flag 256)

Frequent ZSK rotation limits risk. If the key is compromised, the exposure window is short. Rotating the ZSK does not require updating the DS record at the TLD.

KSK (Key Signing Key)

Your domain's KSK only signs the DNSKEY set (including the ZSK). Its hash is published in the DS record at the TLD level. It's the bridge between your zone and the parent zone.

Typical size: 2048-4096 bits (RSA) or 384 bits (ECDSA P-384)
Rotation: every 1 to 2 years
Published in: the DNSKEY record in your zone (flag 257)

Rotating your domain's KSK is trickier. It requires updating the DS record at the registrar. Poor coordination breaks the chain of trust.

DNSSEC records explained: DNSKEY, DS, RRSIG

Four types of DNS records power the chain.

DNSKEY: the public keys

The DNSKEY record contains the public key used to verify signatures. Your zone publishes at least two DNSKEYs: one for the ZSK (flag 256) and one for the KSK (flag 257).

dig DNSKEY captaindns.com +short

The resolver uses these keys to verify the RRSIG signatures on your zone's records.

RRSIG: the signatures

Every signed DNS record has a corresponding RRSIG. The RRSIG contains four elements: the cryptographic signature, the algorithm, the validity period, and the Key Tag of the signing key.

dig A captaindns.com +dnssec

The resolver checks two things: the RRSIG must match the returned record, and the signing key (DNSKEY) must be valid.

DS: the link to the parent zone

The DS record (Delegation Signer) is published in the parent zone (the TLD). It contains a hash of your zone's KSK. The resolver compares this hash with the KSK in your DNSKEY record. If they match, your keys are legitimate.

dig DS captaindns.com +short

The DS record is the critical link between two levels of the hierarchy. Without a DS record, the chain is broken. DNSSEC validation shows the zone as INSECURE.

NSEC/NSEC3: proof of non-existence

NSEC and NSEC3 prove that a requested record does not exist. This proof is authenticated. Without these records, an attacker could forge "domain not found" (NXDOMAIN) responses.

NSEC3 (RFC 5155) adds name hashing to prevent zone enumeration (zone walking).

How does DNSSEC validation work?

Here is the full DNSSEC validation process when a resolver receives a query for captaindns.com.

Step 1: retrieve the DNSSEC trust anchor

The resolver starts with a locally configured root trust anchor. This initial trust does not come from a parent zone; the anchor must then be kept up to date, notably through RFC 5011 when that mechanism is supported and working.

October 12, 2026 update: the root KSK rollover took place on October 11. The root rollover section below explains what it changes for a self-managed resolver.

Step 2: validate from the root to the TLD

The resolver requests the DS record for .com from the root
The root returns the DS record and its RRSIG signature
The resolver validates the root DNSKEY set with the root KSK, then the DS signature with the ZSK authenticated this way
The DS record for .com is now validated

Step 3: validate from the TLD to your domain

The resolver requests the DS record for captaindns.com from the .com TLD
The TLD returns the DS record and its RRSIG signature
The resolver verifies the signature with the TLD's DNSKEY (validated in step 2)
The DS record for captaindns.com is now validated

Step 4: validate your zone

The resolver requests the DNSKEY for captaindns.com
It compares the KSK hash with the DS record validated in step 3
If the hash matches, the DNSKEYs are legitimate
The resolver requests the A record and verifies its RRSIG with the ZSK

If all steps succeed, the response is marked SECURE (flag ad in the DNS response). If any step fails, the response is BOGUS. The resolver returns SERVFAIL to the client.

Step-by-step DNSSEC validation process: from the root to the final record

Root KSK rollover: status as of October 12, 2026

Since October 11, 2026, KSK-2024 (key tag 38696) has been signing the root zone's DNSKEY set in place of KSK-2017 (20326): it is the only KSK signing it. Observed on October 12, 2026: on k.root-servers.net and a.root-servers.net, the root DNSKEY set is signed by 38696, and IANA lists KSK-2024 with the status Active, "Signing since 2026-10-11". This rollover does not change the algorithm. The TLDs' DS records remain signed by the ZSK.

Published on January 11, 2025, the new key was expected to be recognized as a trust anchor through RFC 5011 as early as February 10, 2025. This timeline does not prove that the update succeeded on your resolver.

The old key 20326 is still published in the root zone. As of October 12, 2026, IANA lists it with the status Post-Publication and states that it remains a valid trust anchor: do not remove it from your resolver yourself. For its removal, consult the current IANA timeline.

The ICANN guidance is to verify that 38696 is a locally usable trust anchor, rather than assume it. Seeing this key in a DNS response is not enough.

A self-managed resolver that does not have 38696 among its trust anchors can no longer validate the root DNSKEY set. SERVFAIL responses appear on healthy domains as the cached root DNSKEY set expires (2-day TTL). If a query returns SERVFAIL on this resolver but gets a normal answer with dig +cd (validation disabled for this one test), then validation is failing: check the 38696 anchor before touching the zone or the registrar. With 1.1.1.1, 8.8.8.8, or 9.9.9.9, there is nothing for you to do on their anchors.

When does the chain break?

A break can originate in the zone or in the resolver validating it. Here are four scenarios.

Missing or incorrect DS record

The DS record at the TLD doesn't match the KSK published in your zone. Causes:

The DS record was never added at the registrar (the zone is signed but the chain is not established)
The KSK was rotated without updating the DS record
An error in the DS record values (Key Tag, Algorithm, Digest)

Result: INSECURE if no DS record exists. BOGUS if the DS record exists but doesn't match.

Expired RRSIG signatures

Every RRSIG signature has a validity period. If signatures are not renewed before expiration, the resolver rejects them.

Result: BOGUS on all records whose signature has expired.

Prevention: managed DNS providers (Cloudflare, Route 53, OVHcloud) automatically renew signatures. The risk mainly exists with self-managed BIND or PowerDNS setups.

Incompatible algorithms

If the DS record specifies a different algorithm than the one used by the DNSKEY, validation fails.

Result: BOGUS.

Outdated root anchor on the resolver

Since the October 11, 2026 rollover, a self-managed resolver that does not trust 38696 may return SERVFAIL for many otherwise healthy domains. The fault lies in its root anchor, not in your domain's DS. Check this anchor before making changes to the zone or at the registrar.

Verify your chain of trust

To confirm that your chain is intact, run the following command:

dig captaindns.com +dnssec +short

The ad flag (Authenticated Data) in the response confirms that the full chain is validated:

dig captaindns.com +dnssec | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2

For a complete analysis of each link, use our DNS Lookup tool, which details the DNSKEY, DS, and RRSIG records. You can also run the DNSSEC Checker to verify every link in the chain from the root to your domain in one step.

Recommended action plan

Understand your setup: identify who manages zone signing (DNS provider) and who manages the DS record (registrar)
Verify the chain: confirm that the DS record at the TLD matches your KSK with dig DS captaindns.com +short
Monitor expirations: track RRSIG signature validity and plan key rotations
Document the procedure: record the KSK rotation steps for your specific registrar
Test after every change: verify DNS propagation after any DNSSEC modification
Self-managed resolver: verify that 38696 is indeed a trust anchor of your resolver; if a query returns SERVFAIL on this resolver but a normal answer with dig +cd, validation is failing; if you only use 1.1.1.1, 8.8.8.8, or 9.9.9.9, you do not need to take any action on their anchors

Run a full DNSSEC diagnosis on your domain to check its DS, DNSKEY, and RRSIG records. The DNSSEC Checker does not test your resolver's local anchor.

FAQ

What is the DNSSEC chain of trust?

The DNSSEC chain of trust is the mechanism by which each level of the DNS hierarchy (root, TLD, domain) vouches for the authenticity of the next level through cryptographic signatures. The resolver walks this chain from the trust anchor (root KSK) down to your domain.

What is a trust anchor?

A trust anchor is a key or a key reference that the resolver considers trustworthy to start validation. For the DNS root, it is based on the root KSK and must be kept up to date, especially during a rollover. RFC 5011 provides for this automatic update, whose operation must be verified.

Is my self-managed resolver affected by the root KSK rollover?

Yes, if it validates DNSSEC. Since October 11, 2026, KSK 38696 has been signing the root DNSKEY set: a self-managed resolver that does not have it among its trust anchors may return SERVFAIL for healthy domains. Verify that 38696 is recognized as a trust anchor, without assuming that RFC 5011 succeeded. With 1.1.1.1, 8.8.8.8, or 9.9.9.9, you do not need to take any action on their anchors.

What is the difference between ZSK and KSK?

The ZSK (Zone Signing Key) signs the DNS records in your zone (A, MX, TXT). The KSK (Key Signing Key) only signs the DNSKEYs. Separating them allows you to rotate the ZSK frequently without touching the DS record at the registrar.

What happens if the chain of trust is broken?

If any link in the chain is invalid (incorrect DS, expired signature, incompatible key), the resolver marks the response as BOGUS and returns SERVFAIL to the client. Your visitors cannot reach your site until the issue is fixed.

How does DNSSEC work?

DNSSEC adds cryptographic signatures to every DNS record. Your DNS provider signs the records with a private key (ZSK). The resolver verifies the signatures with the public key (DNSKEY). The legitimacy of the keys is guaranteed by a DS record published at the TLD, forming a chain of trust all the way to the root.

How do I verify that DNSSEC is working on my domain?

Run dig captaindns.com +dnssec | grep flags. If the ad flag (Authenticated Data) is present, the chain of trust is validated. You can also use an online tool that checks the DS record, DNSKEYs, and RRSIG signatures.

Why is KSK rotation risky?

Rotating your domain's KSK requires updating the DS record at the registrar. During the transition, both DS records (old and new) must coexist. Poor coordination (removing the old DS before the new one has propagated) breaks the chain and causes SERVFAIL errors.

Does DNSSEC work with all resolvers?

No. Only validating resolvers check DNSSEC signatures. The major public resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) validate DNSSEC. Some ISP resolvers do not. According to APNIC, about 38% of global DNS queries are DNSSEC-validated as of 2026.

Glossary

Trust anchor: a key or key reference recognized as trustworthy to start DNSSEC validation; the root anchor must be kept up to date when KSKs change.
DS record (Delegation Signer): a record published in the parent zone containing a hash of the KSK. It's the link between two levels of the hierarchy.
DNSKEY: a record containing the public signing key. Flag 256 for the ZSK, flag 257 for the KSK.
RRSIG: a cryptographic signature of a DNS record. Contains the algorithm, validity period, and Key Tag.
NSEC/NSEC3: authenticated proof-of-non-existence records. NSEC3 adds name hashing to prevent zone enumeration.
BOGUS: the state of a DNS response that failed DNSSEC validation. The resolver returns SERVFAIL.