DNS & Networking

DNSSEC Implementation Guide

How DNSSEC protects DNS from cache poisoning using cryptographic signatures, with practical steps for signing your zone and validating the chain of trust.

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

SymptomCauseFix
`SERVFAIL` for all clientsSignature expiredRenew signatures (auto-rotation should handle this)
Chain broken at registrarDS record missing/wrongRe-submit DS record
Works with `8.8.8.8`, fails with ISPISP does DNSSEC validationFix the actual signature issue

DNSSEC vs DoH/DoT

TechnologyProtects AgainstDoes Not Protect Against
DNSSECResponse tamperingEavesdropping, MITM
DoH/DoTEavesdroppingResponse tampering
Both togetherBothNothing DNS-related

DoH (DNS over HTTPS) and DoT (DNS over TLS) encrypt the query in transit. DNSSEC authenticates the response content. They are complementary.

โปรโตคอลที่เกี่ยวข้อง

คำศัพท์ในอภิธานศัพท์ที่เกี่ยวข้อง

เพิ่มเติมใน DNS & Networking