The DNSSEC chain of trust

A signature proves an answer matches a key. It does not prove the key is yours. The chain of trust is how a resolver decides it is.

Each level vouches for the one below

1. Your zone is signed with your keys, and each record set carries an RRSIG.
2. Your public key is published in your zone as a DNSKEY.
3. A hash of that key is published in the parent zone — .com, .sg, whichever — as a DS record.
4. The parent zone is itself signed, and its key is vouched for by the level above it.
5. The root zone's key is known to the resolver in advance. That is the trust anchor, and it is where the chain stops.

A resolver trusts your records because the root vouches for .com, which vouches for you. The cryptography is the easy part; the links are what matter.

The DS record is the join, and it is not in your zone

This is the single most important thing to understand about operating a signed domain.

Everything else — DNSKEY, RRSIG, NSEC3 — lives in your zone and is managed by your DNS provider. The DS record lives at the registry, and it is published through your registrar.

Two different companies hold the two halves. Your DNS provider holds the key; your registrar publishes the fingerprint of it. Nothing automatically keeps them in step.

That is why every serious DNSSEC failure is a DS problem: the DS at the registry no longer matches the key in the zone, so a validating resolver concludes the answer is forged.

Fails closed, not open

Unsigned DNS fails open — a bad answer is still an answer. DNSSEC fails closed: a resolver that cannot verify a signature returns SERVFAIL and gives the user nothing at all.

That is the point of it. It is also the risk. A mismatch does not make a domain slow or partly broken. It removes it, for every user of every validating resolver — which today is most of them.

It is also why the failure is so disorienting: your own resolver may not validate, so the domain works perfectly for you while it has vanished for everyone else.

What this means in practice

• Turning DNSSEC on: sign the zone first, let it publish, then give the DS to your registrar. Doing it the other way round breaks the domain until signing catches up.
• Turning it off: remove the DS first, wait for its TTL, then unsign. See turning DNSSEC off.
• Moving providers: the new provider has a different key, so the old DS is wrong the moment you switch. See moving a signed domain.

Every one of those is the same rule stated three ways: the DS record and the zone's keys must agree at every moment.

Last reviewed 2026-09-16.