DNSSEC Explained

Plain DNS has no security. Your resolver asks “what’s the IP for example.com?” and trusts whatever response comes back. An attacker who can intercept or spoof the response can redirect you to a malicious server. DNSSEC (DNS Security Extensions) fixes this by cryptographically signing DNS records, so resolvers can verify the answers really came from the authoritative server.

What DNSSEC does (and doesn’t)

Does

• Proves DNS responses are authentic (not forged)
• Proves they haven’t been modified in transit
• Proves a name doesn’t exist (NSEC/NSEC3 records)

Does NOT

• Encrypt your DNS queries (use DoH or DoT for that)
• Hide what you’re looking up from network observers
• Stop your ISP from logging queries

The core idea: signed records

Every DNS record gets a corresponding signature record (RRSIG). Resolvers fetch both and verify the signature using the zone’s public key (DNSKEY).

example.com.   3600  IN  A      93.184.216.34
example.com.   3600  IN  RRSIG  A 8 2 3600 ... (signature)

The 4 main DNSSEC record types

Type	Purpose
DNSKEY	Public keys used to sign records in this zone
RRSIG	Signature for a set of records
DS	Hash of child zone’s DNSKEY, stored in parent zone (chain of trust)
NSEC / NSEC3	Authenticated denial — “no record of this type exists for this name”

The chain of trust

For a resolver to trust a DNSSEC response, it must follow a chain from a known trusted root to the answer:

Root zone (.)
  └── trust anchor (built into resolvers, hardcoded)
  └── DS for .com → trust .com's keys

  .com zone
    └── DS for example.com → trust example.com's keys

    example.com zone
      └── RRSIG signs the A record we asked for
      └── Resolver verifies signature using example.com's DNSKEY
      └── ANSWER VALIDATED ✓

If any link in this chain is broken (e.g., parent doesn’t have a DS record), validation fails. The resolver returns SERVFAIL.

Two key types per zone

• KSK (Key Signing Key) — long-lived, rolls every few years. Signs only the DNSKEY records. Its hash is in the parent’s DS record.
• ZSK (Zone Signing Key) — shorter-lived, rolls more often. Signs all the actual data records.

This split lets you rotate the working key (ZSK) without involving the registrar (which would be needed to change the KSK / DS).

Check if a domain has DNSSEC

# Look for DS records at the parent zone
dig +short example.com DS

# Look for DNSKEY records
dig +short example.com DNSKEY

# Validate manually (uses +sigchase for chain check)
dig +sigchase example.com

# Online tools
# - dnssec-analyzer.verisignlabs.com
# - dnsviz.net (visual)

Enabling DNSSEC for your domain

1. Your DNS provider generates the keys and signs your zone (Cloudflare, Route 53, etc. all have a one-click toggle for this)
2. Your DNS provider gives you a DS record
3. Your registrar (where you bought the domain) accepts the DS record and puts it in the parent zone
4. Within 24-48 hours, the chain is established

The downsides

• Bigger DNS responses — adds 200-500 bytes per response, sometimes triggering TCP fallback
• Operational complexity — key rollovers can break things if mishandled
• Doesn’t help with last-mile — you need DoH/DoT to protect the connection between you and your resolver
• Adoption is partial — only ~30% of domains have DNSSEC

Why it matters anyway

For high-value domains (banks, government, large SaaS), DNSSEC is essential. Cache-poisoning attacks like Kaminsky’s 2008 demonstration showed you can hijack DNS for entire enterprises. DNSSEC stops this.

For your tech blog, it’s nice to have but lower priority than HTTPS, strong TLS config, and decent backups.

What to learn next

That covers DNS. Next big topic: HTTP — the protocol you use most, even if you’ve never thought about it as a protocol. Up next on the roadmap.