Understand the DNSSEC chain of trust in 5 minutes

By CaptainDNS
Published on February 22, 2026

DNSSEC chain of trust: from the DNS root to your domain, each level verifies the next using cryptographic keys

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
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 the root KSK. It's built into every validating resolver (1.1.1.1, 8.8.8.8, 9.9.9.9). This is the foundation of the entire chain.

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)

The 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)

KSK rotation 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 already has the DNS root's KSK (DNSSEC trust anchor). This key is built into its configuration. It's the only element the resolver accepts without verification.

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 verifies the signature with the root KSK
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

When does the chain break?

Three scenarios cause a chain-of-trust failure.

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.

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

Run a full DNSSEC diagnosis on your domain to verify that every link in the chain is in place.

Enable DNSSEC: step-by-step guide by registrar
DANE/TLSA: the complete guide to DNS-based certificate authentication
SERVFAIL after enabling DNSSEC: diagnosis and fix (coming soon)

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 public key that the resolver considers trustworthy without further verification. In DNSSEC, the trust anchor is the DNS root's KSK. It's built into the configuration of every validating resolver.

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?

KSK rotation 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 public key that the resolver considers trustworthy without verification. In DNSSEC, this is the DNS root's KSK.
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.