DNSSEC: What It Actually Protects You From, and How It Takes Sites Offline
By NorwegianSpark Editorial — written with AI assistance and reviewed by the NorwegianSpark SA editorial team
The short answer
DNSSEC signs DNS answers so a resolver can prove the answer came from the real owner of the zone and was not altered on the way. That is all it does, and it is worth having.
It does not encrypt your DNS queries — that is DNS-over-HTTPS or DNS-over-TLS, a different mechanism solving a different problem. It does not protect you from a denial-of-service attack against your nameservers. And it introduces a failure mode plain DNS does not have: if the signatures expire or the chain of trust breaks, validating resolvers stop answering for your domain entirely. Not degraded. Gone.
That trade is usually worth taking. You should take it knowingly.
The problem DNSSEC solves
DNS was specified without authentication. A resolver asks "what is the address for example.com" and believes whatever comes back first that looks plausible.
That gap is exploitable. Cache poisoning injects a forged answer into a resolver, which then serves it to every user behind it until the record's time-to-live expires. Everyone typing your domain reaches an attacker's server, over a connection their browser considers perfectly normal — the address bar is right, because the address bar was never the thing that lied.
DNSSEC closes it with signatures. Records in a signed zone carry an RRSIG. The key that verifies them is published as a DNSKEY. The hash of that key is published one level up, in the parent zone, as a DS record — so .com vouches for your domain, the root vouches for .com, and a validating resolver can walk that chain to a trust anchor it already holds.
Break any link and validation fails. That is the design: fail closed, not fail quietly.
What DNSSEC does not do
| Threat | Does DNSSEC help? |
|---|---|
| Forged or poisoned DNS answers | Yes — this is the whole purpose |
| Someone reading your DNS queries | No — that is DoH / DoT |
| DDoS against your nameservers | No — that is anycast and capacity |
| Registrar account takeover | No — that is 2FA and registrar lock |
| A lookalike domain | No — different domain, its own valid signatures |
The second row matters more than people expect. DNSSEC proves an answer is *authentic*; it does nothing to keep it *private*. Anyone on the path still sees which domains you looked up.
The failure mode nobody plans for
Signatures have expiry dates. Keys get rolled. The DS record at the parent has to be updated when the key it points at changes.
If that update is missed, or a zone is re-signed with a key the parent does not know about, every validating resolver on the internet begins returning SERVFAIL for your domain. Not "the site is slow" — the name does not resolve at all, for the substantial share of users behind validating resolvers, including the large public ones.
This has taken real organisations offline, and the outages are characteristically confusing because the website, the server and the certificate are all fine. Only the name is gone.
Two rules follow:
- Never move nameservers with DNSSEC enabled. Disable it at the registrar, wait for the DS record to clear the parent zone and for the old TTLs to expire, move, then re-enable. A transfer with a stale DS record pointing at a key the new provider does not hold is the single most common way people break this.
- Prefer automated key management. Providers that support CDS/CDNSKEY (RFC 7344 and RFC 8078) can signal key changes to the parent automatically, so a rollover does not depend on a human remembering. If both your registrar and DNS provider support it, use it.
Turning it on
Where you enable DNSSEC depends on the split between your registrar and your DNS host.
- Registrar and DNS in one place — typically a single toggle. The provider generates keys, signs the zone and publishes the DS record to the registry itself.
- DNS hosted elsewhere — a two-step. The DNS provider signs the zone and hands you a DS record; you paste that into the registrar. Both halves must be done, in that order.
Support varies by registrar and by TLD — the registry for the extension has to accept DS records at all, and a handful still do not. Spaceship and Namecheap both expose DNSSEC controls in the domain panel; check the specific TLD before assuming it is available.
Once enabled, verify externally rather than trusting the panel's green tick. A DNSSEC analyser that walks the chain from the root will show you exactly which link is unsigned, and is the only check worth believing.
Anycast is the other half, and it is not the same thing
DNSSEC makes answers trustworthy. It does nothing to make sure there is an answer at all.
Anycast announces the same IP address from many locations at once, and the network routes each query to the nearest one. Two things follow: queries travel a shorter distance, and a flood aimed at that address is spread across every location rather than landing on one machine.
That is why serious DNS providers run anycast networks and why a single nameserver at a single address is fragile regardless of how well it is signed. The 21 October 2016 attack on Dyn is the reference case — a botnet aimed at one managed DNS provider, and a long list of major sites became unreachable, all of them with perfectly healthy web servers.
If uptime matters, the questions to ask a DNS provider are: how many points of presence, is it anycast, and what is the documented response to a volumetric attack. Signature support is table stakes by comparison.
Should you enable it?
Yes, if your domain carries anything worth impersonating — mail, logins, payments, an audience that trusts the name — and your registrar and DNS provider both support it properly.
Not yet, if you are mid-migration, unsure who controls the zone, or on a provider without automated key management and without anyone whose job it is to notice an expiry. A broken chain is a worse outage than the attack it prevents, and the attack is rarer.
Either way, do the cheaper security work first: two-factor authentication on the registrar account, registrar lock on, and the contact email on a domain that is not the one being protected. How to protect your domain from hijacking covers those, and they stop the attacks that actually happen to small domains.
The honest summary
DNSSEC is authentication for DNS answers. It is a genuine improvement, it is free at most registrars, and its main risk is operational rather than technical: it fails closed, so a missed key rollover is an outage.
Turn it on where the plumbing is automated. Turn it off *before* you move nameservers. And do not mistake it for encryption, for DDoS protection, or for a reason to skip two-factor authentication on the account that controls the domain.
Last updated: