DNSSEC & the chain of trust

A resolver that sends a question over UDP gets back a packet that could have come from anyone able to guess a few numbers in time. Chapter 13 covers how cache poisoning exploits that. The fix that removes the guessing game entirely is to make answers checkable: the zone's owner signs each set of records with a private key, publishes the matching public key, and any resolver can verify the signature. A forger can copy a signature, but cannot make a new one for different data.

RFC 4033, the overview of DNSSEC, lists exactly three things it provides. Data origin authentication: the records were published by whoever holds the zone's key. Data integrity: they were not altered after signing. Authenticated denial of existence: when the answer is "no such name" or "no such record type", that answer is signed too, so it cannot be forged either. RFC 9364, the current best-practice summary, points back to the same three.

Everything else is out of scope, and most DNSSEC confusion comes from expecting one of the missing items. The table is worth reading row by row.

DNSSEC adds no new servers and no new protocol messages. It adds record types, defined in RFC 4034, that travel in ordinary DNS answers.

• DNSKEY holds a public key. It sits at the zone's apex, so the keys for example.test are the DNSKEY records at example.test. Each key has a key tag, a 16-bit checksum of the record used as a short nickname so a resolver can pick the right key quickly.
• RRSIG is a signature over one RRset: all the records with the same name, class and type, signed together as a unit. It names the key that made it (by key tag and signer name), the algorithm, and a validity window, an inception and an expiration time. Outside that window the signature is worthless, which is what stops an attacker from replaying last year's answer forever.
• DS (Delegation Signer) lives in the parent zone, next to the NS records of the delegation. It holds a hash of one of the child's DNSKEYs. This is the link in the chain: the parent signs the DS, and the DS pins the child's key.
• NSEC and NSEC3 prove that something does not exist. They come later in this chapter.

Most zones use two keys with different jobs. The key-signing key (KSK) signs only the DNSKEY RRset; its hash is what goes up to the parent as the DS. The zone-signing key (ZSK) signs everything else. The split exists for convenience, not cryptography: you can change the ZSK as often as you like without talking to the parent, because the parent only knows about the KSK. A KSK has flag value 257 (the "secure entry point" bit set); a ZSK has 256. Some operators use one key for both jobs, a combined signing key, and that is perfectly valid.

Here is what a signed answer looks like. The data is simulated, on the reserved name example.test, but the format is exactly what dig +dnssec prints.

A signature is only as good as your confidence in the public key that checks it. If a resolver fetched example.test's DNSKEY over the same unprotected channel as everything else, a forger could just send their own key with their own signatures. DNSSEC solves this by asking the parent. Validating www.example.test goes like this:

1. The resolver starts from a key it already trusts: the trust anchor, a copy of the root's KSK (or its hash) built into the resolver's configuration.
2. It fetches the root's DNSKEY RRset, finds the key that matches the anchor, and checks the RRSIG that key made over the whole set. Now the root's ZSK is trusted too.
3. It fetches the DS record for test. from the root, checks the root ZSK's signature on it, and so learns a hash of test.'s KSK.
4. It fetches test.'s DNSKEY RRset, hashes the KSK, compares it with the DS, and checks the KSK's signature over the set.
5. Same again one level down: the DS for example.test, then example.test's DNSKEY RRset.
6. Finally it checks the RRSIG on the A record with example.test's ZSK.

Every link is either a hash comparison (DS against DNSKEY) or a signature check (RRSIG against DNSKEY). Break any one and the chain stops there. That is the whole design.

The root zone was signed in July 2010, and its key has been replaced twice since. The first root KSK rollover, from the 2010 key to KSK-2017 (key tag 20326), happened on 11 October 2018, after a one-year delay while ICANN studied how many resolvers still had only the old anchor. The second, to KSK-2024 (key tag 38696), happened on 11 October 2026, eleven days before this chapter was written. A resolver that never learns the new anchor stops validating anything at all, so rollovers at the root are planned years ahead.

Most resolvers learn new anchors automatically with RFC 5011. When the root publishes a new KSK in its DNSKEY set, signed by the old one, a resolver following RFC 5011 notices it, waits out an "add hold-down" of at least 30 days while it keeps seeing the new key, and only then trusts it. The waiting is the safety: someone who briefly stole the old key could not slip in a new anchor without the change being visible for a month.

RFC 4033 gives every answer a validating resolver handles one of four states, and the difference between them is the most practical thing in this chapter.

"Insecure" sounds alarming but is ordinary: it means "provably unsigned", and the resolver treats the answer like plain DNS. "Bogus" is the alarm. A validating resolver refuses to hand out bogus data, because it cannot tell an attack from a mistake, and handing out data that might be forged would defeat the point. So a DNSSEC mistake looks, to a user, exactly like an outage: the site "doesn't exist", while friends on a non-validating network load it fine.

Two tools make this less mysterious. Extended DNS Errors (RFC 8914) let a resolver attach a reason code to the SERVFAIL: 6 is "DNSSEC Bogus", 7 "Signature Expired", 8 "Signature Not Yet Valid", 9 "DNSKEY Missing" (a DS exists, but no matching key), 10 "RRSIGs Missing". And the CD bit lets you ask the same resolver to skip validation. If +cd makes the answer appear, the problem is the signatures, not the servers.

Signing records that exist is easy. Signing "this name does not exist" is harder, because there are infinitely many names that don't exist and the signer cannot sign each one in advance, and a server that signs on demand has to keep its private key online. DNSSEC's answer is to sort the zone's names and sign the gaps between them.

Sort every name in the zone in canonical order (RFC 4034 section 6.1: compare labels from the right, as lowercase bytes). Then give each name an NSEC record that says "the next name after me is X, and I hold these record types". If you ask for cat.example.test and the zone has blog and then mail, the signed NSEC at blog saying "next is mail" proves nothing lies between them. Its type list also proves "no such type" answers: the NSEC at mail listing only A proves there is no AAAA there. The resolver also needs one more NSEC proving no wildcard (*.example.test) could have produced an answer.

NSEC has a side effect: anyone can follow the chain of "next" pointers and list every name in your zone. This zone walking takes one query per name. For many zones that doesn't matter (the names are in certificates and search engines anyway), but some registries consider their list of customers confidential.

NSEC3 (RFC 5155) replaces each name with a hash of it before sorting. The chain now runs between hashes, so walking it gives you a list of hashes, not names. But hashes of short, common names can be guessed offline: hash www, mail, vpn and a few thousand more and see which match. NSEC3 originally allowed extra hash iterations and a salt to slow that guessing down. In practice the extra work fell mostly on resolvers and authoritative servers, an attacker with a graphics card shrugged it off, and RFC 9276 now says: iterations 0, no salt, and use plain NSEC unless you have a reason not to.

Keys get replaced: on a schedule, after a staff change, when moving to a better algorithm, or when moving to a new DNS provider. The difficulty is caching. At any moment, resolvers around the world hold copies of your DNSKEY set, your signatures and your parent's DS, each fetched at a different time and each expiring on its own TTL. A rollover is safe only if every combination a resolver could be holding still validates. RFC 6781 describes the standard methods and RFC 7583 works out their timing in detail.

• ZSK pre-publish. Add the new ZSK to the DNSKEY set, but keep signing with the old one. Wait at least the DNSKEY TTL, so every resolver's cached key set includes the new key. Switch the signatures to the new key. Wait at least the longest TTL of the signed data, so old signatures have aged out of caches. Then remove the old key.
• Double signature. Sign everything with both keys for a while. Fewer steps, twice the signatures in every answer; it is the usual choice for KSKs, where only the DNSKEY set is affected.
• KSK double-DS. Put the new key's DS in the parent next to the old one. Wait the DS TTL. Swap the KSK in your DNSKEY set. Wait the DNSKEY TTL. Remove the old DS.

Talking to the parent used to mean a web form at your registrar. RFC 7344 added CDS and CDNSKEY: records the child publishes in its own signed zone saying "this is what my DS should be". A parent that supports them polls the child and updates the DS itself, which makes KSK rollovers routine. RFC 8078 extends the idea to turning DNSSEC on or off.

The classic outage is changing DNS provider while the zone is signed. The new provider signs with its own keys, the DS at the parent still points at the old provider's KSK, and from the moment resolvers fetch the new keys every validating resolver returns SERVFAIL. The safe way is either to remove the DS first and wait out its TTL (going briefly insecure), or to have the two providers cooperate and publish each other's keys, the multi-signer model of RFC 8901. Instrument 3 shows both.

Each DNSKEY names its algorithm by number. For years the guidance lived in RFC 8624. In November 2025 RFC 9904 obsoleted it and moved the official recommendations into IANA's registries, so they can change without a new RFC; RFC 9905, published alongside it, deprecated SHA-1-based signing. The values below are the ones RFC 9904 placed in the registry, as updated by RFC 9905.

For DS records, digest type 2 (SHA-256) is the one to publish; SHA-1 (type 1) must not be used for new DS records. NSEC3's own hash is still SHA-1, which is acceptable there because it only obscures names; it is not a signature.

Once names can be trusted, other things can hang off them. DANE (RFC 6698) publishes a hash of a server's TLS certificate or key in a signed TLSA record, at a name like _25._tcp.mail.example.test. A client that validates DNSSEC can then check a server's certificate against what the domain owner published, rather than (or as well as) trusting any of the hundreds of certificate authorities. It has found its main home in mail transport between servers; web browsers never adopted it.