This article—the second in a series of four, examining the complex legacy, technical evolution, and future prospects of DNSSEC—sets out to fact-check common beliefs on DNSSEC, point to future-proof data collections on DNSSEC matters and provides an up-to-date perspective on what DNSSEC is like today. It was widely circulated for comments and has been endorsed by over 60 people across the Internet industry (see list¹).

In the first article from our series on DNSSEC, long-standing DNS luminary Roy Arends and Barbara Jantzen (communicator at the DNSSEC-focused non-profit organization deSEC) have engaged in a dialogue, recounting how DNSSEC adoption has been substantially hindered by the protocol’s bad image—an image that cannot be accounted for by factual failures alone, demonstrating the impact of narratives on the perception of technical devices.

Image-wise, two narrative items have indeed been particularly influential: First, the IANIX list of DNSSEC-related outages since 2009, and second, “Against DNSSEC” (with its follow-up FAQ), a DNSSEC-critical blog post written by Thomas H. Ptáček in 2015. Both helped harden the perception that DNSSEC is more trouble than it is worth, and references to them still surface in forum threads on DNS matters, even as the protocol, tooling, and operational practices have evolved. It therefore seems timely to check how fit they still are to help assess DNSSEC’s usefulness today.

Providing state-of-the-art alternatives to the IANIX list

In every field of knowledge, if we want to assess phenomena, we need thorough documentation to establish and collect facts, to witness evolutions, to develop hypotheses as to underlying causalities and try them. And although absolute numbers can provide a fair amount of insight, relative numbers are more helpful in assessing significance—especially when data is collected multi-dimensionally, allowing analysts to grasp inter-dependencies and derive a hint at potential causes. Because ideally, when dealing with broken things, we need to know not only how broken they are, but also how they broke.

A list can be a starting point for documentary work, though. The IANIX list, however, despite its objective looks, is more of a discourse than a documentation (as highlighted² in our first article). In addition, it lacks transparency about its collection and curation methodology, making it difficult for readers to assess the list’s reliability and significance. As the IANIX site further does not disclose its operator’s name or contact, information on its modus operandi cannot be obtained.

Looking back, the IANIX list can be credited for having drawn the DNS community’s attention on DNSSEC-related outages and, in doing so, having acted as a strong driver for improving the protocol. However, with its bulk of information lying far in the past, and entries becoming scarce since 2020 (without any possibility to know if that is due to a recent decrease in reportable events or simply to less active maintenance), the IANIX list does not make a meaningful contribution today.

To broadly assess the actual outage impact of DNSSEC, we need state-of-the-art alternatives. What should these look like?

• They should employ repeated (e.g., daily) measurements of the DNSSEC security status of a domain name sample of interest, such as TLDs and relevant subordinate domains.
• Based on the resulting dataset, one may more objectively observe trends as well as specific classes of outages (e.g., are ccTLDs or gTLD more frequently affected? and how about IDN variants of a TLD?).
• Additionally, if the dataset were further expanded to include the cascade of DNS queries and responses during resolution, different categories of failure may be discerned, such as signature expiration or synchronization failure during a key rollover (where the parent-side DS record does not match the child’s key).

Such longitudinal studies, consequently, could prove insightful in putting DNSSEC-induced resolution failures into perspective to other failure modes, in particular network issues or HTTPS misconfigurations that impact availability.

Good starting points in that direction are the DNSSEC and DANE Deployment Statistics page, which also has statistics on misconfiguration rates per TLD; a timeline of measured TLD validation statuses, provided by deSEC (the author’s non-profit employer) and based on prior work by Jaap Akkerhuis; the comprehensive dataset (2010-2025) used in a recent study by John Kristoff et al. (expected to be published later this month, at which time it will be linked here) which explores DNSSEC-induced outages and provides unweighed as well as downtime- and impact-weighed analysis (results cited at the end of this article); new measurements by deSEC contrasting percent-level error rates of both DNSSEC and HTTPS amongst the top 1M most popular domains. Another useful metric would be a public record (as recently started by Quad9) of how frequently resolvers use so-called Negative Trust Anchors (NTAs) to temporarily turn off DNSSEC validation when working around human errors, with the long-term trend being of particular interest.

Putting “Against DNSSEC” into perspective

The blog post “Against DNSSEC” was published by Thomas H. Ptáček in 2015, and got widely relayed. Its harsh critique of DNSSEC fell on fertile ground as numerous DNSSEC-related outages were happening and were given visibility by the IANIX list. This helped turn the blog post’s set of negative claims into potent beliefs that persist to this day and obscure actual implementation reality.

At the time of its publication, some of the blog’s criticisms reflected genuine limitations and operational experience, others were disputed even then. A decade of protocol, tooling, and operational evolution makes it useful to revisit how well they describe DNSSEC today, for the sake of a fresh assessment of implementation options.

To be fair, this is not the first effort to matter-of-factly assess the claims voiced in “Against DNSSEC”, but one of several such publications, spanning from 2015 to the present³—which incidentally corroborates the blog’s perceived influence.

These level-headed accounts, although they have not spread through the tech community as easily as earlier criticism did, still reflect (and contribute to) a gradual shift both in tone and in content, observable for instance in Hacker News forum threads where sweeping allegations on DNSSEC now get challenged instead of being swiftly echoed. However, even today in 2026, with automation standards having brought a substantial improvement to the protocol (RFCs 7344, 9615, 9859, 10026), common beliefs die hard—mostly among those less directly involved in technical matters, but with the power to weigh on decisions.

So, what are the common beliefs around DNSSEC? And how much truth is there in them today, in 2026? Because, obviously, common beliefs can also be true, half-true or formerly true.

1. Unnecessary, government-controlled and incomplete—Structural criticism

The first set of claims brought forward by “Against DNSSEC” dismisses the DNSSEC protocol as fundamentally flawed, for being structurally incompatible with its objective (preventing the manipulation of DNS answers). Verbatim: “DNSSEC is Unnecessary”, “DNSSEC is a Government-Controlled PKI”, “DNSSEC is Incomplete”.

Is DNSSEC unnecessary?—NO

The main argument used in “Against DNSSEC” to dismiss DNSSEC as unnecessary is that “with TLS properly configured, DNSSEC adds nothing”, and that the security of TLS certificates is mainly bounded by an attacker’s ability to hijack a domain validation email sent to a domain owner (and thus, bounded by the security of email).

The first part of this argument ignores real-world attacks that DNSSEC would have prevented while TLS could not, as for example the nameserver routing hijack of MyEtherWallet.com in 2018, enabling the theft of $160,000 within two hours.

The second part overlooks that a significant part of data fetched from the DNS are not about finding an IP address for establishing a TLS-secured connection (like HTTPS web site connections), but about providing other information—such as TXT records (used for a myriad of purposes), or NS and (upcoming) DELEG records (both used for declaring a domain’s responsible nameserver). Without DNSSEC, these are prone to various kinds of attacks, which can enable impersonation of the domain owner, traffic interception, or a hijack of the entire domain. Most notably, without a DNSSEC-based indicator, the MX records used to find a domain’s mail server cannot enforce that the subsequent email delivery happens through an encrypted connection (unlike in the web, where the “https://” URL prefix indicates the encryption request).

In addition, while “Against DNSSEC” acknowledges that insecure email can be a problem during certificate issuance, it fails to recognize that DNS lookups are involved in any certificate issuance process, regardless of whether validation happens trough email, or one of the other (and more common) validation methods which involve publishing a validation string under the domain.

Actually, today, you can use CAA records to restrict methods for domain control validation during certificate issuance and simply ban the insecure email method for your domain. As a byproduct, DNSSEC not only secures certificate issuance by hardening domain control validation, but also provides an indicator to secure email, by linking the email server’s TLS key to the domain directly within the DNS. This technology, called DANE, has already been rolled out by large players such as Microsoft, and secures about 4.6M email domains today.

Which means that actually both email and certificate issuance security are bounded by the security of the DNS, and that’s why it is material to up the authenticity level at this crucial layer of technology.

All in all, DNSSEC provides a much needed capability that TLS/HTTPS alone does not: It delivers signed, verifiable proof of origin for anything a registrant publishes, independently of any single application or delivery method. As such, it is a key enabling technology that lays a highly effective trust foundation on which applications such as DANE or CAA/TLS can rely to protect Internet users.

Is DNSSEC a government-controlled PKI?—YES and NO

DNSSEC is the PKI for the Internet’s unique global namespace. It is a globally consistent, well-governed, and well-managed namespace that applications can rely on for identifying servers, devices, and other named resources.

Just like in the certificate PKI world (where trusting a certificate typically requires trusting a chain of Certificate Authorities (CAs) tying back to a “root CA”, DNSSEC’s security guarantees rely on intermediaries, namely the TLD registries (and potentially other sub-registries, if the domain has multiple dots). These registries, as all organizations (CAs included), are indeed subject to some degree of government control, in particular of the jurisdiction in which they are based. That fact, however, is unrelated to DNSSEC: the same security model applies to DNS without DNSSEC. DNSSEC itself does not increase or decrease the risk of legal action. That said, if this is a source of concern to you as a domain owner, you are free to choose which TLD you want to use, according to whom you trust and what is your control preference—without relying on CAs or third parties you don’t have a prior relationship with.⁴

As far as the root zone keys are concerned, government control has been significantly reduced by what is known as the “IANA transition” in 2016, when IANA functions were shifted away from direct control by US-government’s telecommunications agency NTIA to ICANN’s multi-stakeholder governance. As a result, DNSSEC’s root governance and operation are grounded in a transparent multi-stakeholder model, its implementation is highly distributed, and many operational practices (such as key ceremonies and DNSSEC practice statements) are intentionally transparent and publicly observable.

Is DNSSEC incomplete?—YES and NO

“Incomplete”, in the blog’s elaboration, refers to DNSSEC not covering the so-called “last mile”, because validation often happens on a DNS resolver trusted by the client⁵, instead of happening on the client itself. While true, making this choice is a trust decision, not a design limitation of DNSSEC. In fact, Apple has been supporting client-side validation since 2022, and Section 5.3 of NIST’s “Secure Domain Name System (DNS) Deployment Guide” does recognize such deployment realities. Explicit requests for client-side validation features, if directed at software vendors that currently lack support, could create momentum for others to introduce client-side validation as well.

Meanwhile, it is worth noting that most Internet traffic is protected with authentication and encryption certificates (first and foremost: HTTPS web traffic). For certificate issuance, Section 4.2.2.2 of the certification rules requires Certificate Authorities (CAs) to perform DNSSEC validation when making DNS queries, including the DNS queries made to verify that the requestor is actually under control of the desired certificate domain name. This legitimacy check is vulnerable to DNS attacks, but DNSSEC, if in place, prevents the check from being hijacked.

This means DNSSEC makes sure that an illegitimate requestor cannot actually obtain a certificate based on a DNS attack. Barring non-DNS attacks (such as a compromise at the registrar or the CA itself), only the legitimate certificate will be in circulation. Browsers in turn will only communicate with servers that have this certificate configured. In other words: DNSSEC’s security guarantees transfer to the domain’s HTTPS certificate, ensuring that a browser does not communicate with a rogue actor: Even if a browser or other end-user application does not itself perform DNSSEC validation, the fact that CAs do perform it effectively protects the client’s last mile HTTPS traffic.

Besides, many important DNSSEC use cases do not have a “last mile” and thus don’t suffer from this problem: Both DANE-secured email and DNSSEC validation during certificate issuance does not involve end user devices, but only server-to-server communication where the validating resolver typically is directly under control of the participants (CAs and email providers). In these use cases, server-to-server not only equals end-to-end, but is at least equally important.

Finally, the word “incomplete” raises the expectation that technologies may reach completion. Like just every other protocol (including TLS, whose incremental versioning is met with equanimity), DNSSEC is incomplete insofar as it is a living standard.

Operational practices and standards continue to improve, including:

• better automation in signers and validators,
• the ability for better coordination in redundant multi-provider configurations,
• automatically relaying updates between child and parent zones (RFC 10026),
• adding new signing algorithms and deprecating old ones,
• serving as a secure service discovery mechanism and enabler for an increasing array of applications and services.

Regarding the “last mile” issue specifically, there are experimental efforts to facilitate end-to-end validation on the client without paying the latency price from additional DNSSEC-related lookups, by replacing them with pre-fetched DNSSEC chain data included in the TLS handshake (RFC 9102).

2. Cryptography, safety and architecture—Technical criticism

Three further claims revolve around the idea of DNSSEC being technically defective. Verbatim: “DNSSEC is Cryptographically Weak”, “DNSSEC is Unsafe”, “DNSSEC is Architecturally Unsound”.

Is DNSSEC cryptographically weak?—NO

DNSSEC is often dismissed as cryptographically deficient because it doesn’t encrypt DNS responses. That criticism misses the point: DNSSEC is not designed to protect the confidentiality of DNS responses, but their integrity—by cryptographically signing them⁶.

For that purpose, DNSSEC adopts well-tested cryptography and continues to move with operational reality, including broad migration to and use of the Elliptic Curve Digital Signature Algorithm, dubbed ECDSA (algorithm 13) and well-matched to DNSSEC’s resource constraints. The same algorithm globally leads and is generally recommended for the signatures that constitute HTTPS certificates.

Moreover, work on post-quantum cryptography for DNSSEC is underway in the research and standards community. The PQC DNSSEC agenda includes efforts to assess and mitigate the resource impact of newly standardized and proposed PQC signature algorithms—which generally have much larger signature and/or key sizes than ECDSA.

In short, DNSSEC’s cryptographic strength has successfully evolved to meet modern cryptographic demands, and is poised to continue evolving to support the post-quantum future.

Is DNSSEC unsafe?—NO

Under the umbrella of (un)safety, “Against DNSSEC” points out that DNSSEC (in its original form) allows obtaining detailed zone information by so-called “zone walking” (i.e., retrieving the list of all the subdomains of a domain from the responses to systematic DNS queries). That’s because DNSSEC provides signed assurance about which subdomains do not exist, and from that information one can easily conclude which do. While this is essentially a privacy issue more than a safety one, it can be addressed by enabling NSEC3—an automated setting to transform the non-existence response proofs into a hashed form of data, so that subdomains cannot readily be obtained unless explicitly queried for, if that is deemed necessary. (More complicated proposals like NSEC5, also mentioned in the blog post, were not pursued beyond the ideation stage by the DNSSEC community.) Alternatively, DNS operators that sign DNS responses on the fly can solve this problem using Compact Denial of Existence (RFC 9824).

However, even then, it is important to realize that the existence of most subdomains is exposed through Certificate Transparency (CT) logs: Both DNS and CT data, by their nature, are public, as there is no access control on who queries them. Hiding domain names therefore is an unreliable privacy strategy.

That said, DNSSEC can very well work in favor of privacy: in certain cases⁷, it allows a resolver to answer queries for non-existent names from its cache when it has seen a related (but not the same) DNS query before. This helps privacy (because data that is not sent to the domain’s nameserver cannot be eavesdropped on) and enables new defenses against common types of denial-of-service attacks (such as the Pseudo-random Subdomain Attack), turning DNSSEC into a safety belt that is useful beyond just protecting response contents.

Is DNSSEC architecturally unsound?—NO

The argument made by “Against DNSSEC” to bring home this point is that security decisions are best made according to each application’s needs, and that DNSSEC is not an application-layer protocol. While this objection seems valid for a range of things (take captchas, for instance: some applications may be fine with bots, others may not), it does indeed seem fair for a domain owner to assert that they want their domain’s DNS information to come along with verifiable signatures, in order to prevent clients from connecting when validation has failed. It is true that this is not always done end-to-end (although that’s not a design limitation, see the “last-mile” problem above)—but the objection that network-level security mechanisms are architecturally unsound by definition is overreaching. The same argument could be made against Wi-Fi encryption, BGP route validation, or IP packet checksums (which are all network-level), but these security mechanisms are generally accepted.

3. Adoption and deployment costs—Economical concerns

One of the most hard-dying assumptions about DNSSEC is its costliness—which is likely to dissuade non-technical people in charge of budgets from engaging in deployment. According to “Against DNSSEC”, both the adoption and the deployment of the protocol are resource-intensive. Verbatim: “DNSSEC is Expensive to Adopt”, “DNSSEC is Expensive to Deploy”.

Is DNSSEC expensive to adopt and to deploy?—YES and NO

For end users, DNSSEC is essentially free to adopt, with the added benefit of protection against attack-related losses (see the MyEtherWallet.com case above). In practice, all cost is carried by the resolver operator and the signing DNS operator. Measurements have shown that resolver-side memory and compute cost is small in practice. On the signing side, cost depends on how much specific expertise the signing operator needs to build⁸, and how many domains are being operated. Compared to signatures involved in HTTPS connections, DNSSEC signatures are computed much less frequently, so the cost of signing itself is not significant in light of the overall cost of operating an online service.

Overall, for well-run mid-size to large-scale operations, DNSSEC signing and validation during ongoing operations does not fundamentally change the financial equation.

Adapting software is certainly costly, but that task has largely been completed, and nameserver software today includes mature DNSSEC implementations by default. Also, while replacing old components in order to adopt more modern (automatic) solutions can be complex, the cost of new deployment and long-term operations has decreased significantly, with many DNS providers (such as Cloudflare, Squarespace, one.com, deSEC) and resolver operators (such as Cloudflare, Google, Quad9, DNS4EU) now routinely operating DNSSEC with full automation. Some work remains to be done with respect to the automation of DNSSEC configuration updates at the registry side, but progress is happening there as well.

“Against DNSSEC” also argues that network software is not equipped to handle DNSSEC failures smoothly (such as distinguishing expired signatures from an actual attack), and that “mak[ing] DNSSEC workable” would involve a lot of expensive code rewriting. That concern is diminishing, as browsers recently have made an effort to increase visibility into the origin of connection errors by implementing more detailed DNS error feedback based on RFC 8914⁹. Such developments indeed come with some cost, but that cost—unlike suggested—does not preclude large-scale deployment, as demonstrated by > 90% validation deployment in countries like New Zealand, Saudi Arabia, Pakistan, and Ghana.

The elephant in the room: Availability

The common beliefs that have emerged from “Against DNSSEC”, however extensive and influential, are dwarfed by a much more impactful claim: DNSSEC’s alleged threat to availability—exposed and broadcast by the IANIX list, as laid out above. But, historical records aside, how true is that today? Or, in other words, does DNSSEC have high availability in practice?

Yes, it does. The above-mentioned study by John Kristoff et al. (expected to be published later this month, at which time it will be linked here) has developed a measurement-based methodology and impact-weighted evaluation to quantify DNSSEC-induced outages. Its results show not only that the global DNSSEC deployment has had availability of over 99.99% in 15 of 16 years measured, but also confirms a sharp decline of incidents over the last five years. Accordingly, the occasional disruptive event (which still occurs, but has become exceptional) should not obscure the practical record of overall DNSSEC deployment.

As with any technology at Internet scale that requires interoperability amongst disparate implementations and operational environments, early DNSSEC adopters were likely to be hit by painful outages, due to misconfigurations or buggy code. Since then, thanks to engineering refinements and community-crafted operational standards, DNSSEC deployment has come to achieve demonstrably high availability across TLDs. All gTLDs as well as an increasing number of ccTLDs sign their zones, and many TLDs have successfully transitioned to new operators and/or algorithms, while remaining fully signed. And even if validation breaks (and the absence of an attack is confirmed), temporary NTAs (negative trust anchors) can restore basic availability—as done by Cloudflare and other resolver operators during the .de May 2026 incident.

DNSSEC is now considered to be important and stable enough to be a non-negotiable requirement for existing and future gTLDs. This policy-side view is matched by real world uptime records: Two of the world’s largest TLDs, .com and .net operated by Verisign, have long been DNSSEC-enabled, with more than 29 years of uninterrupted DNS resolution uptime. Also spotless is the uptime record of the world’s largest portfolio of TLDs, managed by Identity Digital (previously Afilias) and signed as soon as 2009.

In conclusion, as the facts presented in this article suggest, DNSSEC in 2026 should not be judged by limitations and operational records from its earlier deployment years (i.e., the trouble that triggered publications like the IANIX list and “Against DNSSEC”). Some concerns remain genuine tradeoffs, others have been substantially reduced by protocol evolution, automation, and operational experience.

In short, let’s not get stuck in archives. Instead—recognizing that DNSSEC has been stable and well tested in deployments for nearly two decades and continues to evolve when needed—let’s choose to draw on up-to-date information (such as presented in this article) and check out actual and successfully running implementations (like the DNSSEC automation showcases that will be provided by the third article of this series).

And if after doing so, with your own risk profile in mind, you make the informed decision not to use DNSSEC in your own setting, that’s perfectly fine. But make sure everybody else is also free to make their own choices—and accordingly, if others depend on you for having access to DNSSEC, don’t break their chance to use it, if they wish to.