vault

DNSSEC

17 min read

DNSSEC

Classic DNS answers are unauthenticated: a resolver accepts any response that looks like it matches its query, with no way to prove the answer actually came from the zone’s owner. That is the root cause of cache poisoning and answer forgery. DNSSEC — the DNS Security Extensions (RFC 4033, 4034, 4035, 2005) — fixes this by attaching public-key digital signatures to DNS data. Every record set is signed (an RRSIG), the signing public keys are published (DNSKEY), and each zone’s keys are vouched for by a hash held in its parent (DS), forming an unbroken chain of trust from the DNS root down to any signed name. DNSSEC guarantees data origin authentication and data integrity — it does not provide confidentiality (queries stay in the clear; for that you need DoH) and explicitly “provides no protection against denial of service attacks” (RFC 4033). This note owns how DNSSEC authenticates answers; the encrypted-transport story is a separate, composable guarantee.

Mental Model — Signatures Chained From a Single Root of Trust

The mental model is a notarized chain. Each zone signs its own records with a private key and publishes the matching public key. But a public key by itself proves nothing — anyone can generate a key pair. The trick is that the parent zone publishes a small fingerprint (a hash) of the child’s key, and the parent’s own records are signed, and its key is fingerprinted by its parent, all the way up to the root, whose key a validating resolver knows a priori (it is built in as the trust anchor). To validate www.example.com, a resolver starts from the one key it trusts — the root’s — and walks down: the root vouches for .com’s key, .com vouches for example.com’s key, and example.com’s key verifies the signature on the www A record. Break any link and validation fails “Bogus.”

flowchart TD
  ROOT["Root zone<br/>trust anchor (root KSK)<br/>built into the resolver"]
  COM[".com zone<br/>DNSKEY (KSK+ZSK)"]
  EX["example.com zone<br/>DNSKEY (KSK+ZSK)"]
  REC["www.example.com A record<br/>+ RRSIG (signature)"]
  ROOT -->|"DS(.com) in root, signed by root ZSK<br/>= hash of .com KSK"| COM
  COM -->|"DS(example.com) in .com, signed by .com ZSK<br/>= hash of example.com KSK"| EX
  EX -->|"RRSIG over the A RRset, made by example.com ZSK"| REC

Figure: the DNSSEC chain of trust. Each DS record (held in the parent) hashes the child’s key-signing key; each DNSKEY set is signed by its own KSK; each data record is signed by its zone’s ZSK. The insight — validation only ever needs one pre-configured trust anchor (the root key), because every other key is authenticated transitively by the link above it.

What DNSSEC Guarantees (and What It Does Not)

RFC 4033 is precise about scope, and getting this right is half of understanding DNSSEC:

  • It provides: data origin authentication (the answer really came from the zone’s authoritative data) and data integrity (the answer was not altered in transit or in a cache). A validating resolver that accepts a DNSSEC-signed answer has cryptographic proof it is genuine.
  • It does not provide confidentiality. Queries and answers still travel in the clear; DNSSEC signs data, it does not encrypt it. An eavesdropper still sees every name you look up. Confidentiality is the job of DoQ — orthogonal to DNSSEC and composable with it.
  • It does not protect against denial of service. In fact DNSSEC worsens some DoS vectors: signed responses are larger, and DNSSEC-signed zones have been abused as amplifiers in reflection attacks.

So DNSSEC’s one job is authenticity. It is the categorical answer to the Kaminsky cache-poisoning problem: an off-path attacker can flood forged UDP answers all day, but without the zone’s private key they cannot produce a valid RRSIG, so a validating resolver discards every forgery.

The Four Record Types

DNSSEC introduces four new resource-record types (RFC 4034). Understanding what each holds is understanding DNSSEC.

RRSIG — the signature over an RRset

DNSSEC signs RRsets (resource-record sets — all records sharing the same owner name, class, and type), not individual records. Every signed RRset gets a paired RRSIG record containing the digital signature and the metadata needed to verify it. Its fields (RFC 4034 §3):

  • Type Covered — which RR type this signature protects (e.g. A).
  • Algorithm — the signing algorithm (e.g. RSA/SHA-256, or ECDSA P-256).
  • Labels — the number of labels in the original owner name; used to detect and correctly validate wildcard expansions.
  • Original TTL — the TTL the record had in the authoritative zone. This is essential: caches decrement TTLs, but the signature was computed over the original value, so the validator must restore it before checking the signature.
  • Signature Expiration and Inception — an absolute validity window. RFC 4034: the RRSIG “MUST NOT be used for authentication prior to the inception date and MUST NOT be used … after the expiration date.” Unlike TTLs, these are wall-clock times, which is why DNSSEC signatures expire and must be periodically re-signed even if the data never changes — a major operational burden and a frequent outage cause.
  • Key Tag and Signer’s Name — a short fingerprint and the zone name that together let the validator find the right DNSKEY to verify with.
  • Signature — the actual cryptographic signature over the RRset plus these fields.

DNSKEY — the public keys, split into ZSK and KSK

A zone publishes its public signing keys in DNSKEY records at the zone apex. Fields include a Flags field, a fixed Protocol field (always 3), an Algorithm, and the Public Key itself. Two flag bits matter: bit 7, the Zone Key flag (set when the key signs zone data), and bit 15, the Secure Entry Point (SEP) flag — a hint marking keys intended as entry points to the zone.

In practice operators run two keys, a split defined operationally in RFC 6781 (validators treat all zone keys identically; the split is purely a management convenience):

  • Zone Signing Key (ZSK) — signs the actual zone data (the A, MX, TXT RRsets). It is used constantly, so it is kept online and is typically shorter/cheaper and rolled frequently.
  • Key Signing Key (KSK) — signs only the DNSKEY RRset (i.e. it signs the ZSK and itself). It is the key the parent’s DS record points to, so it is the zone’s public “identity.” Because it is used rarely, it can be kept offline with tighter access control, and it is longer-lived. The SEP flag is conventionally set on the KSK and not the ZSK.

Why the split? Rolling a ZSK is a purely internal operation — the operator publishes a new ZSK, re-signs, and retires the old one without ever touching the parent. Only a KSK rollover requires coordinating with the parent to update the DS record. Decoupling the frequently-rolled data-signing key from the parent-anchored identity key is what makes routine key hygiene tractable.

DS — the delegation link in the parent

The Delegation Signer (DS) record is what connects a child zone to its parent, forming the chain. It contains a Key Tag, Algorithm, Digest Type (the hash algorithm), and Digest — a cryptographic hash of the child’s KSK DNSKEY. The critical structural fact (RFC 4034 §5): “the DS RR appears only on the upper (parental) side of a delegation,” while the DNSKEY it hashes lives in the child. So example.com’s DS record is published in the .com zone, signed by .com’s ZSK. When you enable DNSSEC on your domain, the single most important step is getting your DS record installed at your registry/parent — that is the act that plugs your zone into the global chain of trust. A missing or mismatched DS is the most common DNSSEC misconfiguration.

NSEC — authenticated proof of non-existence

Signing records that exist is straightforward. The subtle problem is proving a name or type does not exist — you cannot sign a record that isn’t there, yet an unsigned “NXDOMAIN” could be forged. NSEC (Next Secure) solves this by signing the gaps. Each NSEC record names, in canonical order, the next owner name that actually exists in the zone, plus a Type Bit Maps field listing which types do exist at the current name. To prove nothere.example.com does not exist, the zone returns a signed NSEC saying, in effect, “the name alphabetically before it is nice.example.com, and the next existing name after that is open.example.com, and nothing exists between them” — a signed statement of a gap. To prove example.com has an A but no MX, the NSEC’s type bitmap lists A (and NSEC, RRSIG) but not MX. Because the NSEC record is itself signed by an RRSIG, the denial is authenticated.

NSEC3 — Fixing the Zone-Walking Leak

Plain NSEC has an ugly side effect: because every NSEC record points to the next real name, an attacker can walk the entire zone by repeatedly querying and following the chain — “the complete set of NSEC records lists all the names in a zone” (RFC 5155). For a zone that considers its list of subdomains (or the email-address-shaped names in it) sensitive, this is an unwanted disclosure.

NSEC3 (RFC 5155) fixes it by proving non-existence over hashes of names instead of the names themselves: “the owner names used in the NSEC3 RR are cryptographic hashes of the original owner name.” An NSEC3 record’s fields are the Hash Algorithm, Flags, Iterations, Salt, Next Hashed Owner Name, and Type Bit Maps. The chain now links hash-to-hash in hash order, so following it reveals only opaque hashes, not plaintext names. Two parameters harden the hashing against precomputation: a Salt (“appended to the original owner name before hashing … to defend against pre-calculated dictionary attacks”) and an Iterations count (“the number of additional times the hash function has been performed”). A zone advertises its active parameters in an NSEC3PARAM record at the apex so secondaries know how to construct denials.

NSEC3 adds an Opt-Out flag for large delegation-centric zones (like TLDs): when set, “the NSEC3 record covers zero or more unsigned delegations,” letting the operator add or remove insecure delegations without re-signing the NSEC3 chain — a major performance win for zones like .com with hundreds of millions of mostly-unsigned delegations.

NSEC3 is a speed bump, not a wall. RFC 5155 is candid that it “remains susceptible to dictionary attacks” — an attacker can pull all the NSEC3 hashes offline and brute-force likely names against them; the salt and iterations only make it more expensive. This residual weakness (and the CPU cost of high iteration counts, which enable a DoS on validators) is why modern guidance pushes iteration counts low — a reversal from early practice.

The Chain of Trust and the Root KSK

Validation (RFC 4035) starts from a trust anchor — a key the resolver trusts intrinsically. For the global DNS there is essentially one: the root zone’s KSK, the top of the entire hierarchy. A validating resolver ships with the root key configured, then for any name builds the authentication chain — RFC 4033 describes it as “alternating DNSKEY and DS RRsets,” each link vouching for the next. To validate www.example.com: verify the root’s DNSKEY against the trust anchor; use it to verify the .com DS in the root; hash .com’s KSK and check it matches that DS; use .com’s DNSKEY to verify the example.com DS; hash example.com’s KSK and check that DS; finally use example.com’s ZSK to verify the RRSIG over the A record. Any broken link, expired signature, or missing DS yields SERVFAIL to the client — DNSSEC fails closed (RFC 4035: on validation failure “the name server MUST return RCODE 2 to the originating client”). RFC 4035 classifies every RRset into one of four security states: Secure (a chain of signed DNSKEY/DS records reaches it from a trust anchor and validates), Insecure (a signed, authenticated delegation proves the zone is legitimately unsigned — the common case today), Bogus (a chain should exist but fails to validate — the alarm state signalling forgery or, far more often, operator error like an expired signature), and Indeterminate (no trust anchor covers the name, so the resolver cannot tell). Only Secure sets the AD bit; Bogus is what SERVFAILs.

Signaling rides on three header bits: the DO (DNSSEC OK) bit in the query says the client wants DNSSEC records; the AD (Authenticated Data) bit in the response says the validating resolver checked the signatures and they passed; the CD (Checking Disabled) bit lets a client ask the resolver not to validate (useful for debugging or when the client validates itself).

The root KSK and its 2018 rollover. Because the root KSK anchors everything, changing it is one of the highest-stakes operations on the Internet, performed at ceremonial Root Key Signing Ceremonies where vetted Trusted Community Representatives physically participate under multi-party control. The root KSK had never been changed from its 2010 original until the first-ever rollover to “KSK-2017.” It was scheduled for 11 October 2017 but postponed when telemetry (gathered via RFC 8145 trust-anchor signaling) revealed “a significant number of resolvers … were not yet ready” — many had not picked up the new key despite RFC 5011 automated trust-anchor updates (Internet Society, Sep 2017). After a year of outreach the rollover finally happened on 11 October 2018 (ICANN, Oct 2018). The episode is the canonical lesson in how hard key rollover is at planetary scale — not because the cryptography is hard, but because cached trust anchors live in resolvers nobody controls, exactly the same TTL-and-staleness problem caching creates everywhere in DNS.

Key Rollover Mechanics

RFC 6781 details why rolling keys is delicate: “data published in previous versions of their zone still lives in caches,” so a validator may hold an old key or old signature while fetching new data. Remove the old key too soon and cached-but-still-valid signatures become unverifiable → the zone goes Bogus; keep it too long and you extend the cryptanalytic exposure window. The two standard ZSK rollover methods manage the overlap:

  • Pre-Publish rollover — publish the new ZSK in the DNSKEY RRset first (without using it to sign), wait for it to propagate into caches, then switch signing to it while both keys remain published, and only later remove the old key. Avoids doubling zone size; takes four phases.
  • Double-Signature rollover — sign every RRset with both old and new keys simultaneously, wait out the old signatures’ cache lifetime, then drop the old key. Simpler (three phases) but temporarily doubles the number of signatures in the zone.

A KSK rollover uses the double-signature approach at the apex and must coordinate the parent DS: publish the new KSK, obtain a new DS from the parent, wait at least the DS TTL for old DS records to expire from caches, then remove the old KSK. The parent-coordination step is exactly what the ZSK/KSK split was designed to make rare.

Why Adoption Stays Low

DNSSEC has existed since 2005 and is technically sound, yet deployment on the signing side remains strikingly low. As of 2023, Verisign reported only about 4.3% of .com and 5.3% of .net domains were signed (CircleID, Sep 2023). The validation side is healthier — a large fraction of users sit behind resolvers that validate — but there is a persistent asymmetry APNIC highlights: “there is no real point in incurring the additional overheads in signing DNS responses if no one is validating,” and conversely little incentive to validate when so few zones are signed (APNIC, Oct 2023). The reasons adoption lags:

  • Operational complexity and fragility. Signatures expire on a wall clock, so a zone must re-sign on schedule forever; a missed re-signing or a botched key rollover takes the domain completely offline for validating users (SERVFAIL), not merely degraded. DNSSEC turns a static zone file into a live cryptographic operation with its own failure modes.
  • The DS/registrar bottleneck. Plugging into the chain requires getting a DS record installed at the parent via the registrar, and registrar support has historically been patchy — APNIC notes signing rates near 16% where a dominant national registrar handles DNSSEC cleanly, but under 10% where registrar support is fragmented.
  • Weak perceived payoff. With encrypted transport (DoH) and source-port randomization already blunting the on-path threat, many operators judge DNSSEC’s marginal benefit not worth its operational risk — a debatable but widespread calculus.

Uncertain

Verify: the precise current DNSSEC validation percentage (fraction of users behind validating resolvers) and the signed-domain percentages. Reason: figures are point-in-time and move; the ~4.3%/5.3% signed figures are Verisign 2023 data, and validation-rate figures vary by measurement methodology (APNIC ad-based vs Cloudflare Radar) — this note did not pin a single current validation percentage to a primary source. To resolve: consult APNIC Labs’ live DNSSEC stats (stats.labs.apnic.net/dnssec) and current Verisign/ICANN reports at read time.

Failure Modes

  • Expired signatures. The most common self-inflicted outage: automated re-signing fails, RRSIGs pass their expiration, and every validating resolver returns SERVFAIL for the whole zone. The domain is unreachable for validating users while working fine for non-validating ones — a confusing “half the Internet can’t reach us” symptom.
  • Broken chain / missing or stale DS. If the DS in the parent does not match the child’s current KSK (e.g. after a KSK roll without updating DS), validation fails Bogus. Enabling DNSSEC but never installing the DS is the classic beginner error — the zone is signed but not anchored, so nothing validates it.
  • Algorithm rollover pitfalls. Migrating signing algorithms (e.g. RSA→ECDSA) requires careful staged publication; a validator that understands neither the old nor new algorithm, or a botched transition, breaks validation.
  • NSEC3 iteration DoS. High iteration counts force validators to do expensive hashing, enabling a CPU-exhaustion attack — modern guidance is to keep iterations low (even zero).
  • Amplification abuse. Signed responses are large; open resolvers and signed zones are attractive reflectors for DDoS amplification. DNSSEC’s own answer to authenticity thus introduces an availability trade-off.

Alternatives and Boundaries

DNSSEC is not interchangeable with the encrypted-transport protocols — they solve different problems and are meant to compose. DoQ give confidentiality (and channel integrity between you and your resolver) but prove nothing about whether the resolver’s answer is genuine; a lying resolver defeats them. DNSSEC gives end-to-end authenticity of the data regardless of how many caches or resolvers it passed through, but leaks the query in cleartext. The strong posture is both: encrypt the channel and validate the signatures. DNSSEC also unlocks capabilities transport encryption cannot — most notably DANE (DNS-Based Authentication of Named Entities), which publishes TLS certificate constraints in DNS, safe only because DNSSEC authenticates them. Where DNSSEC’s operational cost is judged too high, the pragmatic fallback is unsigned DNS hardened with source-port randomization + 0x20 + a validating-but-unsigned trust model + encrypted transport — weaker than DNSSEC’s cryptographic guarantee, but the reality for the ~95% of domains that remain unsigned.

Production Notes

The 2018 root KSK rollover is the reference production event: a year-long, telemetry-driven, ceremonially-executed operation, delayed precisely because ICANN could see (via RFC 8145 signaling) that too many resolvers still trusted only the old key — a vivid demonstration that the hard part of DNSSEC is not the math but the globally-distributed, cache-resident state. On the day-to-day side, the dominant production reality is that DNSSEC’s failure mode is total outage, not graceful degradation: an expired signature or broken chain SERVFAILs the whole zone for validating users, which is why large operators automate signing and monitoring aggressively and why many smaller operators avoid DNSSEC entirely rather than risk a self-inflicted outage. The persistent low signing rate (single-digit percentages of .com/.net a decade and a half after standardization) is the field’s honest verdict: the guarantee is real and the cache-poisoning threat it kills is real, but the operational tax has kept it a minority deployment. Anyone enabling it should treat re-signing and DS-record correctness as first-class monitored infrastructure, not fire-and-forget configuration.

See Also

Graph View