DNSSEC Availability Topped 99.99% in 15 of 16 Years

DNSSEC availability exceeded 99.99% in 15 of 16 measured years, according to results from a forthcoming study cited in an October 2026 CircleID analysis. DNSSEC, or Domain Name System Security Extensions, lets a resolver cryptographically verify that DNS information was authorized by the domain owner and was not altered. The study covers 2010 to 2025 and reportedly found a sharp decline in DNSSEC-related incidents during its final five years. Because publication was still pending when the analysis appeared, the full methodology and results were not yet available for independent examination.

The analysis, written by a communicator at the DNSSEC-focused non-profit deSEC and endorsed by more than 60 people across the internet industry, challenges conclusions drawn from two influential historical sources. One is the IANIX list of DNSSEC-related outages dating from 2009. The other is the widely circulated 2015 essay titled “Against DNSSEC.” The analysis argues that both shaped DNSSEC's reputation when outages, immature software and manual processes were more common, but no longer reflect the protocol's current implementation accurately.

The IANIX list brought important attention to failures, but its operator, contact details and collection methodology are not disclosed. Entries have also become scarce since 2020, making it impossible to tell whether incidents declined or maintenance slowed. The analysis calls instead for repeated measurements, ideally daily, across top-level domains, or TLDs, which are endings such as .com or country codes. Measurements should distinguish generic TLDs from country-code TLDs and internationalized variants, while recording the complete sequence of DNS questions and answers. That could separate expired cryptographic proof from synchronization errors during a change in signing material, including cases where a parent's DS record no longer matches the child domain's information.

Existing starting points include DNSSEC and DANE deployment statistics with misconfiguration rates by TLD, a deSEC timeline based on earlier work, and measurements comparing DNSSEC and HTTPS error rates among the one million most popular domains. The analysis also recommends public reporting of Negative Trust Anchors, or NTAs, temporary exceptions that allow a resolver to stop DNSSEC validation for a broken domain after operators confirm that the problem is not an attack. Quad9 has begun publishing such information. Longer-term records could place DNSSEC failures beside ordinary network outages and HTTPS configuration problems.

The central claim is that DNSSEC protects information that HTTPS alone cannot. In 2018, a routing hijack involving the nameservers for MyEtherWallet.com enabled the theft of $160,000 in two hours, an attack the analysis says DNSSEC could have prevented. DNS also carries more than website addresses. TXT records support numerous services, MX records identify mail servers, and NS and forthcoming DELEG records identify a domain's responsible nameservers. Manipulating them can enable impersonation, interception or control of an entire domain.

DNS is also involved when a Certificate Authority, or CA, confirms control of a domain before issuing an HTTPS certificate. CAA records can restrict which validation methods and CAs a domain permits, including banning email-based validation. DANE, or DNS-based Authentication of Named Entities, can associate an email server's TLS credentials directly with its domain. TLS is the technology that encrypts connections such as HTTPS. The analysis says DANE has been deployed by large operators including Microsoft and currently protects about 4.6 million email domains. DNSSEC therefore complements HTTPS by authenticating DNS data on which certificate issuance, email delivery and other services depend.

The claim that DNSSEC creates a government-controlled public key infrastructure, or PKI, is more nuanced. DNSSEC relies on a chain of trust through registries, just as website certificates depend on trusted CAs. Registries and CAs remain subject to the laws of their jurisdictions, but that is not introduced by DNSSEC. The 2016 IANA transition moved root-zone functions away from direct control by the US telecommunications agency NTIA to ICANN's multi-stakeholder governance. Root operations include publicly observable practices such as formal ceremonies and DNSSEC practice statements.

Another criticism is that validation often occurs at a trusted DNS resolver, the service that looks up domains for a device, rather than on the device itself. Apple has supported client-side validation since 2022, while NIST's Secure DNS Deployment Guide recognizes multiple deployment models. Certificate-issuance rules also require CAs to validate DNSSEC when making relevant DNS queries. This can prevent an attacker who manipulates DNS from obtaining a certificate, although it cannot stop unrelated compromises at a registrar or CA. Experimental RFC 9102 work would carry prefetched DNSSEC chain data in the TLS handshake to support client validation without extra DNS lookup delays.

DNSSEC does not encrypt DNS requests because its main purpose is authenticity and integrity, not secrecy. Encrypted DNS protocols such as DNS over HTTPS, DNS over TLS and DNS over QUIC, commonly called DoH, DoT and DoQ, protect messages between two endpoints. They do not independently prove that information survived every stage of DNS resolution unchanged from what the domain owner authorized. A fuller privacy and security approach can therefore combine encrypted DNS transport with DNSSEC validation.

The cryptography has also evolved. DNSSEC now widely uses the Elliptic Curve Digital Signature Algorithm, or ECDSA, identified as algorithm 13 and also widely used for HTTPS certificates. Standards work is examining post-quantum cryptography, although proposed algorithms generally require much larger cryptographic data. Automation has advanced through RFCs 7344, 9615, 9859 and 10026, including better coordination between providers and automatic updates between child and parent zones.

Privacy concerns around “zone walking,” which can expose a domain's subdomains through systematic queries, can be reduced with NSEC3, which transforms proof that a name does not exist into hashed data. Operators signing responses on demand can instead use Compact Denial of Existence under RFC 9824. Many subdomains are already visible through public Certificate Transparency records, so keeping names secret is not a reliable privacy strategy. DNSSEC can also improve privacy and resilience when RFC 8198 lets resolvers reuse cached proof that related names do not exist, reducing queries to authoritative nameservers and helping defend against pseudo-random subdomain denial-of-service attacks.

Cost remains dependent on scale and expertise.