DNSSEC adds cryptographic signatures to your DNS records so resolvers can verify a response actually came from your nameservers and wasn't tampered with in transit. For most sites, the honest answer is: you don't need it. It protects against a specific, fairly rare attack (DNS spoofing and cache poisoning), and it adds a failure mode of its own: get it misconfigured and your domain can stop resolving entirely, for everyone. Read the rest before you turn it on.
What DNSSEC actually signs
Normal DNS has no authentication built in. When a resolver asks "what's the A record for yourdomain.com" and gets an answer, it has no way to confirm that answer really came from your nameservers and wasn't injected by something sitting in the middle of the lookup. DNSSEC closes that gap by attaching a digital signature to each set of DNS records, so a resolver can cryptographically verify the answer is authentic and unmodified before it hands it to your browser.
It does this with a few new record types layered on top of your existing zone:
- RRSIG: the signature itself, generated for each record set.
- DNSKEY: the public key resolvers use to verify signatures, published in your zone.
- DS: a hash of your DNSKEY, published at your registrar/TLD, one level up the chain.
- NSEC / NSEC3: signed proof that a record doesn't exist, so an attacker can't fake a "no such record" response either.
Put together, these let a validating resolver walk a chain of trust from the DNS root down to your specific domain, checking a signature at every hop.
The validation chain, and why the DS record matters
DNSSEC only works end to end. Your nameservers sign your zone, but that signature is only trustworthy if something above you vouches for your public key. That's what the DS record does: it lives at the registry for your TLD (the layer that already knows who your nameservers are), and it's a hash of your DNSKEY. A validating resolver checks the root's signature, then the TLD's signature, then follows the DS record down to your DNSKEY, then verifies your record signatures against that key.
If any link in that chain is missing or wrong, one of two things happens depending on the resolver's mode: it either ignores DNSSEC and resolves normally (most resolvers, most of the time), or it fails validation and refuses to resolve your domain at all (a smaller but real fraction of resolvers, notably ones set to enforce validation). That second failure mode is the sharp edge of DNSSEC: a stale or missing DS record after a nameserver change, key rotation, or registrar transfer can take your entire domain offline for validating resolvers, with no obvious error message pointing at the cause. If you're planning a domain transfer to a new registrar or away from one, DNSSEC is exactly the kind of setting that gets forgotten mid-move and breaks things days later.
Who actually needs it
For the overwhelming majority of sites, the answer is no. Here's why:
- The attack it stops is narrow. DNS spoofing and cache poisoning require an attacker with a specific position in the network path or a vulnerable resolver. It's not the way most sites get compromised, phished, or taken down. Weak passwords, outdated plugins, and stolen credentials are far more common attack paths, and DNSSEC does nothing for any of them.
- It doesn't encrypt anything. DNSSEC proves authenticity, not privacy. Queries and responses are still visible in transit. If you want confidentiality, that's a separate concern (DNS-over-HTTPS or DNS-over-TLS on the resolver side), not something DNSSEC provides.
- It adds an outage risk that, for most sites, outweighs the threat it defends against. A misconfigured DS record is a self-inflicted, hard-to-diagnose outage. For a small business site or blog, that's a worse expected outcome than the spoofing risk DNSSEC prevents.
Where DNSSEC earns its complexity: financial services, government and .gov-adjacent domains, registries and registrars themselves, and any organization under a compliance mandate that specifically requires it. If you're in one of those categories, you likely already know it, often because a security audit or a partner requirement told you so, not because you went looking for extra protection.
If you're evaluating it anyway
A few things worth knowing before you decide:
- DNSSEC is configured at two levels: signing happens wherever your zone is hosted (your nameservers), and the DS record has to be published at your registrar so it reaches the TLD registry. Both need to agree, and both need to stay in sync if you ever rotate keys or change providers.
- Keys need periodic rotation. An expired or unrotated signature can cause the same validation failures as a missing DS record, silently, until someone on a validating resolver reports your site as unreachable.
- Support varies by TLD. Not every top-level domain's registry supports DNSSEC the same way, and some don't support it at all.
When to ask us
DNSSEC support and configuration depends on your specific domain and TLD. Open a ticket from Support → New ticket in the portal and a real person will confirm what's possible for your domain before you make any changes to your DNS setup.