security

DNSSEC

How cryptographic signatures protect DNS from forgery

Imagine you call directory assistance for your bank’s phone number. You dial the number they give you, someone answers, and they ask for your account details. How do you know you reached the bank? You trusted the directory service. Now imagine anyone along the way could substitute a different number, undetectably.

That is DNS without DNSSEC. Your computer asks “what is the IP address of mybank.com?” and accepts whatever answer arrives first, with no way to verify authenticity. Cache poisoning, spoofing, and hijacking all exploit this blind trust. DNSSEC was designed to fix it.

What DNSSEC Solves (and What It Does Not)

DNSSEC adds cryptographic signatures to DNS records. A validating resolver can verify two things:

Data integrity — the records have not been modified in transit.
Origin authentication — the records genuinely come from the authoritative source for that zone.

DNSSEC does not encrypt DNS traffic. Your queries and their responses are still visible to anyone on the network path. For confidentiality, you need encrypted DNS protocols like DoH or DoT. DNSSEC solves forgery; encrypted DNS solves surveillance. They are complementary, not interchangeable.

The Chain of Trust

DNSSEC’s core concept is a hierarchical chain of cryptographic trust that mirrors the DNS hierarchy itself.

Root Zone (.)            Trust anchor (KSK hardcoded in resolvers)
  │
  ├── .com               Signed by root, contains DS for child zones
  │     │
  │     └── example.com  Signed by .com, contains DS for any subzones
  │
  ├── .org               Signed by root
  │
  └── .nl                Signed by root

Each zone in the hierarchy vouches for the zones below it:

The root zone is the ultimate trust anchor. Its Key Signing Key (KSK) is hardcoded into every validating resolver in the world.
The root zone publishes DS (Delegation Signer) records for each TLD — .com, .org, .net, and so on.
Each TLD publishes DS records for the second-level domains beneath it.
This chain continues downward. At every link, the parent zone’s signature guarantees the child zone’s public key.

If any link in the chain is missing or broken, validation fails and the resolver rejects the response. This is what makes DNSSEC effective — and operationally demanding.

Key Types: KSK and ZSK

DNSSEC uses two types of cryptographic key pairs per zone:

Key	Full Name	Purpose	Rollover Frequency
ZSK	Zone Signing Key	Signs the actual DNS records (A, AAAA, MX, etc.) in the zone	Every few months
KSK	Key Signing Key	Signs the DNSKEY record set (which contains the ZSK)	Annually or less

Why two keys? The ZSK signs every record set and must be rolled frequently. But changing it only requires updating the zone’s own DNSKEY record. The KSK is linked to the parent zone through a DS record — rolling it requires coordinating with the parent (e.g., updating the DS in .com), which is slower and riskier. Separating the two allows routine ZSK rollovers without touching the parent zone.

DNSSEC Record Types

DNSSEC introduces four new DNS record types:

RRSIG (Resource Record Signature)

Every record set in a signed zone gets an RRSIG containing its digital signature. The resolver uses the zone’s public key (from DNSKEY) to verify it.

example.com.  86400  IN  A      93.184.216.34
example.com.  86400  IN  RRSIG  A 13 2 86400 (
                20260315000000 20260213000000 12345 example.com.
                oL2k8Wd3FQ7+h5... )

DNSKEY (DNS Public Key)

Contains the zone’s public keys (both KSK and ZSK). Resolvers use these to verify RRSIG signatures.

example.com.  86400  IN  DNSKEY  257 3 13 (
                mdsswUyr3DPW... )   ; KSK (flag 257)
example.com.  86400  IN  DNSKEY  256 3 13 (
                DaYP8bQL3mIp... )   ; ZSK (flag 256)

DS (Delegation Signer)

Published in the parent zone, the DS record contains a hash of the child zone’s KSK. This is the link in the chain — how .com vouches for example.com.

; In the .com zone:
example.com.  86400  IN  DS  12345 13 2 (
                49FD46E6C4B4... )

NSEC and NSEC3 (Authenticated Denial of Existence)

How do you prove that a domain does not exist? Without DNSSEC, an attacker could forge NXDOMAIN responses to block access to legitimate sites. NSEC and NSEC3 records provide cryptographically signed proof that no record exists for the queried name.

NSEC lists the “next” name in alphabetical order. If you query b.example.com and the zone has a and c, NSEC says “next after a is c” — proving b does not exist. The downside: attackers can “walk” the chain to enumerate every record in the zone.

NSEC3 (RFC 5155) hashes domain names before sorting, revealing hashes instead of actual names. It also supports opt-out for unsigned delegations — critical for .com where most domains are not DNSSEC-signed.

How Validation Works: Step by Step

When a validating resolver receives a query for www.example.com:

Receive signed records. The resolver gets the A record, its RRSIG, and DNSKEY records for example.com.
Verify the record signature. Use the ZSK from DNSKEY to verify the RRSIG over the A record.
Verify the ZSK using the KSK. Confirm the DNSKEY record set is signed by the KSK.
Verify the KSK using the parent’s DS record. The DS in .com contains a hash of example.com’s KSK. If it matches, continue upward.
Repeat up the hierarchy. Verify .com using the root zone’s DS record.
Trust anchor. The chain terminates at the root KSK, hardcoded into the resolver. If every link validates, the response is authenticated. If any fails, it is bogus and discarded.

Root KSK (trust anchor, hardcoded)
  │ signs
  ├── Root DNSKEY (ZSK)
  │     │ signs
  │     ├── .com DS record (hash of .com KSK)
  │     │     │ matches
  │     │     └── .com KSK
  │     │           │ signs
  │     │           └── .com DNSKEY (ZSK)
  │     │                 │ signs
  │     │                 └── example.com DS record
  │     │                       │ matches
  │     │                       └── example.com KSK
  │     │                             │ signs
  │     │                             └── example.com DNSKEY (ZSK)
  │     │                                   │ signs
  │     │                                   └── www.example.com A RRSIG ✓

The Root KSK Rollover

The root zone’s KSK is the most important cryptographic key on the internet. Its first-ever rollover was a landmark event:

Date	Event
July 2010	Root zone signed with DNSSEC for the first time
July 11, 2017	New KSK (KSK-2017, key tag 20326) published alongside original KSK-2010
October 11, 2017	Planned rollover postponed — data showed too many resolvers were not ready
October 11, 2018	Rollover completed. KSK-2017 began signing the root DNSKEY set
January 11, 2019	Old KSK-2010 removed from the root zone

The one-year delay underscores the risk: if resolvers had not updated their trust anchors, they would reject every DNS response as bogus. Root key ceremonies occur quarterly, with new signatures published approximately every 10 days.

Adoption: Where We Stand

DNSSEC adoption varies dramatically by region and by TLD. The global picture as of 2025:

Validation (Resolver Side)

Country / Region	DNSSEC Validation Rate
Sweden	>85%
Nordic countries (aggregate)	>80%
Netherlands	~60%
EU average	~49.4%
Global average	~35.4%

Signing (Domain Side)

TLD	DNSSEC Signing Rate	Notes
.nl (Netherlands)	>50%	Highest major ccTLD adoption
.se (Sweden)	>50%	Early adopter with incentive programs
.cz (Czech Republic)	>50%	High registrant adoption
.no (Norway)	>50%	Nordic leadership
.net	~5.3%	Low despite being a major gTLD
.com	~4—5%	Largest TLD, lowest adoption
.gov (US)	~20%	Lags despite government mandates

The contrast: over 50% of .nl domains are signed versus ~5% of .com. At the ccTLD level, 78 of ~160 ccTLDs (48%) have operational DNSSEC.

Why Adoption Is Slow

Standardized in 2005 (RFCs 4033, 4034, 4035) and available for over two decades, DNSSEC remains far from universal.

Operational Complexity

Every zone change requires re-signing. KSK rollovers require coordinating DS record updates with the parent zone — multi-step processes where a mistake takes the domain offline. Key rollover failures are the most common cause of DNSSEC-related outages.

Increased Resource Usage

DNSSEC-signed zones are larger (RRSIG, DNSKEY, NSEC/NSEC3 records) and cryptographic operations consume CPU on both servers and resolvers. Signed responses can exceed the 512-byte UDP limit, triggering TCP fallback.

The Bootstrap Problem

A signed domain is only protected if the resolver validates, and a validating resolver only helps if queried domains are signed. With ~5% of .com signed, individual incentives remain low — a chicken-and-egg problem that has persisted for years.

No Confidentiality

DNSSEC provides integrity, not encryption. Some argue HTTPS makes it redundant, but HTTPS protects the connection after DNS resolution — it cannot prevent an attacker from redirecting the query itself.

DNSSEC Failures and Gotchas

DNSSEC’s complexity creates its own failure modes.

Signature Expiration

RRSIG records have expiration timestamps. If a zone operator fails to re-sign before expiration, validation fails and the domain goes offline — even though the underlying records are correct.

DS Record Mismatch

During a KSK rollover, the DS record in the parent must match the new KSK. Wrong timing — removing the old DS before the new KSK propagates, or publishing the new DS too early — breaks the chain of trust.

KeyTrap (CVE-2023-50387)

Disclosed on February 13, 2024, KeyTrap demonstrated that DNSSEC’s complexity can itself become a weapon. Researchers at the ATHENE National Research Center discovered that crafted DNSSEC-signed zones with numerous DNSKEY and RRSIG records could cause extreme CPU consumption on validating resolvers. A single malicious DNS packet could exhaust a resolver’s processing capacity.

The vulnerability affected BIND 9.0.0—9.16.46, 9.18.0—9.18.22, and 9.19.0—9.19.20, with a CVSS score of 7.5. Researchers estimated it potentially exposed one-third of DNS servers worldwide, impacting over 1 billion users. A related vulnerability, CVE-2023-50868 (NSEC3 closest encloser), was disclosed alongside it.

Algorithm Rollover

Transitioning from RSA (algorithm 8) to ECDSA (algorithm 13) or EdDSA (algorithm 15) requires publishing dual signatures during the transition. An incomplete rollover leaves some resolvers unable to validate.

Verifying DNSSEC Yourself

You can inspect DNSSEC records with dig:

# Check if a domain is signed
dig +dnssec example.com A

# View DNSKEY records
dig example.com DNSKEY +short

# View DS record in parent zone
dig example.com DS +short

Look for the ad (Authenticated Data) flag in the response header:

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
                   ^^
                   Authenticated Data flag

If present, the resolver validated the full DNSSEC chain successfully.

The Path Forward

DNSSEC is imperfect — complex to deploy, operationally risky, and offering no confidentiality. KeyTrap showed its own validation logic can be weaponized. Adoption is uneven: over 85% validation in Sweden, under 5% domain signing in .com.

Yet it remains essential. DNSSEC is the only widely deployed standard preventing DNS forgery at the protocol level. Encrypted DNS protocols (DoH, DoT, DoQ) protect confidentiality but not integrity — they secure the channel without verifying the answer. The strongest posture combines both: DNSSEC for authenticity, encrypted transport for privacy. The chain of trust is only as strong as its weakest link.

Related Resources

Threats Overview

Record Types