DNSSEC (Domain Name System Security Extensions) is a set of extensions to DNS that adds cryptographic signatures to DNS records, allowing a validating resolver to verify that an answer really comes from the authoritative zone and was not modified in transit. It is defined mainly in RFC 4033, 4034 and 4035 and builds a chain of trust from the DNS root down to individual domain names.
DNSSEC protects data origin authentication and integrity, including proof that a name does not exist. It does not encrypt DNS traffic and does not hide which names are queried; that is the role of separate protocols such as DNS over TLS and DNS over HTTPS.
How DNSSEC signs and validates DNS data
In a signed DNS zone, every set of records with the same name and type, an RRset, receives a digital signature stored in an RRSIG record. The public keys that verify these signatures are published in the zone as DNSKEY records. A resolver that receives an answer can check the RRSIG against the DNSKEY and confirm that the data is intact.
A key alone proves nothing unless the resolver trusts it. DNSSEC therefore links each zone to its parent with a DS (delegation signer) record, a hash of the child zone’s key that is published and signed in the parent zone. Following DS records from the root through the TLD to the domain forms the chain of trust, anchored in the root zone key that validating resolvers are configured to trust.
| Record type | Purpose | Where it lives |
|---|---|---|
| RRSIG | Signature over one RRset | Same zone as the signed data |
| DNSKEY | Public keys used to verify signatures | Apex of the signed zone |
| DS | Hash of the child key, linking zones | Parent zone |
| NSEC | Proves that a name or type does not exist | Signed zone |
| NSEC3 | Hashed proof of non-existence, limits zone walking | Signed zone |
| CDS and CDNSKEY | Signal key changes to the parent for automation | Child zone |
Keys, algorithms and validation results
Most zones use two key roles. The key signing key (KSK) signs only the DNSKEY set and is referenced by the DS record in the parent. The zone signing key (ZSK) signs all other data and can be rolled more often without involving the parent. Some operators use a single combined signing key to simplify operations.
| Algorithm | Number | Characteristics |
|---|---|---|
| RSA/SHA-256 | 8 | Widely supported, larger signatures |
| ECDSA P-256 with SHA-256 | 13 | Small signatures, current common choice |
| Ed25519 | 15 | Small and fast, growing support |
| RSA/SHA-1 | 5 and 7 | Deprecated and should not be used |
A validating resolver classifies each answer as secure, insecure, bogus or indeterminate. Insecure means the zone is simply unsigned and the answer is returned normally. Bogus means validation failed, and the resolver returns SERVFAIL rather than potentially forged data, while secure answers are marked with the AD (authenticated data) flag.
Where DNSSEC fits among DNS components
DNSSEC involves both sides of DNS resolution. Authoritative DNS servers publish signed data, and recursive DNS resolvers perform the validation. The stub resolver on a user’s device usually trusts the recursive resolver’s verdict.
| Component | DNSSEC task | Typical responsible party |
|---|---|---|
| DNS zone owner | Signs the zone and rotates keys | Domain holder or DNS hosting provider |
| Authoritative DNS | Serves records with RRSIG, DNSKEY and NSEC data | DNS hosting provider |
| Parent zone | Publishes the DS record | TLD registry via the registrar |
| Recursive DNS resolver | Validates the chain of trust | ISP, enterprise or public resolver |
| Stub resolver | Usually accepts the resolver result | Operating system |
This split explains a frequent misunderstanding: signing a zone has no effect for users whose resolvers do not validate, while validation helps only for zones that are actually signed with a correct DS record in the parent.
What DNSSEC protects against
DNSSEC was designed against forged DNS answers. The best-known threat is cache poisoning, in which an attacker injects false records into a resolver cache and redirects users to a server under the attacker’s control.
| Threat | Protected by DNSSEC | Note |
|---|---|---|
| Cache poisoning | Yes | Forged records fail validation |
| Tampering on the path | Yes | Modified answers become bogus |
| Fake non-existence answers | Yes | NSEC or NSEC3 proofs are required |
| Eavesdropping on queries | No | Requires encrypted DNS transport |
| Hijacked registrar account | No | Attacker can change keys or DS records |
| DDoS against DNS servers | No | Larger responses can even increase amplification |
DNSSEC also enables other security mechanisms. DANE publishes TLS certificate information in TLSA records, which is meaningful only because DNSSEC makes those records trustworthy.
Operational pitfalls
DNSSEC adds time-dependent state to DNS. Signatures expire, typically after days to a few weeks, and keys must be rotated, so mistakes cause complete resolution failures for validating users rather than subtle errors.
- Expired signatures: if re-signing stops, the zone becomes bogus when RRSIG validity ends.
- Stale DS records: changing DNS providers without updating the DS at the registrar breaks the domain for validating resolvers.
- Rushed key rollovers: removing an old key before cached data expires leaves resolvers unable to validate.
- Large responses: big keys and signatures can exceed UDP limits and trigger fragmentation or TCP fallback.
- Clock errors: resolvers with a wrong system time reject valid signatures.
Managed DNS platforms reduce these risks by automating signing and rollovers, and CDS and CDNSKEY records let supporting registries update the DS record automatically, which removes the most error-prone manual step.
Stripped to the essentials
DNS works like the internet’s address book: it turns a website name into a numeric address. Without protection, someone could slip a false address into that book and send visitors to a fake site.
DNSSEC adds a tamper-evident seal to each entry. The seal is checked against a key vouched for by the level above, all the way up to the top of the system. If a seal is broken, the answer is rejected. It does not hide what people look up; it only proves the answer is genuine.
Where it is applied
A regional bank wants to protect customers against DNS redirection attacks on its online banking domain. Its DNS hosting provider enables automated DNSSEC signing with ECDSA P-256, using a KSK and a ZSK, and the bank adds the resulting DS record at its registrar.
Before going live, the team verifies the chain of trust with validation testing tools and confirms that resolvers mark answers with the AD flag. They also document a rule that any change of DNS provider must include a coordinated DS update, to avoid a self-inflicted outage.
Customers whose ISPs validate DNSSEC are now protected against forged DNS answers for the banking domain. The bank later publishes TLSA records for its mail servers, using DNSSEC as the trust foundation for authenticated, encrypted email delivery.