DNS was designed in 1983 for a network where everybody knew everybody. A resolver asks a question, an answer comes back, and the resolver believes it. Nothing in the original protocol says who sent the answer or whether anyone changed it on the way.
For years that was mostly theoretical. Then in 2008 Dan Kaminsky showed that an attacker could poison a resolver's cache in seconds, by racing the real answer with thousands of forged ones. Every major DNS vendor shipped an emergency patch the same day. The patch made the race much harder to win. It didn't fix the underlying problem, which is that DNS answers can't be checked.
DNSSEC is the fix, and it's been ready for a long time. The root zone was signed in July 2010 and .com in 2011. Fourteen years later, most domains still aren't signed. Here's why it matters, and why it hasn't caught on.
What it actually does
DNSSEC adds signatures. It doesn't add secrecy.
Each signed zone has a key pair. The zone's records are signed with the private key, and the signatures are published in DNS as RRSIG records next to the data. The public key is published as a DNSKEY record. A validating resolver fetches both and checks the signature.
That raises the obvious question: how do you trust the key? The answer is a chain. The parent zone publishes a DS record, a hash of the child's key, and signs it with its own key. .com vouches for example.com, the root vouches for .com, and the root's key is built into every validating resolver as a trust anchor. If every link checks out, the answer is genuine. If any link fails, the resolver returns SERVFAIL instead of an answer it can't verify.
DNSSEC also covers answers that say a name doesn't exist. NSEC and NSEC3 records let a zone sign the "nothing here" response, so an attacker can't forge a denial either.
It's worth being clear about what that leaves out:
- It isn't encryption. Anyone on the path can still see what you looked up. Encrypting the query is a separate job, done by DNS over TLS or DNS over HTTPS.
- It doesn't protect the last hop by default. Your laptop usually trusts whatever its resolver says. If the resolver validates, you're protected from forged answers upstream, not from a hostile network between you and the resolver.
- It doesn't make a domain trustworthy. A phishing domain can sign its zone too. DNSSEC proves that an answer came from the zone's owner, not that the owner is honest.
Why it matters
Forged answers stop working. A cache poisoning attack against a validating resolver fails, because the forged answer won't carry a valid signature. The same goes for a compromised network device rewriting DNS responses on the way through.
It gives you somewhere to publish keys. Once DNS answers can be trusted, DNS can carry other security data. That's the bigger payoff. DANE puts a TLSA record next to a service, saying which certificate or key that service uses. A client that finds it can verify the server without depending only on the hundreds of certificate authorities it would otherwise trust.
It matters most for mail. Web browsers never adopted DANE, so on the web it's mostly an idea. Mail is different. When one mail server connects to another, STARTTLS is opportunistic. If an attacker strips the STARTTLS offer, most senders shrug and deliver in plain text. DANE for SMTP, defined in RFC 7672, fixes that. A sending server that finds a signed TLSA record for the receiving MX knows encryption is required and which certificate to expect, and it refuses to deliver otherwise. Postfix and Exim have supported it for years, and Microsoft has been bringing it to Exchange Online. MTA-STS is the alternative for domains that can't sign, but it's a weaker, trust-on-first-use arrangement over HTTPS.
Why so few people use it
The reasons are real ones.
It's easy to break. A signed zone has keys that need rolling, signatures that expire, and a DS record at the parent that has to match. Get any of that wrong and validating resolvers treat your whole domain as unreachable, which is worse than having no DNSSEC at all. Slack found that out in September 2021. A DNSSEC rollout went wrong and some users couldn't reach slack.com for most of a day, and Slack turned DNSSEC back off. Even top-level domains get caught. In May 2023 a routine key rollover at .nz tripped over a DS record TTL that was a day instead of an hour, and some users couldn't reach .nz sites for about thirteen hours.
The benefit is invisible. When DNSSEC works, nothing happens. There's no padlock icon, no browser badge, and nothing to show an auditor except a line in a scan.
The registrar chain is clumsy. The DS record has to be published by the parent, which usually means your registrar. Some registrars don't support it, some make you paste it into a form by hand, and moving DNS providers means a careful dance to avoid an outage. CDS and CDNSKEY records let a child zone ask the parent to update itself, but registrar support is still patchy.
Validation is only half there. Large public resolvers like Google's 8.8.8.8 and Cloudflare's 1.1.1.1 validate, and so do some big ISPs. Plenty of others don't, so a signed domain only protects the users whose resolvers check.
What I'd do
Validate on your resolvers. This is the cheap half. Unbound, BIND, Knot Resolver and PowerDNS Recursor all validate with a line of configuration or by default. Turn it on.
Sign zones you run on a managed DNS provider. Cloudflare, Route 53, Google Cloud DNS and most serious providers sign automatically and roll keys for you. You enable it, copy the DS record to your registrar once, and you're done. The breakage stories are almost always self-managed signing.
Sign the zone your mail lives in, and publish TLSA. If you run mail, this is where DNSSEC earns its keep. A signed zone with a TLSA record for your MX gets you authenticated, mandatory TLS from every sender that checks.
Monitor it. Keys and signatures that expire quietly are how DNSSEC outages start. Check the chain with delv, DNSViz or a monitoring probe, and alert on signature expiry the same way you'd alert on a certificate.
DNSSEC won't stop phishing or encrypt anything. It does one narrow thing: it lets you prove an answer is real. Almost everything else in DNS security depends on that.
Since then
Added October 2026. The root zone just changed its trust anchor for the first time since 2018. The new key, KSK-2024, was published in January 2025, and on October 11, 2026, the root started signing with it alone. Resolvers that never picked up key tag 38696 stopped validating. Closer to home, DANE is one of the things inbuxa checks for its mail domains. I wrote about why every one of those layers exists in How Email Got Hard.