DNSSEC
DNS Security Extensions add cryptographic signatures to DNS responses so resolvers can verify that the answers come from the rightful owner of the zone.
The problem DNSSEC solves
Plain DNS is unauthenticated. An attacker who can intercept or inject UDP traffic — a malicious resolver, a hostile network, a cache-poisoning attack — can hand a client whatever address they like and the client has no way to detect it. DNSSEC closes that gap by signing records cryptographically; the resolver verifies signatures against a chain of trust anchored at the root zone.
The four core record types
| Record | Role |
|---|---|
DNSKEY | The zone's public key(s). Used to verify signatures inside the zone. |
RRSIG | Cryptographic signature over an RRset, made with the zone's private key. |
DS | Delegation Signer — a hash of the child zone's DNSKEY, placed in the parent zone. This is the link in the chain of trust. |
NSEC / NSEC3 | Proves authenticated denial of existence — "this name doesn't exist, and I can prove it." |
The chain of trust
A validating resolver builds trust like this:
- Start at the root, whose key (the "trust anchor") is pre-configured.
- Resolve a TLD's
DSrecord in the root and verify the root's signature over it. - Resolve the TLD's
DNSKEYand verify it hashes to theDS. - Repeat down the tree: each parent zone signs a
DSover the child'sDNSKEY. - Finally, the leaf zone's records carry
RRSIGs that can be verified against itsDNSKEY.
What DNSSEC does not do
- Encrypt DNS traffic. That's the job of DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH).
- Authenticate the resolver. A malicious recursive resolver can still strip DNSSEC and lie — clients need a validating stub resolver to be safe end-to-end.
- Protect against DDoS or amplification. Larger DNSSEC responses can actually make amplification attacks worse.