What is DNSSEC?
DNSSEC (Domain Name System Security Extensions) adds digital signatures to DNS record sets. A validating resolver can use valid signatures and a chain of trust to authenticate signed data and detect unauthorized changes. DNSSEC does not encrypt DNS queries or responses.How DNSSEC Works
Chain of Trust (split-key example):
Root Zone (.)
├── Root KSK (trust anchor) signs root DNSKEY RRset
└── Root ZSK signs authoritative root RRsets, including the parent-side DS RRset for .com
└── DS digest matches .com KSK
├── .com KSK signs .com DNSKEY RRset
└── .com ZSK signs authoritative .com RRsets, including the parent-side DS RRset for example.com
└── DS digest matches example.com KSK
├── example.com KSK signs example.com DNSKEY RRset
└── example.com ZSK signs authoritative example.com RRsets
Resolver validates signatures and DS digests from the root trust anchor
DNSSEC Record Types
| Record | Purpose | Description |
|---|---|---|
| RRSIG | Signature | Cryptographic signature for each record set |
| DNSKEY | Public Key | Zone's public signing keys (KSK and ZSK) |
| DS | Delegation Signer | Hash of child zone's KSK in parent zone |
| NSEC/NSEC3 | Authenticated Denial | Proves a record doesn't exist |
Key Types
| Key | Purpose | Rotation Frequency |
|---|---|---|
| KSK (Key Signing Key) | Signs DNSKEY records | Policy-dependent; see note below |
| ZSK (Zone Signing Key) | Signs other authoritative RRsets; parent-side delegation NS and glue RRsets are unsigned ([RFC 4035 §2.2](https://www.rfc-editor.org/rfc/rfc4035.html#section-2.2)) | Policy-dependent; see note below |
Rotation timing depends on the KSK's role and the operator's policy. For a KSK linked by a DS record in its parent zone, [RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) describes one year as a reasonable interval when regular rollover is chosen. A KSK used as a trust anchor needs coordination with validating resolvers and may have a much longer effectivity period ([RFC 6781 §3.2.2](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.2.2)).
ZSK rollover timing depends on DNSKEY and signature TTLs, zone propagation, and how long signatures made with a retiring key can remain in resolver caches ([RFC 7583 §3.2.1](https://www.rfc-editor.org/rfc/rfc7583.html#section-3.2.1)). For an online ZSK with fairly high exposure to compromise, [RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) describes a one-month intended lifetime as reasonable; this is conditional guidance, not a universal rotation interval.
11 October 2026 Root KSK Rollover
ICANN lists the root zone KSK rollover for 11 October 2026. Confirm your validating resolver has KSK-2024 (key tag 38696) loaded as a trust anchor; automatic update mechanisms may not have succeeded. If it is absent, check that automatic updates are turned on and apply your resolver vendor's instructions. See [ICANN's root KSK rollover guidance](https://www.icann.org/resources/pages/ksk-rollover-en) for current details.
DNSSEC Validation Process
1. Client queries DNS resolver for example.com A record
2. Resolver retrieves A record + RRSIG signature
3. Resolver fetches DNSKEY to verify RRSIG
4. Resolver validates DS record against DNSKEY
5. Chain continues to root, verifying each level
6. If all signatures valid, response is authenticated
What DNSSEC Validation Can Help Detect
These checks require signed RRsets and a validating resolver with an intact chain of trust. Unsigned or insecure data cannot be authenticated.
| Threat | Example | DNSSEC protection |
|---|---|---|
| Cache poisoning | Forged DNS data inserted into a resolver cache | A validating resolver can reject data that fails signature or chain validation. |
| Response tampering | A signed DNS record set is changed in transit | The changed data fails signature verification. |
| DNS spoofing | A forged answer is supplied for a signed zone | A validating resolver can reject an answer that fails validation. |
Implementation Considerations
- Performance: Larger responses due to signatures (~1000-4000 bytes vs ~100 bytes)
- Key management: Requires secure key generation, storage, and rotation
- Zone signing: Must re-sign zone when records change
- Resolver support: Clients need DNSSEC-validating resolvers
Best Practices
1. Choose a DNSSEC signing algorithm: The [IANA DNSSEC algorithm registry](https://www.iana.org/assignments/dns-sec-alg-numbers) recommends ECDSAP256SHA256 (algorithm 13) for signing and validation. ECDSAP384SHA384 (14) may suit applications needing 192-bit strength; check resolver support before changing algorithms ([RFC 9904](https://www.rfc-editor.org/rfc/rfc9904.html), [RFC 8624 §3.1](https://www.rfc-editor.org/rfc/rfc8624.html#section-3.1)).
2. Automate key rotation: Use tools like OpenDNSSEC for key lifecycle
3. Monitor expiration: RRSIG signatures have validity periods
4. Test before deployment: Validate zone with tools like dnsviz.net
5. Plan for emergencies: Have key rollover procedures documented
When a validating resolver verifies the chain, DNSSEC authenticates the origin and integrity of signed DNS data. It does not establish that a website or server at a returned address is trustworthy.