After the Kaminsky attack in 2008 made the urgency undeniable, the DNS community accelerated deployment of a solution that had been in development since the mid-1990s: DNSSEC — the Domain Name System Security Extensions.
DNSSEC adds cryptographic signatures to DNS responses. It doesn’t encrypt anything — your queries still travel in plaintext, and anyone watching the wire can see what domains you’re looking up. What DNSSEC does is authenticate: it lets a resolver verify that a DNS response genuinely came from the authoritative source and hasn’t been tampered with in transit.
That distinction — authentication without encryption — is crucial. DNSSEC solves cache poisoning. It doesn’t solve privacy. Those are different problems with different solutions.
The Problem DNSSEC Solves
Recall the cache poisoning attacks from Chapter 1. The fundamental issue is that DNS responses carry no proof of authenticity. A resolver receives a UDP packet claiming to contain an answer from the authoritative server for example.com, but it has no way to verify that claim beyond checking a 16-bit transaction ID and the source port.
DNSSEC fixes this by adding digital signatures to DNS data. The authoritative server for example.com signs its records with a private key. Any resolver can verify those signatures using the corresponding public key. If the signature doesn’t match, the data has been forged or tampered with — and the resolver rejects it.
But this raises an obvious question: how does the resolver know it has the right public key? What if the attacker forges both the DNS data and the key?
The answer is a chain of trust.
The Chain of Trust
DNSSEC builds a hierarchy of cryptographic trust that mirrors the DNS hierarchy itself:
Root Zone (.)
│ Signs the root zone; public key is the trust anchor
│ DS record for .com points to com's key
▼
.com TLD
│ Signs the com zone with its own key
│ DS record for example.com points to example.com's key
▼
example.com
│ Signs its zone data with its own key
▼
www.example.com → A record + RRSIG (signature)
The resolver starts with a single, pre-configured trust anchor: the root zone’s public key. From there, each level of the hierarchy vouches for the level below it through DS (Delegation Signer) records. The root zone contains a DS record that authenticates .com’s key. The .com zone contains a DS record that authenticates example.com’s key. And so on.
This is analogous to the certificate authority model in TLS/HTTPS — but built into the DNS hierarchy itself rather than relying on external CAs.
Key Types: KSK and ZSK
DNSSEC uses two types of keys for each zone:
Key Signing Key (KSK)
The KSK is the zone’s identity key. It’s a larger, more secure key (typically 2048-bit RSA or 256-bit ECDSA) used to sign the zone’s DNSKEY record set. The KSK’s hash is published as a DS record in the parent zone, forming the link in the chain of trust.
Because the KSK is referenced by the parent zone, changing it requires coordinating with the parent (your registrar and the TLD registry). KSKs are typically rolled infrequently — every one to two years, or longer.
Zone Signing Key (ZSK)
The ZSK is the workhorse key. It signs all other record sets in the zone. The ZSK is typically smaller (1024-bit RSA, though 2048-bit and ECDSA are now common) and rolled more frequently — every one to three months.
The separation exists for operational reasons. Rolling a ZSK is a zone-local operation — you generate a new key, re-sign your records, and publish both keys briefly during the transition. Rolling a KSK requires updating the DS record in the parent zone, which involves coordination with external parties. By using two keys, routine key rotation (ZSK) stays fast and local.
DNSSEC Record Types
DNSSEC introduces four new record types (extending the standard DNS record types):
DNSKEY
The DNSKEY record publishes a zone’s public keys. A zone typically has at least two DNSKEY records — one for the KSK and one for the ZSK.
example.com. IN DNSKEY 257 3 13 (
mdsswUyr3DPW132mOi8V9xESWE8jTo0d... ; KSK (flag 257)
)
example.com. IN DNSKEY 256 3 13 (
DaTnKIvf6oFDz3gMhNR7JhBWGsMqHKQ2... ; ZSK (flag 256)
)
The flags field distinguishes KSKs (257, with the Secure Entry Point bit set) from ZSKs (256). Algorithm 13 is ECDSA P-256 (RFC 6605), the current recommended algorithm.
RRSIG
The RRSIG record contains the digital signature for a record set. Every signed record set in the zone has a corresponding RRSIG.
www.example.com. IN A 93.184.216.34
www.example.com. IN RRSIG A 13 3 3600 (
20260401000000 20260301000000 12345
example.com.
oJB1W6WNGv+ldvQ3WDG0MQkg5IEh... )
The RRSIG includes: the algorithm used, the number of labels in the name, the original TTL, signature expiration and inception timestamps, the key tag (identifying which DNSKEY was used), the signer’s name, and the signature itself.
Note the expiration dates. RRSIG signatures have limited validity periods. If signatures expire and aren’t re-signed, the zone becomes bogus — validating resolvers will refuse to return its data. This has caused real outages, including at major organizations that forgot to re-sign their zones.
DS (Delegation Signer)
The DS record lives in the parent zone and contains a hash of the child zone’s KSK. It’s the cryptographic link that connects the chain of trust across zone boundaries.
; In the .com zone:
example.com. IN DS 12345 13 2 (
49FD46E6C4B45C55D4AC69... )
The fields are: key tag (matching a DNSKEY in the child zone), algorithm, digest type (2 = SHA-256), and the digest itself.
NSEC and NSEC3 (Authenticated Denial of Existence)
DNSSEC needs to authenticate not just positive answers but also negative ones — proving that a name or record type doesn’t exist. Without this, an attacker could strip DNSSEC signatures from legitimate responses and replace them with unsigned forged data.
NSEC records create a chain linking all existing names in a zone in canonical order. If you query for a name that doesn’t exist, the server returns the NSEC records that bracket where the name would appear — proving there’s a gap.
alpha.example.com. IN NSEC gamma.example.com. A RRSIG NSEC
This NSEC record says: “The next name after alpha is gamma — there’s nothing between them.” If you queried for beta.example.com, this proves it doesn’t exist.
The problem with NSEC is zone walking: by following the NSEC chain, anyone can enumerate every name in the zone. For many organizations, this is unacceptable — their internal hostnames are considered sensitive.
NSEC3 (RFC 5155) solves this by hashing domain names before creating the chain. Instead of revealing alpha.example.com, the NSEC3 record contains the hash of the name. An attacker can still walk the chain, but they only get hashes — recovering the original names requires offline dictionary attacks.
NSEC3 added an “opt-out” flag that allows unsigned delegations to be skipped, reducing the number of NSEC3 records in large zones like .com (which has millions of delegations, most unsigned).
The Validation Process
When a DNSSEC-validating resolver receives a response, it performs the following steps:
- Receive the answer and its RRSIG — e.g., the A record for
www.example.comand the corresponding RRSIG - Fetch the DNSKEY records for
example.com— these contain the public keys - Verify the RRSIG using the ZSK from the DNSKEY set — confirm the A record’s signature is valid
- Verify the DNSKEY set’s RRSIG using the KSK — confirm the DNSKEY records themselves are authentically signed
- Fetch the DS record from the parent zone (
.com) — this contains the hash ofexample.com’s KSK - Verify the DS matches the KSK — confirm the KSK hash in the parent zone matches the actual KSK
- Repeat up the chain — verify
.com’s keys against the root zone’s DS record, and verify the root’s keys against the pre-configured trust anchor
If every link in the chain validates, the response is secure. If any link fails, the response is bogus and the resolver returns SERVFAIL to the client.
If a zone simply isn’t signed (no DNSKEY records exist), the response is insecure — the resolver returns the answer but can’t guarantee its authenticity. This is the status of the vast majority of domains today.
The Root KSK Rollover (2017-2018)
The root zone’s KSK is the ultimate trust anchor — every DNSSEC validation chain terminates there. In October 2018, ICANN completed the first-ever root KSK rollover, replacing the key that had been in use since 2010 (KSK-2010, key tag 19036) with a new key (KSK-2017, key tag 20326).
The rollover was originally scheduled for October 2017 but was postponed by a year when ICANN discovered that a significant number of resolvers hadn’t updated their trust anchors. The risk was real: if a resolver’s trust anchor doesn’t match the current root KSK, all DNSSEC validation fails, and users behind that resolver lose access to DNSSEC-signed domains.
The successful rollover in 2018 validated RFC 5011’s automated trust anchor update mechanism (which most major resolver implementations support) and demonstrated that the root KSK can be changed — an essential capability for long-term cryptographic agility.
Deployment Challenges
Despite being standardized in 2005 (RFC 4033-4035) and operational at the root since 2010, DNSSEC adoption remains disappointingly low. As of 2025, fewer than 10% of .com domains are signed, and validation rates vary enormously by country and ISP.
Why DNSSEC Is Hard
Operational complexity. DNSSEC adds key management, signature generation, and rollover procedures to DNS operations. Keys expire. Signatures expire. Rolling keys requires careful timing to avoid validation failures. One misconfigured rollover can take a domain offline for every validating resolver.
Zone size inflation. DNSSEC signatures dramatically increase zone size and response size. A zone that was 1 MB unsigned might be 5-10 MB signed. Larger responses mean more TCP fallback (since they exceed UDP’s practical limits), more bandwidth, and more processing.
Fragile failure modes. When DNSSEC breaks, it breaks hard. An expired signature doesn’t degrade gracefully — the domain simply stops resolving for all DNSSEC-validating clients. Traditional DNS failures are usually partial; DNSSEC failures are total.
Limited resolver validation. Even if you sign your zone, the benefit depends on resolvers actually validating signatures. Many ISP resolvers still don’t validate DNSSEC. Google Public DNS (8.8.8.8) and Cloudflare (1.1.1.1) do validate, but they serve a fraction of global DNS traffic.
No encryption. DNSSEC doesn’t provide confidentiality. After all the complexity of deploying it, your DNS queries are still visible to every observer on the network path. This has led some to argue that encrypted transports (DoH, DoT) are a better investment of operational effort.
The Chicken-and-Egg Problem
Domain owners don’t sign because few resolvers validate. Resolver operators don’t validate because few domains are signed. Breaking this cycle has proven remarkably difficult.
Despite these challenges, DNSSEC remains the only mechanism that provides origin authentication for DNS data. Encrypted transports protect the query path but don’t verify the answer’s authenticity. In an ideal world, you’d want both — DNSSEC for authentication and encrypted transport for privacy. The real world has made that combination rare.
Key Takeaways
- DNSSEC provides authentication, not encryption — it proves DNS data is genuine, not that it’s private
- The chain of trust mirrors the DNS hierarchy: root → TLD → domain, with each level vouching for the next
- KSK and ZSK separation allows routine key rotation without parent zone coordination
- RRSIG records contain signatures; DS records link the chain across zones; NSEC/NSEC3 prove non-existence
- The 2018 root KSK rollover was a landmark event demonstrating long-term key management
- Adoption remains low due to operational complexity, fragile failure modes, and a persistent chicken-and-egg problem