DNSSEC validates about 38% of the internet. Here's why the other 62% hasn't moved.

DNSSEC has been in production deployment since the root zone was signed in July 2010. The foundational RFCs (4033, 4034, 4035) were finalized in 2005. The experimental work goes back to 1999. By any measure, DNSSEC is old enough to drive, vote, and make its own terrible financial decisions.

APNIC’s longitudinal DNS measurement puts validation at roughly 38% of queries from real users, up from 28% in 2020. It has been hovering in the mid-to-high thirties for several years without a dramatic inflection. The full breakdown by country and network is on their stats page if you want to see which ISPs are dragging the average down.

Two out of three DNS queries are not validated. On a protocol that has been production-ready for over fifteen years.

I have been waiting for a reasonable explanation of this.

What DNSSEC does and does not do

This needs saying every time because every time I skip it someone writes back.

DNSSEC authenticates DNS responses. It does not encrypt them. A signed response carries a signature from the zone owner’s private key; a validating resolver verifies that signature against the published public key, which chains up to the root zone’s trust anchor. If the signature doesn’t check out, the validating resolver returns SERVFAIL instead of the forged answer.

What this prevents: an attacker on the path between you and your resolver who modifies the response to redirect your traffic. It also prevents a compromised or malicious resolver from returning fabricated records. Without DNSSEC, the answer your resolver hands you is just bytes from a server that claims authority, with no proof.

What this does not prevent: a legitimate resolver knowing what names you look up. DNSSEC does not hide your queries. If you want that, you want DNS over TLS or DoH, which is a separate problem with its own tradeoffs. Do not confuse the two.

The practical cost of signing your zone

Zone signing requires key management. Two key types: the Key Signing Key (KSK) and the Zone Signing Key (ZSK). The KSK signs the ZSK; the ZSK signs the zone records. The ZSK rotates frequently (monthly to quarterly is common) to limit exposure if it’s compromised. The KSK rotates less often because KSK rollover requires updating the DS record at the parent zone, which means coordinating with your registrar.

If your registrar does not support publishing DS records, you cannot complete a DNSSEC delegation. This was a serious blocker a decade ago. It is less of one now: most registrars for .com, .net, and major ccTLDs support DS record publication. Some smaller registrars still don’t, and for obscure TLDs the parent zone operator may not publish DNSSEC at all, which means your zone can be perfectly signed and it still doesn’t matter because the chain of trust stops above you.

The tooling has improved. Knot DNS and PowerDNS both do automatic key management and rotation. BIND 9.17+ has inline signing that handles ZSK rotation without manual intervention. The scenario of “forgot to rotate the ZSK and the zone failed validation” is mostly an old-tooling problem at this point. Mostly.

There is still NSEC3 to think about. The original denial-of-existence mechanism (NSEC) lets an attacker walk your entire zone by following the chain. NSEC3 hashes zone names to prevent zone walking, at a cost: more computation on the authoritative server and parameters that need to stay current (SHA-1 is deprecated; you want SHA-256 with current iteration counts). Most signing tooling defaults to NSEC3 now, but old signed zones that have not been touched in five years may still be using weak parameters worth auditing.

DANE, which was supposed to fix the CA system

DANE (DNS-Based Authentication of Named Entities, RFC 6698) is the application layer that DNSSEC makes possible and that the ecosystem never fully deployed.

The idea: publish your TLS certificate hash in a TLSA DNS record. A connecting client looks up the TLSA record, verifies the chain of trust via DNSSEC, and validates your TLS cert against what DNS says it should be rather than against any of the hundreds of publicly trusted CAs. Fraudulent cert issuance from a misbehaving CA? TLSA catches it. Compromised CA? Doesn’t matter if the TLSA record names the right key.

For email specifically (DANE for SMTP, RFC 7672), TLSA records let a sending MTA verify it’s actually talking to the real SMTP server for the recipient domain, not an intercept. SMTP has no HSTS, no certificate pinning, no equivalent mechanism. DANE was the right answer to that gap.

DANE never got browser support. The major browsers decided not to add DNSSEC validation to the browser’s trust model, so DANE does not work for HTTPS in Chrome or Firefox regardless of whether a zone is signed. That decision killed DANE for the web. It is not coming back in any near-term form I can see.

For email it’s a different story. Postfix has had DANE support since 2.11. Exim since 4.85. Major providers started rolling it out around 2020-2022. If you run your own mail server and your zone is signed, there is no good reason not to publish a TLSA record for your SMTP service. The opportunistic mode (verify TLSA when available, fall back gracefully when absent) is three configuration lines and has essentially no downside.

The browser DANE story is dead for now. The email DANE story is a quiet ongoing success that most mail server operators don’t know about.

What to actually do

If you run authoritative DNS for any zone you care about: sign it. Use Knot or PowerDNS if you want key management automated. Confirm your registrar supports DS records. Publish NSEC3 with current parameters. That’s it for the signing side.

If you run a recursive resolver: enable validation. Unbound validates by default. BIND 9.4+ validates with dnssec-validation auto; in named.conf. Most major DNS-over-TLS providers (1.1.1.1, 9.9.9.9, 8.8.8.8) validate already. If your in-house resolvers predate the last five years, check.

If you run Postfix: read the DANE section of the Postfix documentation and enable opportunistic DANE. Takes twenty minutes, improves outbound SMTP security for every destination that has TLSA records.

The validation rate will not move by lecturing people. It moves by operators signing their zones and running validating resolvers until the minority becomes the majority becomes the assumed baseline.

The part I’ll grudgingly admit

DNSSEC is the right architecture. Authentication layered below the application, anchored to a single global trust root, with a delegation model that mirrors the zone hierarchy DNS already uses. If you designed DNS security from scratch today you would not produce something radically different.

The operational experience has been better for the last five years than it was before that. Automated key management is real. Registrar support is mostly there. The tooling is genuinely good.

What I cannot defend is the deployment pace. Fifteen years after the root was signed, two-thirds of queries are not validated. Some of those are routers and embedded devices that will never be updated. Some are ISP resolvers stood up a decade ago and not touched since. A meaningful fraction are operators who know DNSSEC exists and have never gotten around to it.

The protocol works. The tooling is there. The remaining gap is organizational inertia, which is the hardest kind to close.

Sign your zones. Validate your queries. Tell the next person who owns a caching resolver in your organization to turn on validation.

See also: Certificate lifetimes are collapsing for the related story of what the CA ecosystem is doing on the TLS side, and post-quantum key exchange is already deployed for the cryptographic transition happening in parallel.