DNSSEC Explained: How DNS Cryptographic Signatures Actually Work

The Domain Name System was designed to be cache-friendly. Recursive resolvers ask authoritative servers; answers propagate; intermediate caches store records for the duration of their TTL. Nothing in the original protocol authenticates any of this. A response that arrives at your resolver carrying the answer to a question it just asked is trusted because… it has the right transaction ID and shows up in the right time window.

DNS cache poisoning, the Kaminsky attack (2008), BGP-hijack-routed DNS, and ordinary on-path tampering all exploit this. DNSSEC — the DNS Security Extensions, defined principally in RFCs 4033/4034/4035 — adds digital signatures so that a resolver can cryptographically verify a record came from the zone that's authoritative for it.

The Chain of Trust

DNSSEC's central idea: every zone signs its records with a private key, publishes the corresponding public key, and lets the parent zone vouch for that public key. Walk the chain from a record up through zones to the root, and you have a cryptographic path you can verify.

The walk looks like this for example.com:

1. Resolver fetches example.com's A record (the IP) and its RRSIG (the signature on that record).
2. Resolver fetches example.com's DNSKEY — the public key the RRSIG verifies against.
3. Resolver fetches the DS (Delegation Signer) record for example.com from the .com zone. The DS is a hash of example.com's DNSKEY, signed by .com's key.
4. Resolver fetches .com's DNSKEY and its DS record from the root zone.
5. Resolver verifies against the root's trust anchor — a public key shipped with the resolver software and rotated through KSK ceremonies every few years.

If every signature in that chain verifies, the resolver knows the A record is authentic. If any link fails — a missing DS, a mismatched signature, an expired RRSIG — the resolver returns SERVFAIL and the lookup fails closed.

The Record Types You Actually Need to Know

Record	What it does
DNSKEY	The public key for a zone. Zones typically have two: a Zone Signing Key (ZSK, frequently rotated) and a Key Signing Key (KSK, rarely rotated and pointed at by the parent's DS).
RRSIG	A signature over a Resource Record Set. Includes signer name, algorithm, validity window, and the signature bytes themselves.
DS	Delegation Signer. Lives in the parent zone. A hash of the child's KSK, signed by the parent. This is the link between zones.
NSEC / NSEC3	Authenticated denial of existence. Proves that a given name does NOT exist by signing a record that says "between names A and C, nothing exists." NSEC3 hashes the names to make zone enumeration harder.
CDS / CDNSKEY	Child copies of DS and DNSKEY. Allow zones to signal key rollovers to their parent via DNS itself.

Why It's Still Under-Deployed

DNSSEC's adoption curve is famously sluggish. As of 2026, roughly 90% of TLDs are signed, but only a small fraction of second-level domains are signed, and only somewhere around 30% of recursive queries arrive at a validating resolver. The reasons are operational, not technical.

Operational complexity

Signing a zone requires key management, signature regeneration before expiry, and coordination with the registrar to publish DS records in the parent. A misconfiguration takes the domain offline for validating resolvers — and the failure mode is silent for everyone else, which makes it hard to detect.

Signature expiry as a footgun

RRSIGs have a validity window — typically 7–30 days. If automation fails to re-sign before the window closes, every record in the zone becomes invalid. Major outages from this exact failure: HBO Max, Slack, Microsoft Office 365 tenant DNS — multiple high-profile cases over the past decade where signature expiry took services offline.

Algorithm transitions

Many zones still use RSA-SHA256. The modern recommendation is ECDSA-P256-SHA256, which produces smaller signatures and smaller DNSKEY records. Some zones haven't transitioned. Others stayed on old algorithms because their registrar's DS-update tooling lagged.

What DNSSEC Does Not Do

It's important to be precise about DNSSEC's threat model. It is authentication, not confidentiality.

• Does not encrypt queries or responses. Anyone watching the wire still sees what you looked up. For confidentiality you need DoH, DoT, or DoQ.
• Does not prevent last-mile tampering between your resolver and your device. Unless your stub resolver validates DNSSEC itself, an attacker on your local network can still rewrite responses after the recursive resolver has done validation.
• Does not authenticate the IP you connect to. It authenticates the DNS record. If that record points to an attacker-controlled IP that the legitimate owner accidentally signed, DNSSEC will validate the lie.
• Does not stop NXDOMAIN-rewriting by ISPs that bypass DNSSEC. If your ISP filters its own responses before you get them, DNSSEC catches it only if you validate yourself.

DNSSEC and Modern Protocols

DNSSEC pairs naturally with several modern protocols that need to bind cryptographic material to a name:

• DANE (DNS-Based Authentication of Named Entities) — publish TLS certificate hashes in DNS, signed by DNSSEC, instead of trusting public CAs. Heavily used for SMTP MTA-to-MTA security via MTA-STS and DANE-TA.
• SSHFP — publish SSH host key fingerprints in DNS. Lets clients verify the host key without a TOFU prompt, if the lookup is DNSSEC-validated.
• SVCB / HTTPS records — used by ECH to distribute server config. ECH's value depends on the lookup being authenticated, which means DNSSEC.
• CAA records — CAA tells CAs which authorities may issue certs for a domain. Signing CAA with DNSSEC closes a class of issuance-bypass attacks.

DNSSEC is the boring infrastructure layer that quietly enables the more famous privacy work above it. Encrypted Client Hello assumes DNS authenticity. DANE assumes it. SSHFP assumes it. None of those works as designed without DNSSEC under them.

Should You Enable It on Your Zone?

For most domains, yes — with automation. The decision criteria:

• Does your registrar support DS publishing? Most major ones now do.
• Does your DNS host support automatic re-signing? Cloudflare, Route 53, NS1, Bind 9.11+ all do.
• Are you willing to monitor signature expiry? At minimum, a Prometheus exporter or external check (e.g. dnsviz.net) checking weekly.

If yes to all three, the security benefit is real. If no — especially the third — leaving DNSSEC off is honestly safer than enabling it badly. The footguns are real.

Haven's havenmessenger.com zone is DNSSEC-signed; we pair it with SPF, DKIM, and DMARC and BIMI so that name-resolution authenticity, sender authenticity, and brand visibility all reinforce each other.