Why do we need DNSSEC?

Original Article ↗ Hacker News Discussion ↗

Perceived need for DNSSEC

  • One side argues “if we truly needed it, it would be widely deployed after 25+ years”; current near-zero adoption in major orgs is seen as evidence it’s low-value or misdesigned.
  • Others say this is just a reflection of poor cybersecurity priorities; DNS hijacks and BGP-based attacks are real, and dismissing DNSSEC downplays genuine risks.

Threat models and real-world attacks

  • Pro-DNSSEC comments focus on:
    • On‑path attacks (ISP, Wi‑Fi, BGP hijacks) that can spoof DNS and obtain rogue TLS certs.
    • Documented BGP hijacks of DNS providers used to steal cryptocurrency or inject malicious JS.
    • DNS-based ACME/CAA flows where unsigned DNS lets attackers get certificates.
  • Skeptics respond that in practice most compromises are via registrar or DNS-provider account takeover (ATO), which DNSSEC doesn’t mitigate; BGP/DNS spoofing is treated as a rare, “fine‑tuned” threat.

Alternatives and “better fixes”

  • Suggested alternatives:
    • Secure CA↔registrar channels (RDAP/DoH) for validation, bypassing end‑user DNS entirely.
    • Multi‑perspective validation by CAs, RPKI + ASPA for routing security.
    • Stronger auth (U2F/passkeys) at DNS providers to stop ATO.
    • Transport security for DNS (DoH/DoT/DNSCrypt, encrypted zone transfers) instead of data signing.
  • Some argue “secure DNS” is needed, but DNSSEC is a poor mechanism compared with easier‑to‑deploy encrypted DNS.

Operational complexity and economics

  • DNSSEC is described as brittle, outage‑prone, and tooling‑poor: key mixups, chain issues, TTL/caching pitfalls, and spectacular outages at TLD/major sites.
  • Critics frame security as an economic problem: DNSSEC raises defender cost massively while barely increasing attacker cost for common attacks.
  • Supporters counter that cost is modest on modern platforms (e.g., Route53, Unbound, pi‑hole) and worth it for organizations with higher risk.

Trust, governance, and PKI concerns

  • DNSSEC is criticized as “another PKI” with roots controlled by governments and large operators, with no CT‑style transparency or realistic way to distrust misbehaving TLDs.
  • Some see it as effectively a key‑escrow system for states, offering “zero protection” against them.
  • WebPKI + Certificate Transparency is presented as strictly better in governance and revocation.

Client-side validation and UX

  • Core architectural complaint: DNSSEC validation usually happens in recursive resolvers, not clients; browsers trust a single “AD” bit.
  • Some want validation pushed to clients/OS APIs with better UX, but note that would be yet another massive migration.

Adoption, IPv6 comparison, and future

  • IPv6 is used as a contrast: slow start but now large share of traffic; DNSSEC has stagnated at very low deployment, even regressing in some regions.
  • Multiple commenters suggest “back to the drawing board”: keep the problem (DNS integrity) but design a new, simpler, incrementally deployable protocol rather than try to force DNSSEC to 40%+ deployment.