Cert Authorities Check for DNSSEC from Today

Original Article ↗ Hacker News Discussion ↗

New CA/B Forum Requirement

  • As of March 2026, CAs must validate DNSSEC if a domain uses it when doing domain control validation (DCV) and CAA lookups.
  • DNSSEC is not required to obtain certificates; the change is that CAs can no longer ignore DNSSEC where it exists.
  • Some CAs (notably ACME-based ones) have already been using DNSSEC-validating resolvers for years; the requirement is now formalized.

State of DNSSEC Deployment

  • Monitoring of the Tranco top-1000 shows single‑digit DNSSEC usage; around 2% in the top 100.
  • Very few large sites have changed DNSSEC status in a year, and some have disabled it, suggesting stagnation.
  • Global numbers (tens of millions of signed zones, most TLDs enabled) exist but many are low-value or auto-signed domains; critics argue the metric that matters is coverage of “important” domains.

Security Value and Threat Models

  • Pro‑DNSSEC:
    • Provides cryptographic integrity for DNS answers; mitigates cache poisoning, some MITM/DNS spoofing, and can underpin DANE and other non‑HTTPS PKI.
    • Reduces reliance on hundreds of CAs by anchoring keys in DNS.
  • Skeptical view:
    • Main modern domain-takeover vector is registrar account compromise or routing/BGP, which DNSSEC does not address.
    • WebPKI + CT + multi‑perspective DCV + DoH already mitigate most practical DNS spoofing risks.
    • Very few real‑world incidents clearly “would have been stopped” by DNSSEC.

Operational Complexity and Risk

  • DNSSEC errors (especially with KSK/DS rollovers) can make a domain entirely unresolvable, with failures cached for TTL durations.
  • There is a long history of significant outages (including major services) tied to DNSSEC misconfigurations.
  • Some argue this is just “DNS is fragile” and we should improve tooling (advisory modes, better validation, shorter TTLs). Others see DNSSEC as adding dangerous “footguns” for limited gain.

Alternatives, Complements, and Ecosystem Constraints

  • WebPKI is deeply entrenched; browsers and large sites have invested heavily in making TLS fast, ubiquitous, and observable via CT.
  • DANE over DNSSEC is conceptually strong but stalled: clients would still need WebPKI for a long time, and middleboxes/misbehaving resolvers make DNSSEC hard‑fail impractical.
  • DoH/DoT give transport security for DNS without requiring domain operators to change anything, and are being deployed by browsers.
  • Some suggest a new, DNSSEC‑like but narrower mechanism just for CAs/DCV, or HTTPS-style schemes that encode key material in URLs.

Use Cases Beyond Web Browsing

  • Advocates emphasize:
    • DNSSEC + DANE could provide a general PKI usable by SMTP, SSH, VPNs, and decentralized systems that currently rely on TOFU or ad‑hoc PKI.
    • Could especially help small operators who lack internal PKI.
  • Critics respond that large fleets already run internal PKI (e.g., SSH CAs); delegating to a global DNSSEC PKI is a step backward for them.

Cost–Benefit and Incentives

  • One view: DNSSEC’s marginal benefit, once WebPKI exists, is modest, while deployment and operational risk are significant; that’s why adoption has stalled and even regressed.
  • Opposing view: resistance is largely cultural (risk‑averse ops, legacy infra, and misinformed FUD); cryptographically authenticating DNS is conceptually as important as HTTPS for HTTP, and the ecosystem should invest to make it safer and more automatic.