Does DNSSEC Matter?

Slack recently shared a detailed AAR of their DNSSEC rollout, including the outages they hit along the way. It’s the kind of post that makes DNS folks wince—and it’s a great prompt to revisit what DNSSEC promises, and whether it’s worth the trade-offs for most organizations.

After reading Slack’s post and the follow-on discussions (HN, for DNSSEC, against DNSSEC), you’re left asking: what practical risk does DNSSEC materially reduce today?

What is DNSSEC?

DNSSEC (Domain Name System Security Extensions) adds authentication to DNS answers—proving that a record was signed by the owner’s authoritative DNS. It does not encrypt queries. ICANN summarizes the goals as data origin authentication, data integrity, and “improved” security posture overall.

In practice, two things must happen for DNSSEC to work: the authoritative zone must be properly signed and the validating resolver must verify signatures. The protection is primarily between the resolver and the authoritative DNS, not between users and sites.

Here’s the normal DNS flow, with DNSSEC’s validation highlighted. Note how the user’s device isn’t part of DNSSEC’s trust check:

That means DNSSEC doesn’t secure your client connection to the resolver (that’s where encrypted DNS like DoH/DoT helps). And if either your authoritative DNS or the resolver is compromised, signatures can still be abused.

What Attack Is DNSSEC Aiming At?

DNSSEC targets DNS cache poisoning / spoofing—i.e., a resolver accepting a forged answer. It’s often depicted as a “man-in-the-middle,” but the relevant “middle” is inside the DNS stack (resolver ↔ authoritative), not the end-user’s browser session.

Real-world examples are uncommon. One oft-cited case is mail MX tampering—changing the A record where an MX points so mail detours via an attacker. DNSSEC can help if everything is deployed and validated perfectly. But many incidents attributed to “DNS” are really BGP mishaps or account compromise at registrars/hosts.

Is DNSSEC Worth It?

For most organizations: no. The probability-of-benefit is low versus the probability-of-outage during deploy/rotate/sign (Slack’s post is a cautionary tale). Meanwhile, today’s web is overwhelmingly HTTPS; a forged IP will usually hit a certificate mismatch.

Add the rise of encrypted DNS (DoH/DoT) increasingly protecting the client↔resolver link, and DNSSEC’s incremental value narrows further. There are exceptions—banks, governments, high-assurance environments—but for the 99% it’s hard to justify the complexity and fragility.

Who Actually Uses It?

Adoption among large consumer brands is still limited decades after the first DNSSEC spec (1997). Many big platforms don’t sign their apex today, while some infrastructure providers do. It’s telling.

Bottom Line

DNSSEC authenticates DNS answers—it doesn’t encrypt traffic, and it doesn’t stop compromise at your registrar, authoritative DNS, or resolver. If you deploy it, do so with strong ops hygiene (key rotation, monitoring, staged rollouts). If you don’t, you’re in good company—and you should still pursue HTTPS everywhere and encrypted DNS for user privacy.