Updated 2 hours ago
DNS was built on blind faith.
When you ask "where is example.com?" your computer sends that question into the network and believes whatever answer comes back. No verification. No proof of authenticity. Just trust—like asking a stranger for directions and following them without question.
Attackers exploit this. They intercept DNS responses and replace them with lies, redirecting you to malicious servers that look exactly like the sites you meant to visit. Your computer can't tell the difference because DNS never gave it the tools to check.
DNSSEC changes this. It adds cryptographic signatures to DNS, and DNSKEY and DS records are the foundation of how those signatures are verified. Together, they create a chain of trust that lets your computer prove—mathematically—that a DNS answer is authentic.
The Chain of Trust
The Internet's DNS is a hierarchy. At the top sits the root zone. Below it are the top-level domains like .com, .org, and .net. Below those are the domains you actually use: example.com, google.com, your company's domain.
DNSSEC creates a chain of cryptographic proof that follows this hierarchy. The root zone signs a statement about .com. The .com zone signs a statement about example.com. And example.com signs statements about its own records—the actual IP addresses you're looking for.
If every link in this chain is valid, the final answer is trustworthy. If any link is broken—a missing signature, an invalid proof, a hash that doesn't match—the whole thing fails. Your computer rejects the answer rather than trust a lie.
This is fail-secure design. DNSSEC would rather give you nothing than give you something forged.
DNSKEY Records: The Public Keys
Every signed DNS zone has DNSKEY records containing the public keys used to verify signatures. When example.com signs its DNS records, the signatures can only be verified with example.com's public key. That key lives in a DNSKEY record.
The components:
- 257 — Flags indicating this is a Key Signing Key (more on this shortly)
- 3 — Protocol field, always 3 for DNSSEC
- 13 — Algorithm number (ECDSA P-256 with SHA-256)
- The long string — The actual public key, base64 encoded
When a resolver receives a DNS record along with its signature (stored in an RRSIG record), it uses the DNSKEY to verify that signature. If the math checks out, the record is authentic.
Two Keys, Two Jobs
DNSSEC uses two types of keys, and the reason is practical.
The Zone Signing Key (ZSK) signs the actual DNS records—A records, MX records, everything in the zone. It's used constantly, every time the zone is re-signed. Because it's used so often, security practice says to rotate it frequently, typically every few months.
The Key Signing Key (KSK) has one job: sign the DNSKEY record set itself. The KSK vouches for both keys (including itself), and because it's used less often, it rotates less frequently—maybe once a year.
Why bother with two keys? Because of what happens when you change them.
When you rotate your ZSK, you generate a new one, re-sign your zone, and update your DNSKEY records. The outside world doesn't need to know. Your KSK—the key the parent zone trusts—hasn't changed.
When you rotate your KSK, the parent zone needs to be updated. That requires coordination, takes time, and creates windows where things can go wrong. By separating the keys, you minimize how often you need that coordination.
DS Records: The Chain Links
Here's the critical question: why should anyone trust example.com's DNSKEY? Anyone could publish a DNSKEY record claiming to be authoritative for example.com.
The answer is DS records. A DS record is a hash of a child zone's KSK, stored in the parent zone. The .com zone holds a DS record containing a hash of example.com's KSK. This creates the link in the chain of trust.
The fields:
- 12345 — Key tag, a quick identifier for which DNSKEY this refers to
- 13 — Algorithm number, matching the DNSKEY
- 2 — Digest type (SHA-256)
- The hex string — The hash of the child zone's DNSKEY
When a resolver wants to validate example.com, it first gets the DS record from .com (which it can verify using .com's DNSKEY). Then it gets example.com's DNSKEY and checks: does hashing this key produce the digest in the DS record? If yes, the key is legitimate. The parent zone has vouched for it.
Following the Chain
Walk through a real validation. You want to verify www.example.com.
First, the resolver needs to trust something. That something is the root zone's public key—the trust anchor. This key is distributed to resolvers through a secure out-of-band process and updated rarely. The root key is the one thing DNSSEC asks you to take on faith. Everything else, you can prove.
With the root key trusted:
-
Root → .com: The resolver asks the root for the DS record of .com. The root signs this response. The resolver verifies the signature using the root's DNSKEY. Now it has a trusted hash of .com's KSK.
-
.com → example.com: The resolver asks .com for its DNSKEY, verifies it matches the DS record from the root, then asks for example.com's DS record. The .com zone signs this response. Now the resolver has a trusted hash of example.com's KSK.
-
example.com → www: The resolver asks example.com for its DNSKEY, verifies it matches the DS record from .com, then asks for the A record of www.example.com along with its signature. It verifies the signature using example.com's ZSK (which is vouched for by the KSK, which is vouched for by the DS record).
Every step depends on the previous one. Break any link and validation fails.
When Keys Must Change
Keys don't last forever. Algorithms weaken. Keys might be compromised. Best practice is periodic rotation even without specific threats.
ZSK rollover stays within your zone. The typical approach: publish the new key alongside the old one, wait for caches to update, start signing with the new key while keeping old signatures around, wait again, then remove the old key and signatures. Gradual transitions ensure resolvers always have what they need.
KSK rollover is harder because you must update the DS record in the parent zone. The safe approach: publish both old and new KSKs, submit both DS records to the parent, wait for global propagation (this takes time—DNS caches are everywhere), then remove the old KSK and its DS record.
The timing is unforgiving. Remove the old KSK before the new DS record has propagated and you break validation for anyone still using cached data. Automated tools handle most of this now, but when something goes wrong, understanding the mechanics matters.
The Architecture of Proof
DNSSEC retrofits proof onto a system built on faith. DNSKEY records hold the public keys that verify signatures. DS records, stored in parent zones, link those keys into a chain by holding hashes of child zone keys.
The two-key system exists to make rotation manageable. Change your ZSK whenever you want. Change your KSK and you coordinate with your parent zone.
The chain flows from the root down through each level of the hierarchy. One trusted root key. Billions of domains, all provable. That's the architecture—mathematical proof layered onto a protocol that was never designed to prove anything.
Frequently Asked Questions About DNSKEY and DS Records
Sources
Was this page helpful?