DNSSEC Explained: Chain of Trust, DS Records and Common Validation Failures

DNSSEC answers a plain question: can I trust this DNS answer? Plain DNS has no authentication — a forged response from a compromised resolver or an on-path attacker is indistinguishable from a real one. DNSSEC signs records so a validating resolver can verify they were published by the zone owner and were not modified in transit.

The chain of trust

Trust starts at the DNS root and is delegated downward, link by link:

1. The root zone is signed with a key that everyone’s resolver ships with (the trust anchor).
2. The root signs the .com zone’s key, publishing a DS (Delegation Signer) record for it.
3. .com signs your domain’s key and publishes your DS record at the delegation point — this is the record your registrar stores.
4. Your zone signs every record set with an RRSIG, and publishes its public keys as DNSKEY records.

A validating resolver walks this chain from the root to your name. Break any link — most often a stale DS record — and the entire domain returns SERVFAIL for validating resolvers. Not a downgrade: a total outage. That asymmetry is why DNSSEC mistakes are so visible.

DS, DNSKEY, RRSIG, NSEC

• DNSKEY: the public keys in the zone. The KSK (key signing key) signs the zone’s key set; the ZSK signs ordinary records. Many providers merge them into one key (algorithm 13, ECDSA).
• DS: a hash of the KSK, published by the parent. The registrar is the only place this lives, which makes it the classic failure point.
• RRSIG: the signature over a record set, with validity windows. If a zone is re-signed lazily or a server’s clock drifts, signatures expire and validation fails.
• NSEC/NSEC3: signed proof that a name does not exist. Also a (mitigated) enumeration side channel — NSEC3 hashes names to make walking the zone expensive.

Why validation breaks — and how to check

The recurring failure scenarios:

• After a zone transfer or DNS provider switch: the new provider signs with a fresh key, but the DS at the registrar still hashes the old KSK. Resolvers fail validation until the DS is updated. Never enable signing at the new host and delete it at the old one in the wrong order.
• After disabling DNSSEC at the host but not at the registrar: the parent keeps demanding signatures nobody produces. Remove the DS first, wait for its TTL to expire, then stop signing.
• During key rollover: the double-signature windows (typically several TTLs long) must complete before the old DS is removed. Compressing the schedule is how domains go dark.
• Signature expiry on secondary servers: a hidden primary that stopped re-signing leaves secondaries serving stale RRSIGs.

Verification from the shell:

dig +dnssec +multi example.com DNSKEY
dig +short example.com DS @a.gtld-servers.net
delv @8.8.8.8 example.com

delv is the fastest way to see exactly which link fails, because it prints the validation path. For a quick external check — is the zone signed, does the DS at the parent match the DNSKEY set, are signatures in their validity window — run the domain through the DNSSEC checker, which reports each of those conditions separately instead of a bare SERVFAIL.