What is DNSSEC?

What DNSSEC is#

DNSSEC (Domain Name System Security Extensions) is a suite of specifications that adds cryptographic authentication to DNS responses. Without DNSSEC, a resolver has no way to verify that the data it receives actually came from the domain's authoritative server; it trusts whatever response arrives first. DNSSEC closes this gap by allowing zone operators to sign their records so resolvers can validate them before accepting the answer.

DNSSEC provides data integrity and origin authentication, not encryption. Queries and responses still travel in plaintext unless combined with DNS over HTTPS (DoH) or DNS over TLS (DoT). DNSSEC prevents tampering with DNS answers but does not hide which domains a client is resolving.

The chain of trust#

DNSSEC works through a hierarchical chain of trust that mirrors the DNS delegation model:

1. The root zone is signed with a well-known key managed through a public ceremony process conducted by ICANN. Resolvers are configured to trust this root key as the trust anchor. The root key signing key (KSK) was last rolled in 2018; it remains the only root KSK rollover to date.

2. Each TLD (e.g., .com) publishes its own signing keys and places a DS (Delegation Signer) record in the root zone, linking the TLD's key to the root.

3. Individual domains repeat the pattern. The domain's zone is signed, and a DS record in the TLD zone links it upward. The domain's name servers serve the signed records.

A validating resolver follows this chain from the root down. If any link is broken (an unsigned parent zone, a missing DS record, or an expired signature) validation fails. This all-or-nothing property means DNSSEC either fully validates or produces a SERVFAIL, which can make misconfiguration worse than having no DNSSEC at all.

Key DNSSEC record types#

DNSSEC introduces several record types beyond standard DNS:

• RRSIG. Contains the cryptographic signature for a record set. Every signed record set (e.g., all A records at a name) has a corresponding RRSIG with an expiration time.
• DNSKEY. Holds the public key used to verify RRSIG signatures. A zone typically publishes two keys, a Zone Signing Key (ZSK) that signs individual record sets, and a Key Signing Key (KSK) that signs the DNSKEY record set itself.
• DS. A hash of a child zone's DNSKEY, published in the parent zone to establish the trust chain. This is the glue between parent and child in the chain of trust.
• NSEC / NSEC3. Provide authenticated denial of existence, proving that a queried name or record type does not exist. NSEC reveals adjacent names in the zone (enabling zone walking). NSEC3 mitigates this by hashing owner names, though determined attackers can still enumerate zones offline by brute-forcing the hashes.

What DNSSEC does not do#

A common misconception is that DNSSEC encrypts DNS traffic. It does not; an observer on the network path can still see every query and response. DNSSEC also cannot prevent:

• Registrar account compromise. If an attacker changes records through the registrar (including updating DS records), DNSSEC provides no protection because the replacement records carry valid signatures
• DNS hijacking at the registrar level. The attacker can point NS records to their own servers and publish new DNSSEC keys with a matching DS record
• BGP hijacking. A route hijacker cannot forge valid DNSSEC signatures, so data integrity is preserved, but the hijacker can drop or blackhole DNS traffic, causing denial of service that DNSSEC cannot recover from
• Attacks outside DNS. Phishing sites on lookalike domains can deploy their own valid DNSSEC signatures

DNSSEC is a defense against cache poisoning and on-path response manipulation. It is not a comprehensive domain security solution.

Deployment challenges#

Despite being standardized since 2005, DNSSEC adoption remains uneven. Signing rates vary widely by TLD, and only a fraction of .com domains have DS records published. On the resolver side, roughly 30% of recursive resolvers perform full validation. Key challenges include:

• Key management. Rotating Zone Signing Keys and Key Signing Keys requires coordination between the zone operator and the parent zone (for DS updates). Errors can cause resolution failures for the entire zone. Automated key management via CDS and CDNSKEY records helps but is not universally supported.
• Unsigned parent zones. Some TLDs or registrars don't support DS record publication, breaking the chain before it starts.
• Validation failures. Misconfigured signatures or expired keys cause hard failures, making the domain unreachable for validating resolvers rather than silently degrading. This operational risk discourages adoption.
• Response size. Signed responses are significantly larger (often 4–10x), increasing UDP fragmentation, amplification risk, and bandwidth consumption.

These operational costs explain why many domain operators, including large organizations, still have not deployed DNSSEC. Managed DNS providers like Cloudflare and AWS Route 53 now offer one-click DNSSEC signing, which lowers the barrier but does not eliminate the key management complexity at the registrar level.