Just one bad packet can bring down a vulnerable DNS server thanks to DNSSEC

Original Article ↗ Hacker News Discussion ↗

A newly disclosed “KeyTrap” flaw in the DNSSEC standard allows a single crafted packet to exhaust CPU on validating resolvers, potentially knocking major DNS software offline until patched. Commenters argue this exposes deeper design problems in DNSSEC—high operational complexity, self‑DoS risks, limited real‑world benefits given low signing rates, and reliance on intermediaries for key management—especially when HTTPS, DoH/DoT, and CT already handle most user-facing security. Others counter that DNSSEC still matters for tamper detection between resolvers and authoritative servers and underpins mechanisms like DANE, but concede that deployment remains uneven and often fragile.

Scope of the vulnerability

  • Attack only affects DNSSEC-validating recursive resolvers, not ordinary authoritative servers.
  • Exploit (“KeyTrap”) abuses a >20-year-old design choice in DNSSEC: validators may spend unbounded time chasing and checking multiple bad keys/signatures.
  • All major validators (BIND, Unbound, dnsmasq, PowerDNS, etc.) were affected because they followed the spec.
  • Patches mostly add limits on validation work/time; that technically makes implementations spec-noncompliant, highlighting a spec flaw rather than a classic memory bug.

DNSSEC’s design and operational problems

  • DNSSEC was designed in the 1990s around offline signing due to assumed crypto cost; several argue this architectural choice is a “original sin.”
  • Key rollover and expiry are described as a major adoption blocker: easy to self‑DoS, difficult to automate; CDS/CDNSKEY help but are poorly supported.
  • Misconfigurations and broken zones lead to opaque failures (“Internet is broken”), causing operators to disable validation in practice.
  • Some call DNSSEC a “footgun,” “infrastructure tax,” and suggest treating DNSSEC itself as a high-severity liability.

Security value vs. WebPKI / DoH

  • Pro‑DNSSEC side:
    • Provides tamper detection between resolver and authoritative servers; only way to “trust a zone’s content.”
    • Enables protocols like DANE and DNS-based SSHFP/PGPKEY verification.
  • Skeptical side:
    • DNSSEC offers no privacy or encryption; DoH/DoT/ODoH protect the last mile more effectively and are easier to deploy.
    • For the Web, TLS + CA + Certificate Transparency already handle integrity; wrong DNS answers mostly become DoS, not silent compromise.
    • DNSSEC downgrade/stripping attacks exist; validation mostly happens in recursive resolvers, not end clients.

Adoption and real-world use

  • Global DNSSEC signing of major TLDs (.com, .net) is said to be very low (around a few percent), with some ccTLDs (.nl, .se, .ch) much higher.
  • Validation rates measured at resolvers are reported ~30–40% globally, but critics note this doesn’t equate to end‑to‑end client security.
  • Debate over whether registrar‑managed DNSSEC for many domains counts as “meaningful” adoption.

Alternatives and future directions

  • Some promote DNSCurve or DNSCrypt as better designs with proper transport security, but acknowledge DoH has effectively “won” that niche.
  • Several argue DNSSEC is unlikely to replace WebPKI; DANE experiments in browsers were tried and removed.
  • There is interest in newer memory-safe DNS implementations (e.g., Rust-based resolvers), but multiple commenters stress this specific issue is about protocol design, not memory safety.