What Is DNSSEC? Securing the Internet's Phone Book
DNSSEC (Domain Name System Security Extensions) is a suite of extensions that adds cryptographic authentication to DNS responses. Standard DNS has no way to verify that a response actually came from the legitimate authoritative server and wasn’t modified in transit. DNSSEC fixes this by digitally signing DNS records so that resolvers can verify their authenticity. It doesn’t encrypt DNS traffic (that’s what DNS over HTTPS does), but it prevents cache poisoning attacks where an attacker injects fake DNS records to redirect you to malicious websites.
The Problem DNSSEC Solves
Standard DNS operates purely on trust. When your resolver asks a nameserver for the A record of yourbank.com, it accepts whatever response comes back. There’s no built-in verification that the response is genuine.
This opens the door to DNS cache poisoning (also called DNS spoofing). An attacker can:
- Race the legitimate DNS response and inject a fake one
- Compromise a resolver and insert fake records into its cache
- Execute a man-in-the-middle attack between the resolver and the authoritative server
In any of these scenarios, users who query the poisoned resolver get directed to the attacker’s server instead of the real one. The attacker’s server can look identical to the real site and harvest login credentials, credit card numbers, or any data the user submits.
The Kaminsky vulnerability (discovered in 2008 by Dan Kaminsky) demonstrated that DNS cache poisoning was far easier than previously thought. It sent shockwaves through the security community and accelerated DNSSEC adoption efforts.
How DNSSEC Works
DNSSEC adds four new record types to DNS:
RRSIG (Resource Record Signature): Contains the cryptographic signature for a set of DNS records. When a DNSSEC-validating resolver receives DNS records, it also receives the corresponding RRSIG. The resolver uses the domain’s public key to verify the signature.
DNSKEY: Publishes the public key used to verify RRSIG signatures. There are typically two keys: the Zone Signing Key (ZSK) that signs individual records, and the Key Signing Key (KSK) that signs the ZSK for an extra layer of security.
DS (Delegation Signer): Published in the parent zone. The .wiki zone contains a DS record for whatismyip.wiki that links the parent zone to the child zone’s DNSKEY. This creates the chain of trust.
NSEC/NSEC3 (Next Secure): Proves that a record doesn’t exist. Without this, an attacker could serve fake “this domain doesn’t exist” responses. NSEC3 is the hashed version that prevents zone enumeration.
The Chain of Trust
DNSSEC validation follows a chain from the root zone down:
Root Zone (signed by IANA's root KSK)
↓ DS record for .wiki
.wiki TLD Zone (signed by .wiki's KSK)
↓ DS record for whatismyip.wiki
whatismyip.wiki Zone (signed by domain's KSK)
↓ RRSIG covering A record
A record: 116.203.189.147 ✓
Each level vouches for the next through DS records, creating an unbroken chain of trust from the root zone to the individual record. If any link in the chain is broken or invalid, the resolver rejects the response.
Adoption Status
Despite being standardized in 2005 (RFCs 4033 to 4035), DNSSEC adoption has been painfully slow:
- About 30% of the top 1 million domains have DNSSEC enabled
- The root zone and all major TLDs are signed
- Several country-code TLDs mandate DNSSEC (.se, .nl, .br)
- Major DNS providers (Cloudflare, Google, Quad9) validate DNSSEC by default
The slow adoption stems from several factors:
Complexity: Setting up DNSSEC correctly requires generating key pairs, signing zones, publishing DS records with your registrar, and managing key rotation. Misconfiguration can make your domain completely unreachable.
Key management: DNSSEC keys need to be rotated periodically. The KSK rollover for the root zone in 2018 was a major operational undertaking that required years of planning.
Operational risk: Expired signatures or failed key rotations cause hard failures. Unlike most DNS misconfigurations that result in slow degradation, DNSSEC failures result in complete unavailability for validating resolvers.
No visible benefit: End users don’t see a green padlock or any other indicator that DNSSEC is working. The protection is invisible, making it hard to justify the operational overhead to management.
Cloudflare has helped adoption significantly by offering one-click DNSSEC for all domains on their platform. If your domain uses Cloudflare DNS, enabling DNSSEC is trivially easy and Cloudflare handles key management automatically.
DNSSEC vs DNS Encryption
It’s important to understand that DNSSEC and DNS encryption (DoH/DoT) solve different problems:
| DNSSEC | DoH/DoT | |
|---|---|---|
| Protects against | Response tampering | Eavesdropping |
| Encryption | No (data is signed but not encrypted) | Yes |
| Verification | Yes (proves data is authentic) | No (data could still be tampered with) |
| Where it works | Server-side (zone signing) | Client-side (query encryption) |
The ideal setup uses both: DoH/DoT encrypts your queries (privacy), and DNSSEC verifies the responses (integrity). They’re complementary, not competing.
Test It Yourself
Check DNSSEC Status
Look up any domain's DNS records and check if DNSSEC is enabled. See DNSKEY and DS records.