Skip to content

CONCEPT Cited by 1 source

DNSSEC

Definition

DNSSEC (Domain Name System Security Extensions; RFC 4033 + 4034 + 4035) adds cryptographic authentication to DNS. When a zone is signed with DNSSEC, each set of records is accompanied by a digital signature — an RRSIG record — that lets a resolver verify the records have not been tampered with.

From the 2026-05-06 Cloudflare DNSSEC .de outage post:

"DNSSEC (Domain Name System Security Extensions) adds cryptographic authentication to DNS. When a zone is signed with DNSSEC, each set of records is accompanied by a digital signature known as an RRSIG record that lets a resolver verify the records haven't been tampered with. Unlike encrypted DNS protocols, such as DNS over TLS (DoT) and DNS over HTTPS (DoH), DNSSEC is about integrity, not privacy. The records are visible, but their authenticity can be proven."

Integrity, not privacy

The most-repeated wiki distinction:

Protocol What it protects Encrypts payload?
DNSSEC Integrity + authenticity of DNS records No — records still visible
DoT / DoH Privacy of the transport Yes — but records still trusted-on-faith at the endpoint

They are complementary, not alternatives. DoH/DoT prevents a passive observer from seeing your DNS queries; DNSSEC prevents an on-path attacker (or a misconfigured upstream) from giving you a forged answer. A resolver can use both: DoH between the client and the resolver, DNSSEC for the resolver to validate the authoritative answer.

Signatures travel with records

A unique DNSSEC property:

"What makes DNSSEC unique is that the signatures travel together with the records they protect. This means integrity can be verified regardless of how many caches or hops a response has passed through. A cached record is just as verifiable as a fresh one."

Contrast with TLS, where the signature is bound to a specific connection. A DNS response in a resolver's cache carries its own RRSIG; any subsequent client can re-validate it locally.

Record types DNSSEC introduces

  • RRSIG — the digital signature for a record set (RRset).
  • DNSKEY — the public key used to verify RRSIG signatures. Two types:
  • Zone Signing Key (ZSK) — signs the zone's actual records.
  • Key Signing Key (KSK) — signs the ZSK (and only the ZSK). The KSK's public half is what the parent zone's DS record points at.
  • DS (Delegation Signer) — lives in the parent zone; contains a cryptographic hash of a child zone's KSK public key. Establishes the parent→child authority link in the chain of trust.
  • NSEC / NSEC3 — authenticated denial of existence ("prove that nonexistent.example.com genuinely has no records").

Validation flow (simplified)

  1. Resolver receives a DNS response with RRSIG records attached.
  2. Resolver fetches the signing DNSKEY from the same zone.
  3. Resolver verifies the RRSIG against the DNSKEY.
  4. Resolver walks up the chain: DS record in the parent hashes to the child's KSK; parent's DS is itself signed by the parent's ZSK; and so on back to the root zone, whose trust anchor is hardcoded into the resolver.
  5. If every link verifies, the answer is authentic. If any link fails, the resolver must return SERVFAIL — RFC compliance requires rejecting unverifiable data.

Why the failure-mode default is fail-closed

DNSSEC resolvers fail-closed on purpose: an authentic attacker substituting their own signed record must not be indistinguishable from a legitimate record. When verification fails, returning no answer is correct. The downside surfaces when the upstream zone itself publishes broken signatures — the DENIC .de incident of 2026-05-05 (see sources/2026-05-06-cloudflare-when-dnssec-goes-wrong-de-tld-outage) is the canonical example. The fix-in-the-small is a Negative Trust Anchor to treat the affected zone as unsigned until the upstream is repaired.

DNSSEC is not the failure when signing breaks

A common misreading after a DNSSEC incident is "DNSSEC failed as a technology". The 2026-05-06 Cloudflare post rejects that framing directly:

"any technology that is misconfigured will risk breaking for users that rely on it. Leaving critical fiber cables exposed on the seabed for sharks to chew on does not invalidate the important role underwater cables pose in today's Internet communications. It only highlights that we've sometimes failed to accurately protect it. The same applies here. DNSSEC serves a critical role in ensuring that we can rely on the DNS answers without tampering by malicious actors."

The validator's job is to reject broken signatures; the failure was in the upstream signing pipeline. DNSSEC surfaced it rather than caused it.

Operational ecosystem

  • Resolvers that validate: every major open-source resolver (BIND, Unbound, PowerDNS Recursor, Knot Resolver) plus the major public resolvers (1.1.1.1 via Big Pineapple, 8.8.8.8, 9.9.9.9).
  • Zones that are signed: ccTLDs (including the vast majority of European ccTLDs like .de, .nl, .se), many gTLDs, and a growing share of second-level domains.
  • Community coordination on operational DNSSEC issues happens on DNS-OARC.

Seen in

  • sources/2026-05-06-cloudflare-when-dnssec-goes-wrong-de-tld-outage — canonical wiki instance of DNSSEC as the enforcer that correctly rejected DENIC's broken rollover signatures, with the "integrity not privacy" definition and the "signatures travel with records" property quoted verbatim. Also canonical instance of the fail-closed default being deliberately bypassed via an NTA-equivalent when the break is widespread and publicly confirmed.
  • sources/2026-01-19-cloudflare-what-came-first-the-cname-or-the-a-record — DNSSEC context: RFC 4035's normative language around RRSIG inclusion gets contrasted with RFC 1034's ambiguous CNAME-ordering prose; DNSSEC post-dates RFC 2119 and is therefore written with MUST/SHOULD/MAY precision.
Last updated · 451 distilled / 1,324 read