DNSSEC Explained, and Whether You Actually Need It
DNSSEC signs DNS answers so a resolver can prove they were not tampered with. Roughly one domain in twenty uses it. Here is what it protects against, what it costs you, and the failure mode that keeps adoption low.
September 21, 20267 min readDNSSEC · DNS · Security
The short answer. DNS was designed without authentication, so a resolver cannot normally tell a genuine answer from a forged one. DNSSEC adds cryptographic signatures that prove an answer came from the real zone. If your DNS provider offers it as a single switch, turn it on. If it requires manually moving keys between systems, understand the failure mode first, because a broken DNSSEC setup takes your domain offline for part of the internet.
The problem DNSSEC solves
When your computer asks where example.com lives, it gets back an IP address. Classic DNS has no way to verify that answer came from the domain's real nameservers.
That gap enables cache poisoning: an attacker feeds a resolver a forged answer, and the resolver caches it and serves it to everyone using it. Users type the right domain and reach the wrong server, with no certificate warning and nothing visibly wrong.
DNSSEC closes that gap by signing records. Each zone signs its records with a private key, publishes the public key, and the parent zone vouches for that key. The result is a chain of trust from the DNS root down to your domain.
A validating resolver checks the chain. If a signature does not verify, it returns an error instead of the answer. That last part is the whole design, and also the whole risk.
What DNSSEC does not do
This is where most explanations mislead by omission.
It does not encrypt anything. DNSSEC provides authenticity and integrity, not confidentiality. Your queries remain visible. Encryption is a separate problem solved by DNS over HTTPS or DNS over TLS.
It does not protect a compromised registrar account. If someone takes over your registrar login and changes the nameservers legitimately, they can re-sign the zone with their own keys. DNSSEC proves answers came from whoever controls the zone, not that the right person controls it.
It does not stop phishing from lookalike domains. A typosquatted domain can have perfectly valid DNSSEC. It is signed, it is just not yours.
It is not HTTPS. They solve different problems at different layers and neither substitutes for the other.
Why adoption is still low
Measured by signed domains, DNSSEC adoption sits at roughly 4 to 5 percent of second-level domains, depending on the sample and the measurement method. The Internet Society and APNIC both track this, and the picture has moved slowly for years.
Enterprise numbers are not much better. CSC's Domain Security Report 2026 puts DNSSEC among the eight controls that most of the Global 2000 have not implemented, with adoption in the low teens.
The reason is not ignorance. It is that DNSSEC's failure mode is an outage.
A misconfigured certificate produces a warning the user can click through. A misconfigured DNSSEC setup produces NXDOMAIN. Your domain does not appear broken, it appears not to exist, and only for users whose resolver validates.
That asymmetry explains everything about adoption. The benefit is protection against an attack most domains never experience. The cost is a class of outage that is confusing to diagnose, because the site works fine from your machine and not from your customer's.
Measurement work also shows the single strongest predictor of whether a domain is signed is simply whether its DNS provider does it automatically. Adoption is an infrastructure default, not a security decision.
The ways it breaks
Key rollover gone wrong. Keys are rotated. If the DS record at the registry is not updated to match the new key in time, validation fails for everyone.
Changing DNS provider without unsigning. The classic disaster. You move DNS to a new provider, the old keys no longer apply, the DS record at the registrar still points at them, and the domain goes dark for validating resolvers while working perfectly from any resolver that does not validate. Always unsign before migrating, then re-sign afterwards.
Registrar and DNS provider out of sync. DNSSEC requires the DS record at the registrar to match the key at the DNS host. When those are two different companies, somebody has to keep them aligned manually.
Expired signatures. Signatures have validity periods. Automation that stops running produces a domain that works until a specific timestamp and then does not.
Should you enable it?
Yes, if your DNS provider and registrar are the same company, or your provider offers one-click DNSSEC that manages the DS record for you. The risk is then carried by someone who does this at scale, and there is no real reason not to.
Yes, if you are a bank, a government service, a healthcare provider or anything where cache poisoning would be catastrophic. Also if you operate under regulatory frameworks that expect it, which increasingly includes EU entities under NIS2.
Think harder, if your registrar and DNS provider are different companies and you would be moving DS records by hand. The honest question is whether the person who does that will still be there at the next key rollover.
Probably not yet, if you have no monitoring. DNSSEC failures are invisible from an unvalidating resolver, which means you can be down for a fraction of the internet for days without knowing. If you turn it on, monitor it.
If you do enable it
- Turn it on at the DNS provider and let it publish the DS record if it can
- Verify the chain validates from an external validating resolver, not just your own machine
- Add DNSSEC state to whatever monitors your domain, so a break is an alert rather than a support ticket
- Before any DNS migration, unsign first, wait for TTLs, migrate, then re-sign
Our Domain Hub tracks authoritative DNS consistency and raises an event when a domain's DNS stops resolving as expected, which is the category of failure a broken DNSSEC chain produces.
Common questions
What does DNSSEC actually protect against?
DNS cache poisoning and forged DNS answers. It lets a resolver cryptographically verify that a DNS response came from the zone that should have produced it, and has not been altered in transit.
Does DNSSEC encrypt my DNS queries?
No. DNSSEC provides authentication and integrity only. Queries stay visible to anyone on the path. Encryption requires DNS over HTTPS or DNS over TLS, which are separate technologies.
Is DNSSEC worth enabling?
If your provider offers it as a managed one-click option, yes. If it requires manually synchronising DS records between a separate registrar and DNS host, weigh it against the outage risk and your ability to monitor it.
What happens if DNSSEC is misconfigured?
Validating resolvers refuse to return an answer, so your domain becomes unreachable for their users while continuing to work normally for everyone else. It is a partial, confusing outage that is easy to misdiagnose.
How many domains use DNSSEC?
Around 4 to 5 percent of second-level domains are signed, depending on the measurement. Actual end-to-end validation covers a much smaller share of queries, since both the domain and the user's resolver must support it.
Do I need DNSSEC if I have HTTPS?
They protect different things. HTTPS secures the connection after your browser has found the server. DNSSEC helps ensure it found the right server in the first place.
Put the research to work.
Check your shortlist across the extensions that matter, then save the strongest names to a project.
Check a domain