DNSSEC

DNSSEC chain of trust, ZSK/KSK key pairs, RRSIG/DNSKEY/DS records, validation process, and real-world adoption challenges.

Overview

Overview DNSSEC (Domain Name System Security Extensions) adds cryptographic authentication to DNS, protecting against cache poisoning and man-in-the-middle attacks. Without DNSSEC, a resolver has no way to verify that the answer it received for a query actually came from the authoritative nameserver and was not tampered with in transit. The 2008 Kaminsky attack demonstrated how DNS cache poisoning could be weaponized at scale, accelerating DNSSEC adoption.

DNSSEC does not encrypt DNS traffic — it only signs DNS responses so resolvers can verify authenticity. Each DNS zone signs its resource records with a private key, and resolvers validate those signatures using the corresponding public key, which is itself authenticated by the parent zone.

The trust chain starts at the DNS root (managed by IANA). The root zone signs the keys for TLDs (.com, .org), TLDs sign the keys for second-level domains, and so on down the hierarchy. A validating resolver only needs to trust the root's public key (the Root Trust Anchor, updated via RFC 5011) to validate any signed zone.

DNSSEC introduces several new record types: DNSKEY (public keys), RRSIG (cryptographic signatures over resource record sets), DS (Delegation Signer, a hash linking parent to child zone), and NSEC/NSEC3 (authenticated denial of existence for NXDOMAIN responses).

In practice, DNSSEC adoption remains incomplete. Many registrars support it, but configuration complexity, key rollover procedures, and the risk of SERVFAIL on misconfiguration cause many operators to skip it. High-value domains (banking, government) are more likely to be signed. Cloud DNS services like Route 53 and Cloud DNS support DNSSEC signing. DNSSEC does not protect against DDoS amplification (it makes responses larger), and it cannot prevent compromised authoritative servers from serving false signed records.

Key concepts

Zone Signing Key (ZSK): The ZSK is the key pair used to sign individual resource record sets (RRSets) within a zone. The private ZSK signs each RRSIG record; the public ZSK is published in the zone as a DNSKEY record. ZSKs are rotated frequently (monthly to quarterly) because they are used heavily. Rollover is done using either pre-publication (publish new key before using it) or double-signature (sign with both keys simultaneously) methods.
Key Signing Key (KSK): The KSK signs only the DNSKEY RRSet (which contains the public ZSK). The KSK's public key hash is submitted to the parent zone as a DS record, anchoring the chain of trust. KSKs are rotated less frequently (annually) because changing them requires coordination with the parent zone registrar to update the DS record. A KSK rollover that fails to update the DS record in the parent zone will cause SERVFAIL for all validators.
DS Record (Delegation Signer): A DS record lives in the parent zone (e.g., .com) and contains a hash of the child zone's KSK public key. When a resolver queries child.example.com and receives a referral, it fetches the DS record from the parent and compares it to the DNSKEY in the child zone. A match means the child zone's keys are authenticated by the parent. DS records use algorithm numbers (e.g., 13 = ECDSA P-256 SHA-256, 8 = RSA SHA-256) to identify the signing algorithm.
RRSIG Record: An RRSIG record is a cryptographic signature over a specific RRSet (e.g., the A records for www.example.com). It contains the signature itself, the algorithm used, the key tag identifying which DNSKEY signed it, and an expiration timestamp. Resolvers verify the RRSIG by fetching the DNSKEY, reconstructing the canonical RRSet wire format, and verifying the signature. Expired RRSIGs cause SERVFAIL — zone signing must re-sign before expiry.
NSEC and NSEC3: Authenticated denial of existence records. NSEC links zone names in sorted order, allowing resolvers to prove that a queried name does not exist (NXDOMAIN) without requiring the zone to be online to sign each negative response. However, NSEC allows zone enumeration (walking the chain reveals all names). NSEC3 hashes the names with a salt before chaining, preventing trivial enumeration. NSEC3 with opt-out mode reduces signing overhead for large zones with many unsigned delegations.
Chain of Trust: The unbroken cryptographic path from the DNS root to the queried zone. Root zone signs TLD DNSKEY via DS record in root, TLD signs second-level domain DNSKEY via DS record in TLD, and so on. A validating resolver starts at the Root Trust Anchor (a hardcoded or RFC 5011-managed public key) and follows DS records down to the queried zone. Any break in the chain — missing DS record, mismatched key, expired RRSIG — causes SERVFAIL for strict validators.

When to use it

Evaluating whether a domain is properly secured against cache poisoning and BGP hijacking attacks.
Debugging SERVFAIL errors caused by DNSSEC validation failures at the resolver.
Configuring a new domain on a registrar that supports DS record submission.
Designing a certificate issuance pipeline using DANE (TLSA records anchored by DNSSEC).
Auditing DNS security posture for compliance frameworks that require authenticated DNS.

Interview questions

Explain the DNSSEC chain of trust from the root to a leaf domain. What records are involved at each step?
How would you debug a SERVFAIL that you suspect is caused by a DNSSEC validation failure?
What is the difference between ZSK and KSK, and why are two key pairs used instead of one?

DNSSEC

Overview

Key concepts

When to use it

Interview questions

More Networking topics