DNSSEC explained — what it is and whether you need it
// published 2026-04-17
DNSSEC adds cryptographic signatures to DNS responses so you can verify that the answer wasn't tampered with in transit. It's been "the future of DNS" for 20 years and is still under-adopted. Here's what it actually protects, what it doesn't, and whether you should turn it on for your domain.
What DNS without DNSSEC is vulnerable to
Unsigned DNS is plaintext UDP. A network attacker who can see your queries can also forge replies. The classic attack is cache poisoning: attacker races the legitimate response, gets the recursive resolver to cache a malicious one, all subsequent users of that resolver get the poisoned record.
If the poisoned record is for your-bank.com, users get directed to the attacker's IP, which serves a perfect HTTPS phishing site (with a valid cert from a CA that does DNS-based domain validation — a separate problem DNSSEC also helps with).
What DNSSEC does
Each DNS record gets a cryptographic signature (RRSIG). Each signature is verifiable using a public key (DNSKEY) for the zone. The zone's DNSKEY is itself signed — by a hash (DS record) published in the parent zone. The parent's DS is signed by its parent. The chain ends at the root zone, whose key is hard-coded into resolvers.
Verifying resolver checks the chain top-down. If any signature is missing, expired, or invalid, the answer is rejected entirely. No silent tampering.
Run the DNSSEC Checker on a domain to see whether it has DNSKEY (zone signed) and DS (delegation signed by parent).
What DNSSEC does NOT do
- It doesn't encrypt. An observer can still see your queries. For privacy, you need DoH or DoT (DNS-over-HTTPS / DNS-over-TLS).
- It doesn't protect the last mile. If your local resolver does DNSSEC validation but the connection between you and that resolver isn't authenticated, an attacker on your network can still inject results before they reach the validator.
- It doesn't replace TLS. Plenty of attacks happen above DNS. TLS protects the connection content; DNSSEC protects the lookup that finds the server.
- It doesn't catch all attacks. Active downgrade (BGP hijack of the recursive resolver itself) can still work, though much harder.
The trade-offs
Pro
- Protects against cache poisoning at the resolver level.
- Required for some advanced features: DANE (TLS cert pinning via DNS), SSHFP (SSH fingerprints), various certificate-issuance verifications.
- Some governments and gTLD operators prefer signed zones.
Con
- Operational risk: a misconfiguration (expired RRSIG, mismatched DNSKEY rotation, DS not updated at parent) makes your domain disappear from DNSSEC-validating resolvers. Validating resolvers refuse partial answers.
- Increased query size: signed responses are larger, sometimes triggering UDP truncation and TCP fallback. Slower.
- Zone-walking: NSEC records (used for "this name doesn't exist" proofs) used to expose all hostnames in the zone. Mitigated by NSEC3 but still concerning if your zone has secret hostnames.
- Key rotation discipline required. KSK rollover needs DS updates at parent in time. Missed rollover = outage.
Should you enable it?
For most websites: probably not yet. The operational risk is real and the threat model is narrow (most attacks happen elsewhere). Wait until your DNS is hosted on a provider with reliable automated DNSSEC (Cloudflare, Route53, AWS — they handle key rotation for you).
For high-value targets (banks, governments, infrastructure providers, anything where DNS hijack = catastrophe): yes, enable it. The risk of cache poisoning outweighs the operational complexity, especially with a managed provider.
Safe deployment checklist
- Use a managed DNS provider with full DNSSEC support (Cloudflare, Route53, Google Cloud DNS, NS1).
- Enable signing at the provider — usually one toggle.
- Get the DS record from the provider.
- Submit DS to your registrar. The registrar publishes it at the parent zone.
- Wait for parent propagation (1-2 days for most TLDs).
- Verify with the DNSSEC Checker — both DNSKEY and DS should appear.
- Set monitoring. RRSIG expiry should never sneak up on you.
For a reference of what a fully-signed zone looks like, check /d/cloudflare.com — DNSKEY present at the zone, DS record signed by the parent, clean chain. Compare against your own: /d/yourdomain.com.