What is DNSSEC and do I need it?
What DNSSEC protects against, what it does not, and an honest account of when it is worth the operational risk.
DNSSEC cryptographically signs DNS answers so a resolver can detect forged ones. It protects against DNS spoofing and cache poisoning. It does not encrypt anything, does not protect the connection, and adds a failure mode where a mistake takes your entire domain offline. Worth enabling for high-value domains with automated key management; genuinely optional otherwise.
The problem it solves
Plain DNS answers are unauthenticated. A resolver asks where example.com lives and believes whatever comes back. An attacker positioned to answer first — or to poison a cache — can send visitors to an address they control, and nothing in the protocol notices.
DNSSEC adds signatures. Each record set is signed, the signing keys are themselves signed by the parent zone, and the chain runs up to the root. A validating resolver can verify that chain and reject answers that do not check out.
What it does not do
This is where most of the confusion lives, and the misconceptions matter because they lead people to skip things DNSSEC does not replace.
- It does not encrypt DNS. Queries remain visible to anyone on the path. That is what DNS over HTTPS and DNS over TLS are for, and they are unrelated mechanisms.
- It does not protect the connection. Once you have the right address, TLS does the work. DNSSEC and HTTPS solve different problems at different layers.
- It does not prevent domain hijacking at the registrar. Someone who takes over your registrar account can disable DNSSEC as easily as they can change your nameservers. Registrar lock and strong account security matter more.
- It does not stop phishing. A lookalike domain has its own valid DNSSEC.
The real cost: a new way to go completely offline
This is the honest trade-off and it deserves to be stated plainly. Without DNSSEC, a DNS mistake usually degrades something. With DNSSEC, a signing mistake makes your domain fail validation, and validating resolvers then refuse to resolve it at all. Not slow. Not partially broken. Gone, for everyone behind a validating resolver.
- Expired signatures. Signatures have their own validity windows and must be refreshed on schedule. Miss it and the zone fails.
- Key rollover errors. Rotating keys without updating the parent DS record breaks the chain.
- Provider migration. Moving DNS hosts with DNSSEC enabled requires careful coordination. Done carelessly, the domain disappears mid-migration.
Large, well-run organisations have taken themselves offline this way. The mechanism is sound; the operations are unforgiving.
When it is clearly worth it
| Situation | Verdict |
|---|---|
| Financial services, healthcare, government | Yes — often required, and the threat is real |
| A domain used for authentication or email at scale | Yes — spoofing has outsized consequences |
| Provider offers fully automated signing and rollover | Reasonable — the operational risk is largely absorbed |
| Small business site, manual DNS management | Optional — spend the effort on registrar security and DMARC first |
| Frequent DNS provider migrations | Be cautious — this is where outages happen |
Checking whether it is on
dig +dnssec +short example.com # RRSIG records present means signing
dig DS example.com @1.1.1.1 # the parent's delegation signer recordA signed zone with no DS record at the parent is the worst of both worlds: the operational risk without the protection, because nothing anchors your signatures to the chain of trust.
What to do first instead
For most domains, three things reduce more real risk than DNSSEC, at lower operational cost: enable registrar lock, secure the registrar account with strong multi-factor authentication, and get DMARC to an enforcing policy. Domain takeover at the registrar is a far more common attack than DNS spoofing, and DNSSEC does nothing about it.
What our audit reports about this
Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.
- Whether DNSSEC records are present in the zone. Full chain validation is reported as untested, with the reason.
- Registrar-adjacent hygiene that matters more for most domains: CAA records, SPF, DMARC policy strength.
- Nameserver configuration and whether the zone being served matches the delegation.
- A clear statement of which DNS properties are measured and which are declared out of scope, rather than a silent gap.
For agents and scripts, the same measurement is at
/api/v1/dns?url=yoursite.com —
see the API documentation.
Related questions
Does DNSSEC make my site faster?
No, marginally the opposite. Signed responses are larger and validation adds a small amount of work at the resolver. The effect is not usually noticeable, but it is not a performance feature.
Will DNSSEC help my SEO?
No. There is no evidence any search engine uses it as a ranking signal, and it is not visible to a crawler in any case.
What happens if my signatures expire?
Validating resolvers refuse to resolve your domain at all. Not a warning, not degraded service — the domain does not resolve for a large share of the internet until it is fixed. This is the main reason to insist on automated signing.
Why does Outrings not validate the chain?
Because validating a DNSSEC chain properly requires a validating resolver and trust-anchor handling that shared hosting cannot honestly guarantee. Rather than report an unreliable verdict, it is declared as not measured, with the reason.
Read next
What do my DNS records actually say?
Reading your own DNS from first principles — which records exist, what each one decides, and the four commands that show you all of them.
ReadWhat is a CAA record and do I need one?
A DNS record naming which certificate authorities may issue certificates for your domain. One line, and it closes a real gap.
ReadHow do I stop people sending email that looks like it came from my domain?
Three DNS records. Without them anyone can forge your address, including to your own customers — and this applies even if you never send email.
ReadWhat are SPF, DKIM and DMARC?
Three DNS records that together decide whether your email arrives and whether anyone can forge it. What each one does, in plain terms.
Read