Cloudflare

DNSSEC Explained: Why It Was Invented and How It Protects Your DNS

By Travis · May 14, 2025 · 7 min read

#dnssec #dns #security #cloudflare #networking

Before we dive in: If you manage DNS for any domain, the single best thing you can do to make DNSSEC simple is to use Cloudflare as both your registrar and your DNS provider. When both are on Cloudflare, enabling DNSSEC is a single click — Cloudflare automatically handles the DS record, key management, and signing. No manual DS record submissions, no inter-provider coordination, no risk of getting the order wrong. We’ll cover this in detail in the companion post on implementing DNSSEC in Cloudflare.

The Problem: DNS Was Built Without Security

The Domain Name System (DNS) is the phone book of the internet — it translates human-readable domain names like example.com into IP addresses that computers use to route traffic. When you type a URL into your browser, a DNS resolver queries authoritative name servers and returns the answer.

DNS was designed in the 1980s for a cooperative, academic internet. Security was not a design requirement. The protocol has no built-in mechanism for verifying that a DNS response actually came from the legitimate authoritative server. A resolver that asks “what’s the IP for bank.com?” has no way to know whether the answer it receives is genuine.

This created a fundamental vulnerability that took decades to fully appreciate.

The Attack: DNS Cache Poisoning and Spoofing

The most dangerous exploitation of DNS’s lack of authentication is cache poisoning, also called the Kaminsky Attack (named after security researcher Dan Kaminsky who demonstrated its severity in 2008).

Here’s how it works:

An attacker floods a DNS resolver with forged responses, each claiming to be the authoritative answer for a domain
The resolver has no way to verify whether the response is genuine
If the forged response arrives before the legitimate one, the resolver caches the fake record
Every user that resolver serves now gets the attacker’s IP address instead of the real one — potentially for hours or days until the TTL expires

The consequences are severe. Users could be silently redirected to:

Fake banking sites that steal credentials
Phishing pages that look identical to legitimate services
Malware distribution servers
Attacker-controlled infrastructure for man-in-the-middle attacks

All of this happens transparently — users see no warning, their browser shows the correct URL, and the connection may even appear secure if the attacker has a valid TLS certificate for their phishing domain.

DNS Man-in-the-Middle attacks follow a similar pattern: an attacker positioned between a user and a DNS resolver modifies responses in transit, redirecting traffic without the user’s knowledge.

The Solution: DNSSEC

DNSSEC (DNS Security Extensions) was developed to address this problem. The core concept is straightforward: rather than trusting DNS responses based on where they came from, resolvers can now cryptographically verify that the data hasn’t been tampered with.

DNSSEC was standardized through a series of RFCs (RFC 4033, 4034, 4035) and has been progressively deployed across the internet since the mid-2000s, with the root zone being signed in 2010 — a landmark moment that established the foundation for a fully verifiable DNS hierarchy.

What DNSSEC Provides

Data integrity — You can verify that a DNS record hasn’t been modified in transit
Origin authentication — You can verify that a record genuinely came from the authoritative zone
Authenticated denial of existence — You can verify that a record genuinely doesn’t exist (preventing attackers from forging NXDOMAIN responses)

What DNSSEC Does NOT Provide

Encryption — DNS queries and responses still travel in plaintext. DNSSEC proves authenticity, not confidentiality. For encrypted DNS, you need DNS over HTTPS (DoH) or DNS over TLS (DoT).
Protection against all DNS attacks — DNSSEC doesn’t protect against DDoS against DNS infrastructure, or against a compromised authoritative server
Privacy — DNSSEC doesn’t hide which domains you’re looking up

How DNSSEC Works: Cryptographic Signing

DNSSEC uses public key cryptography — the same mathematical foundation as HTTPS certificates. Each DNS zone gets a key pair: a private key (kept secret, used to sign records) and a public key (published in DNS, used to verify signatures).

New Record Types

DNSSEC introduces several new DNS record types:

DNSKEY — Stores the zone’s public cryptographic key. Resolvers use this key to verify signatures.

RRSIG (Resource Record Signature) — A digital signature over a set of DNS records. Every signed record set has a corresponding RRSIG. When a resolver fetches an A record, it also fetches the RRSIG and verifies the signature using the zone’s DNSKEY.

DS (Delegation Signer) — A hash of a child zone’s DNSKEY, published in the parent zone. This is what creates the chain of trust between zones.

NSEC / NSEC3 — Provides cryptographic proof that a record does NOT exist, preventing attackers from forging NXDOMAIN responses. NSEC3 uses hashed names to prevent zone enumeration (walking the zone to enumerate all records).

Two Keys, Two Roles

DNSSEC uses a two-key model for operational security:

ZSK (Zone Signing Key): Signs the actual DNS records in the zone (A, MX, CNAME, etc.). Rotated frequently — often monthly — to limit exposure if compromised.

KSK (Key Signing Key): Signs the DNSKEY record set, which includes the ZSK. Changed infrequently because changing it requires updating the parent zone’s DS record. The KSK is the anchor that connects to the parent’s trust.

This separation is intentional: if a ZSK needs to be rotated, it can be done entirely within the zone without touching the parent. Only a KSK change requires coordination with the parent zone operator.

The Chain of Trust

The most important concept in DNSSEC is the chain of trust — a hierarchy of cryptographic verification that extends from the DNS root zone all the way down to individual domains.

Root Zone (.)
    ↓ signs
.com TLD Zone
    ↓ signs
example.com Zone
    ↓ signs
sub.example.com Zone

At each level, the parent zone publishes a DS record — a hash of the child zone’s KSK. This DS record is how a resolver knows to trust the child zone’s DNSKEY.

How Verification Works Step by Step

When a DNSSEC-validating resolver looks up www.example.com:

Root trust anchor — The resolver starts with a root KSK it already knows and trusts (pre-configured by the OS or resolver software). This is the ultimate trust anchor.
Root → .com — The resolver fetches the DS record for .com from the root zone, and the DNSKEY for .com. It hashes the .com KSK and compares it to the root’s DS record. Match → .com is trusted.
.com → example.com — The resolver fetches the DS record for example.com from .com, and the DNSKEY for example.com. It hashes the example.com KSK and compares it to .com’s DS record. Match → example.com is trusted.
example.com → www.example.com — The resolver fetches the A record for www.example.com and its RRSIG. It verifies the RRSIG using example.com’s ZSK (itself verified by the KSK). Match → the A record is authentic.
Result delivered — The resolver returns the IP address to the client with confidence that it hasn’t been tampered with.

If any link in this chain breaks — a missing DS record, an invalid signature, an expired RRSIG — the resolver returns SERVFAIL instead of the record. This all-or-nothing property is what makes DNSSEC powerful: a broken chain cannot be partially accepted.

The Root Signing Ceremony

At the very top of the chain, the root zone’s KSK is managed by ICANN through an elaborate Root Signing Ceremony — a physically secure, publicly audited event where several trusted individuals from around the world gather to sign the root DNSKEY. The ceremony produces the RRSIG records that allow resolvers to verify the root zone’s public key. The root KSK has only been rolled over once, in 2018, reflecting how consequential any change to the ultimate trust anchor is.

NSEC and NSEC3: Authenticated Non-Existence

One subtle but important capability DNSSEC provides is authenticated denial of existence. Without DNSSEC, if you query for a record that doesn’t exist, the response is just an NXDOMAIN with no way to verify it’s genuine. An attacker could forge NXDOMAIN responses to make real records appear not to exist.

DNSSEC solves this with NSEC (Next Secure) records, which form a sorted chain of all existing names in a zone. If a record doesn’t exist, the resolver can verify this cryptographically by checking the NSEC chain.

NSEC3 hashes the record names before publishing them, preventing zone walking — the ability to enumerate all records in a zone by following the NSEC chain.

What DNSSEC Helps DNS Owners With

For domain operators, DNSSEC provides:

Protection against cache poisoning — Forged DNS responses for your domain will fail cryptographic verification and be discarded by validating resolvers.

Trust signals — DNSSEC-signed domains signal to security-conscious operators that DNS integrity is taken seriously. Some enterprise environments and government agencies require DNSSEC for vendors.

Foundation for DANE — DNSSEC enables DANE (DNS-Based Authentication of Named Entities), which allows TLS certificates to be pinned in DNS. This provides an alternative trust mechanism to the CA system for email (SMTP) and other services.

Email security — DNSSEC protects your MX records and SPF/DKIM/DMARC TXT records from tampering, ensuring your email security configuration can’t be forged.

BGP and routing security complement — Just as RPKI secures BGP routing, DNSSEC secures DNS. The two together provide defense in depth for internet routing integrity.

The Deployment Gap

Despite being standardized over 20 years ago, DNSSEC adoption remains incomplete. As of 2025, a significant portion of the internet’s domains are still unsigned. The reasons are operational:

Complexity — Manually managing DNSKEY records, DS records, key rollovers, and RRSIG expiration is error-prone. A misconfiguration makes the domain unreachable for validating resolvers.
Registrar fragmentation — Adding DS records requires cooperation between your DNS provider and your registrar. When they’re different providers, this coordination adds friction and risk.
“Works without it” mentality — Since most resolvers don’t validate (or fail silently), DNSSEC failures often go unnoticed until someone with a validating resolver can’t reach the domain.

This is exactly why using Cloudflare as both your registrar and DNS provider removes nearly all of this friction. The automation Cloudflare provides around DNSSEC — one-click enabling, automatic DS record provisioning, automated key management — eliminates the primary barriers to adoption.

See the companion post for a step-by-step guide to implementing DNSSEC on parent and child zones in Cloudflare.