What Is DNSSEC and How Does It Protect DNS Answers?

DNSSEC (Domain Name System Security Extensions) is a set of DNS protocol extensions that cryptographically sign DNS data so a resolver can verify that an answer is authentic and unmodified. It protects integrity and authenticity, not confidentiality: queries and answers still travel in cleartext unless a separate protocol such as DoT or DoH encrypts the transport. You need DNSSEC if you want to prevent forged or tampered DNS answers from being accepted; you do not need it to hide which names are being queried.

What DNSSEC actually guarantees

A validating resolver checks two things about a signed answer:

• Authenticity — the answer came from the zone that is authoritative for the name.
• Integrity — the answer was not altered in transit or in a cache.

It does not provide:

• Encryption of queries or responses.
• Hiding of domain names (the query name is still visible on the wire).
• Protection against a compromised authoritative server that signs bad data with its own valid key.

The chain of trust

DNSSEC works as a hierarchy of signatures anchored at the DNS root.

1. The root zone is signed, and its public key (the trust anchor) is distributed with validating software.
2. Each signed child zone publishes a DS record in its parent, which commits to the child's key.
3. The child zone publishes its public key as a DNSKEY and signs its records with the matching private key.
4. A validator walks from the root down, verifying each DS/DNSKEY link, until it can validate the answer for the name it was asked about.

If any link is missing or invalid, the validator treats the data as bogus and returns a failure (typically SERVFAIL) rather than accepting it.

Signing vs. validation: two separate jobs

DNSSEC requires action on both sides, and they are independent.

A zone can be signed without your resolver validating, and a resolver can validate without the zones you query being signed. For end-to-end protection, both must be in place.

Common failure modes

• Expired signatures — RRSIG records have validity windows; if re-signing fails, validating resolvers reject the zone.
• Broken delegation — a DS record at the parent that does not match the child's DNSKEY makes the whole subtree bogus.
• Missing DS — a signed child with no DS at the parent is treated as unsigned, so validation silently does not apply.
• Clock skew — validators with wrong time may reject valid signatures.
• Algorithm mismatch — parent DS and child DNSKEY must use compatible algorithms.

Diagnosis usually starts by querying with a validating resolver and checking whether the response is secure, insecure, or bogus, then inspecting DS, DNSKEY, and RRSIG records along the delegation path.

Tooling and implementations

DNSSEC is implemented across many open-source and commercial systems. NLnet Labs, a nonprofit foundation focused on DNS and routing, maintains several relevant components:

• Cascade — described as a purpose-built DNSSEC signing solution.
• NSD — a fast, robust authoritative DNS nameserver.
• Unbound — a lean, versatile recursive DNS resolver (validation happens on the resolver side).
• Krill — RPKI Certificate Authority software (routing security, not DNSSEC).
• Routinator — RPKI Relying Party software.

For a zone owner, the practical path is: choose a signer (such as Cascade or another DNSSEC-capable authoritative server), publish the DS record at your registrar or parent zone, and confirm that a public validating resolver returns validated answers. For a resolver operator, enable validation in software such as Unbound and verify the root trust anchor is current.

Deciding whether to enable it

Enable DNSSEC if you want to reduce the risk of cache poisoning and forged answers reaching your users, and you can commit to key management and timely re-signing. Skip it only if you have a specific reason — for example, an internal-only zone where validation is not enforced end to end — and understand that unsigned zones gain no integrity protection.