Why DNSSEC?
Standard DNS has no authentication — a resolver cannot verify that the answer it received is genuine. The Kaminsky attack (2008) demonstrated that DNS caches could be poisoned in seconds, redirecting users to attacker-controlled servers without their knowledge.
DNSSEC (DNS Security Extensions, RFC 4033–4035) adds cryptographic signatures to DNS records. Resolvers that validate DNSSEC can detect tampered responses and refuse to use them.
How DNSSEC Works
Signatures and Keys
Each DNS zone is signed with a Zone Signing Key (ZSK). For every record set (RRset), a corresponding RRSIG record contains the cryptographic signature:
example.com. 3600 IN A 203.0.113.10
example.com. 3600 IN RRSIG A 8 2 3600 20240301000000 20240201000000 12345 example.com. <base64 signature>
The Key Signing Key (KSK) signs the ZSK, and the KSK's hash is published as a DS (Delegation Signer) record in the parent zone:
example.com. 3600 IN DNSKEY 257 3 8 <KSK public key>
example.com. 3600 IN DNSKEY 256 3 8 <ZSK public key>
Chain of Trust
Root zone (.) — signed with IANA's root KSK
└── .com — root DS record points to .com KSK
└── example.com — .com DS record points to example.com KSK
└── www.example.com — signed by example.com ZSK
A validating resolver walks this chain from the root to verify every signature. If any link is broken or a signature is invalid, the resolver returns SERVFAIL rather than the potentially poisoned answer.
DS and DNSKEY Records
DNSKEY— the public key record in your zone. Contains both KSK (flag 257) and ZSK (flag 256).DS— the hash of your KSK, published in the *parent* zone by your registrar. This is what establishes the chain of trust.RRSIG— the signature for each RRset. Auto-generated by your DNS provider when signing is enabled.NSEC/NSEC3— authenticated denial of existence. Proves that a name does not exist without revealing all zone contents.
Signing Your Zone
Most DNS providers offer one-click DNSSEC activation:
Cloudflare: Dashboard → DNS → Settings → DNSSEC → Enable. Cloudflare generates keys, signs records, and shows you the DS record to submit to your registrar.
Route 53: Enable DNSSEC signing on the hosted zone, then create a Key Signing Key in Route 53 and establish the chain of trust via Route 53 → Customer Managed Keys.
Registrar Configuration
After signing, submit the DS record to your domain registrar:
DS record values to submit:
Key Tag: 12345
Algorithm: 13 (ECDSA P-256 SHA-256)
Digest Type: 2 (SHA-256)
Digest: ABCDEF1234567890...
The registrar publishes this as a DS record in the parent zone (.com, .org, etc.), completing the chain of trust.
Validation Testing
# Check if DNSSEC is enabled and chain of trust is valid
dig +dnssec example.com
# Look for 'ad' (Authenticated Data) flag in the response header
# ;; flags: qr rd ra ad
# ^^ authenticated
# Full chain validation
delv example.com A # part of bind-utils
# Online validator
# https://dnssec-debugger.verisignlabs.com/example.com
Common Failures
| Symptom | Cause | Fix |
|---|---|---|
| `SERVFAIL` for all clients | Signature expired | Renew signatures (auto-rotation should handle this) |
| Chain broken at registrar | DS record missing/wrong | Re-submit DS record |
| Works with `8.8.8.8`, fails with ISP | ISP does DNSSEC validation | Fix the actual signature issue |
DNSSEC vs DoH/DoT
| Technology | Protects Against | Does Not Protect Against |
|---|---|---|
| DNSSEC | Response tampering | Eavesdropping, MITM |
| DoH/DoT | Eavesdropping | Response tampering |
| Both together | Both | Nothing DNS-related |
DoH (DNS over HTTPS) and DoT (DNS over TLS) encrypt the query in transit. DNSSEC authenticates the response content. They are complementary.