How DNSSEC Works: A Technical Deep Dive

Technical Guide • Updated December 2024

DNSSEC uses public-key cryptography to add authentication to DNS responses. This guide explains the complete mechanism, from zone signing to resolver validation.

The Two Key Types: KSK and ZSK

DNSSEC uses a two-key system to balance security and operational efficiency:

Zone Signing Key (ZSK)

The ZSK signs the actual DNS records in a zone. It's used frequently (every time zone data changes) and typically rotated every 1-3 months. Shorter key length (1024-2048 bits) keeps signatures compact.

Key Signing Key (KSK)

The KSK signs only the ZSK—it vouches for the ZSK's authenticity. The KSK is rotated less often (annually or less) and uses a longer key (2048-4096 bits) for stronger security. The KSK's hash is published as the DS record in the parent zone.

The Chain of Trust

DNSSEC establishes trust through a hierarchical chain from the DNS root to your domain:

Root Zone

The DNS root zone is signed by ICANN. The root's public key is the "trust anchor" pre-configured in validating resolvers.

TLD Zone

The root zone contains DS records for each TLD (.com, .org, etc.). These DS records vouch for the TLD's keys.

Your Domain

The TLD zone contains DS records for your domain. Your domain's DNSKEY records can now be trusted through this chain.

DNS Records

Your zone's RRSIG records, verified using your trusted DNSKEY, authenticate the actual DNS data.

DNSSEC Record Types Explained

RRSIG (Resource Record Signature)

Every DNS record set has a corresponding RRSIG containing its digital signature. The RRSIG includes:

  • Algorithm used (RSA, ECDSA, Ed25519)
  • Signature expiration and inception times
  • The signer's key tag (identifies which key signed it)
  • The actual cryptographic signature

DNSKEY

Contains the public keys for the zone. Flags indicate whether it's a KSK (257) or ZSK (256). The key data is Base64-encoded.

DS (Delegation Signer)

Published in the parent zone, the DS record contains a hash of the child zone's KSK. This is the link that establishes trust between zones. The DS record includes:

  • Key tag of the referenced DNSKEY
  • Algorithm number
  • Digest type (SHA-256 recommended)
  • The key digest itself

NSEC and NSEC3

These records provide authenticated denial of existence—proof that a queried name does not exist. NSEC3 adds hashing to prevent zone enumeration attacks.

The Validation Process

When a DNSSEC-validating resolver receives a response, it performs these steps:

  1. Fetch the RRSIG records for the requested data
  2. Fetch the DNSKEY records for the zone
  3. Verify the RRSIG using the ZSK from the DNSKEY set
  4. Verify the ZSK using the KSK (check the self-signature)
  5. Fetch the DS record from the parent zone
  6. Verify the DS matches the KSK's hash
  7. Recursively validate up to the root trust anchor

If any step fails, the response is marked as BOGUS and rejected. If the zone is unsigned (no DS record in parent), it's marked as INSECURE.

Signature Algorithms

DNSSEC supports multiple cryptographic algorithms:

Algorithm Number Status Notes
RSASHA256 8 Recommended Widely supported, good security
RSASHA512 10 Supported Larger signatures
ECDSAP256SHA256 13 Recommended Smaller keys and signatures
ECDSAP384SHA384 14 Supported Higher security ECDSA
ED25519 15 Recommended Modern, efficient

Key Rollover

Keys must be rotated periodically. The two main rollover methods:

  • Pre-publish: New key is published before use, then activated. Old key removed after TTL expires.
  • Double-signature: Both old and new keys sign records during transition period.

KSK rollovers require updating the DS record with the registrar, which adds coordination complexity.

Related Resources