DNSSEC: Securing the DNS Infrastructure

DNSSEC was standardized in RFC 4033-4035 in 2005. The root zone was signed in 2010. As of 2024, roughly 20% of .com domains have DNSSEC deployed. Adoption is not stellar.

This isn't because DNSSEC doesn't work. It does. It's because key management is genuinely annoying, zone walking is a real downside, and for most domains the operational cost outweighs the benefit. We'll cover both sides honestly.

What DNSSEC Actually Does

DNSSEC adds cryptographic signatures to DNS records. A validating resolver can verify that a response came from the authoritative zone owner and wasn't modified in transit. Cache poisoning becomes structurally impossible: an attacker can't forge a valid signature without the private key.

What DNSSEC does not do:

Encrypt DNS queries or responses (that's DoT/DoH)
Protect the confidentiality of who is querying what
Prevent DDoS attacks
Fix domain hijacking if the attacker gets your private key or controls the parent zone

DNSSEC provides data integrity and authenticity, not privacy.

The Chain of Trust

DNSSEC validation works through a hierarchy of trust anchored at the root zone.

Root Zone (.)
  └── Signed by root KSK (ICANN manages this)
      └── .com zone
          └── Signed by Verisign's KSK
              └── example.com zone
                  └── Signed by example.com's KSK

Each level trusts the level above it through a DS (Delegation Signer) record. The DS record in the parent zone contains a hash of the child zone's KSK public key. Validators start from the root (which they know and trust) and walk down.

Key Types

KSK (Key Signing Key): Signs the DNSKEY record set. This is the "anchor" key. Changed infrequently (annually or less) because changing it requires coordinating with the parent zone to update the DS record.

ZSK (Zone Signing Key): Signs all other records in the zone. Rotated more frequently (monthly is common) without requiring parent zone updates, because the ZSK is validated through the KSK.

# See a zone's keys
dig DNSKEY cloudflare.com +short

# You'll see two records: KSK (flag=257) and ZSK (flag=256)
# Flag 257 = KSK, Flag 256 = ZSK

DNS Record Types Added by DNSSEC

RRSIG: The digital signature for a record set. Every signed record type has an associated RRSIG.

DNSKEY: Contains the public keys (ZSK and KSK) for the zone.

DS (Delegation Signer): In the parent zone, contains a hash of the child zone's KSK. Establishes the chain of trust.

NSEC (Next Secure): Used to prove non-existence. When a name doesn't exist, NSEC proves it cryptographically by providing signed pointers to adjacent names in the zone.

NSEC3: Like NSEC but hashes the names first, preventing zone walking.

Validating a DNSSEC Response

# Check DNSSEC signature for a record
dig +dnssec example.com A

# Look for the AD flag in the flags section (Authenticated Data)
# AD flag = the resolver validated the DNSSEC chain
dig +dnssec cloudflare.com A | grep -E "flags:|RRSIG"

# Test a known-good DNSSEC domain
dig +dnssec sigok.verteiltesysteme.net A
# Should have AD flag and RRSIG records

# Test that your resolver rejects invalid signatures
dig sigfail.verteiltesysteme.net A
# Should return SERVFAIL if resolver validates DNSSEC

Check if a domain is DNSSEC-signed:

dig DS example.com +short  # DS record in parent = signed
# Or use DNSSEC Analyzer: https://dnssec-analyzer.verisignlabs.com

Zone Walking and Why NSEC3 Exists

NSEC records prove non-existence by listing the next existing name in the zone:

a.example.com NSEC c.example.com (A, AAAA, RRSIG, NSEC)

This proves that b.example.com doesn't exist. But it also lets you enumerate every name in the zone by following the NSEC chain from start to finish. This is zone walking. For zones where the records are semi-private (internal infrastructure, enumerable customer subdomains), this is a problem.

NSEC3 hashes zone names before including them in the chain:

H(a.example.com) NSEC3 H(c.example.com)

An attacker gets hashes, not names. Offline dictionary attacks against common names are possible (subdomain wordlists are not secret), but enumerating arbitrary names is infeasible.

NSEC3 with a random salt is the right choice for most zones. The tradeoff: NSEC3 adds computational overhead.

Key Rollover

ZSK rollover (monthly or quarterly): You generate a new ZSK, publish it alongside the old one (pre-publish), start signing with the new key, wait for caches to expire (based on DNSKEY TTL), then remove the old key. No parent zone coordination needed.

KSK rollover (annual or emergency): More complex. Requires updating the DS record in the parent zone. The sequence:

Generate new KSK, publish alongside old
Update DS record at parent (this requires action at the registrar)
Wait for parent DS TTL to expire
Remove old KSK from zone

If you automate nothing else in DNSSEC operations, automate ZSK rollover. Manual key rotation is where operational problems happen.

BIND supports automatic key rollover with auto-dnssec maintain. Knot DNS has excellent automatic signing. If you're managing DNSSEC with manual key generation and zone file editing, you're setting yourself up for an incident.

DNSSEC Deployment Reality

Signing a zone is not enough. The full chain requires:

Zone signed with DNSKEY and RRSIG records ✓
DS record published in parent zone (registrar action required) ✓
Validating resolver between user and authoritative server ✓

Step 3 is outside your control. If a user's resolver doesn't validate DNSSEC, they won't get the protection. As of 2024, roughly 30-40% of global DNS queries are validated by DNSSEC-validating resolvers (based on APNIC measurements). That's growing, but slowly.

The resolver side: Google (8.8.8.8), Cloudflare (1.1.1.1), and most major ISP resolvers validate DNSSEC. If your users are behind these resolvers, DNSSEC helps them.

When You Actually Need DNSSEC

You need DNSSEC if:

Your domain is a high-value target for cache poisoning or interception (banking, government, critical infrastructure)
You use DNS-based authentication like DANE (which requires DNSSEC to be meaningful)
You want TLSA records for verified TLS without relying on CAs
Regulatory compliance requires it (some government frameworks mandate it)

DNSSEC is probably overkill if:

You're running a small blog or personal project
Your registrar's DNS hosting doesn't support it well
You don't have the operational capacity to manage key rollovers properly

A poorly managed DNSSEC zone that fails validation (because someone forgot to roll keys or update DS records) is worse than no DNSSEC at all — it breaks resolution for validating resolvers.

Key Takeaways

DNSSEC provides cryptographic data integrity for DNS records. It prevents cache poisoning and forgery but does not encrypt queries.
The chain of trust runs from root zone to TLD to your zone, connected by DS records.
KSK signs DNSKEY records; ZSK signs everything else. Rotate ZSKs frequently, KSKs carefully.
NSEC enables zone walking; NSEC3 with a salt mitigates it.
Automate key rollover. Manual rotation at scale is an incident waiting to happen.
Validate both the AD flag in resolver responses and the full chain using tools like DNSSEC Analyzer.

Up Next

Lesson 06 covers DNS over HTTPS and DNS over TLS: how they solve the privacy problem that DNSSEC doesn't, and the new problems they create.