Skip to content

CONCEPT Cited by 4 sources

DNSSEC

Definition

DNSSEC (DNS Security Extensions) adds origin authentication and integrity to DNS answers using public-key cryptography. A validating resolver checks a cryptographic signature (RRSIG) on each DNS record set against a public key published in the zone's DNSKEY set, so it can verify an answer is authentic and unmodified. DNSSEC provides authenticity, not confidentiality — it does not encrypt queries or answers (that is the job of DoT/DoH); it proves that the answer you got is the one the zone owner published.

Because a resolver cannot trust a zone's keys on their own say-so, DNSSEC builds a chain of trust rooted at a preconfigured trust anchor — the DNS root's key-signing key.

Record types

Record Role
DNSKEY Public keys a zone publishes (both ZSK and KSK).
RRSIG A signature over a record set, made with a DNSKEY.
DS (Delegation Signer) A fingerprint of a child zone's DNSKEY, published by the parent. The link in the chain.
NSEC / NSEC3 Authenticated denial of existence ("this name does not exist").

The two root keys: KSK and ZSK

The DNS root publishes two keys with split duties (the same split applies to any signed zone):

  • Zone-signing key (ZSK) — signs the zone's ordinary records, including the DS records that delegate to TLDs such as .com.
  • Key-signing key (KSK) — signs only the DNSKEY RRset (the published key list). The resolver verifies the key list with the KSK it trusts, then trusts the ZSK found inside that list.

This indirection lets the ZSK rotate frequently (small, routine) while the KSK — the actual trust anchor — changes rarely and carefully (a key rollover).

How validation works

For cloudflare.com, a resolver walks the delegation chain:

  1. Start from the trusted root KSK (the trust anchor) → verify the root DNSKEY set → trust the root ZSK → verify the root's DS record for .com.
  2. The .com DS fingerprints .com's KSK → verify .com's DNSKEY set → trust .com's ZSK → verify the DS for cloudflare.com.
  3. That DS fingerprints cloudflare.com's key → verify cloudflare.com's DNSKEY set → verify the RRSIG on the A record.

Each parent vouches for its child via a DS record; the root has no parent, so its trust must be preconfigured in the resolver.

Fails closed

A broken DNSSEC validation path is unreachable, not degraded: a correctly behaving validating resolver returns SERVFAIL rather than serve a possibly-forged answer — it fails closed. The consequence is that a working website can become completely unreachable if anything in its validation chain breaks (an expired signature, a mismatched DS, or — at the root — a key the resolver doesn't trust). Canonical wiki instances: the .de (2026-05) and .al (2026-07) TLD rollover failures where DENIC / the .al registry published non-validatable signatures and systems/cloudflare-1-1-1-1-resolver|1.1.1.1 correctly refused to validate. (Source: sources/2026-05-06-cloudflare-when-dnssec-goes-wrong-de-tld-outage)

Operators cushion and override this fail-closed behaviour with two levers:

  • Serve-stale (RFC 8767) keeps answering from cache while TTLs age out, buying time during an upstream break.
  • Negative Trust Anchor (NTA) (RFC 7646) — a resolver operator deliberately disables DNSSEC validation for a specific broken zone to restore reachability, trading authenticity for availability once the break is confirmed external.

Key rollovers and trust-anchor distribution

Changing the KSK — a KSK rollover — is the hardest DNSSEC operation because the root KSK is the one key with no parent to vouch for it. Every validating resolver must independently come to trust the new key before it starts signing. Two mechanisms:

  • RFC 5011 automatic update — the root publishes the new KSK alongside the old one, still signed by the trusted KSK; a resolver verifies the newcomer, waits ≥ 30 days of continuous presence, then accepts it as a new anchor.
  • Built-in anchors shipped in resolver software — the vendor bakes the new anchor into the binary, so the resolver trusts it from startup without relying on retained learned state. Cloudflare chose this for KSK-2024 after resolvers lost RFC-5011-learned state across upgrades during the 2017 rollover. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)

See concepts/key-rotation for the general discipline and the KSK-2024 → KSK-2017 October 11, 2026 root rollover specifics.

Verifying what a resolver trusts: the RFC 8509 sentinel

RFC 8509 defines a root key trust anchor sentinel: specially-named labels (root-key-sentinel-is-ta-<tag> / root-key-sentinel-not-ta-<tag>) let a user ask a supporting resolver whether it trusts a given root key, using ordinary DNS queries. A sentinel-aware resolver validates the signed answer and then returns it or substitutes SERVFAIL depending on trust. This closes the gap from the 2017 rollover, when operators had no practical way to check whether a resolver had retained the new key. 1.1.1.1 implements it; test with dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev A. (Source: sources/2026-10-06-cloudflare-the-keys-to-the-internet-change-on-october-11-are-you-ready)

DNSSEC and post-quantum

DNSSEC is authenticity-only, so it is not subject to harvest-now-decrypt-later — the quantum threat to it is live forgery at Q-Day, not retroactive decryption. Making the whole chain post-quantum needs the root, every parent, and signed zones to adopt a PQ algorithm — i.e. a post-quantum KSK rollover. 1.1.1.1 already validates ML-DSA-44 DNSSEC signatures (IANA DNSSEC algorithm number 18). Because zones publish classical + PQ signatures together during transition, RFC 6840's "accept any single valid path" rule becomes a downgrade vector; 1.1.1.1 uses the parent DS RRset as an authenticated signal to require a PQ path once one is advertised. (Source: sources/2026-09-10-cloudflare-1111-post-quantum-dnssec)

Seen in

Last updated · 854 distilled / 2,448 read