Roy Arends is a Distinguished Technologist at ICANN, working in the Office of the CTO. His work focuses on DNS and DNSSEC standardisation, protocol evolution, and the relationship between specifications and deployed systems. He has co-authored and contributed to DNS security standards, analysis, and Free and Open Source Software, supporting the ICANN community through technical research that informs standards and policy discussions.

This article—the first in a series examining the complex legacy, technical evolution, and future prospects of DNSSEC—stages a reflective dialogue between Roy Arends, a long-time DNSSEC advocate and Barbara Jantzen, a newcomer from the humanities, discussing how a security protocol lost its lustre—not through technical challenges alone, but through stories, perceptions, and emotional baggage.

Once upon a time, a vulnerability was found in DNS, the foundational protocol of the Internet’s naming system. The fix seemed obvious: apply cryptographic signatures to ensure authenticity. The solution, DNSSEC (Domain Name System Security Extensions), was greeted by everyone as a no-brainer—to the effect that deployment was seamless, and the protocol lived happily ever after.

Reality, however, deviated sharply from that tale.

And here’s another tale: People working in the DNS world (be they thoroughbred techies or not) are not impacted by emotions—not concerning the fate of a given technical feature (that had their support, or not), and even less when it comes to their assessment of a technical issue.

Stories shape our perception

Tales, or stories, as I shall call them from now on, pervade us humans. They are woven into the fabric of our lives; their archetypical characters and dynamics shape our experience of the world and structure our emotions. That makes them hard to spot as biases in the assessments we make and the stands that we take. And stories are not only what gets recounted by grandparents at the fireplace, in movies or by advertising companies, they are also what we, as individuals or as a community, devise for ourselves as a means of self-identification.

Roy Arends: I like the approach, about how stories get interpreted as reality. And I think it’s good to step back and look at things from a distance. We techies may already know the DNSSEC story—whether they like their own version or not—this will be interesting to us.

The case of DNSSEC is very interesting from that point of view. In my 6-month experience as a communicator in a DNSSEC automation project, if you ask tech people whether DNSSEC has a deployment problem, you’ll get a swift “yes” as an answer. If you suggest it might have an image problem, people will mostly agree. If you imply that this might be related to storytelling issues, they will pause skeptically and only after a while tentatively acknowledge that there might be something to it. But if you hint that former DNSSEC supporters may, by now, be emotionally entangled regarding DNSSEC, you will mostly face incomprehension.

That’s why, despite image and stories not being those shallow things only “lesser beings” go for (because we all do), the very fact of writing an article such as this one, without the usual extensive statistical leg work to back it up, feels somewhat shady—even after having given a similar and mostly well-received talk at DNS-OARC 45.

I will therefore limit myself to reporting what I have observed—from my external perspective as someone rooted in the humanities—during my interactions with the DNS community. I leave it to Roy Arends, a long-standing figure in the field and currently a distinguished technologist at ICANN, to jump in and provide illustrations, additional context, corrections, or outright refutations as he sees fit.

Roy Arends: It’s good to frame it that way. And I am gladly jumping in.

Here’s my claim: Today, DNSSEC has a bad image, one that specs and events alone cannot account for, and which in turn impacts both the community’s choices concerning DNSSEC and, on an emotional level, the people involved in its development.

So, let’s see what DNSSEC’s image is like. Browsing the web and listening to what people say, common perceptions include the following: DNSSEC is old, expensive, complicated, both to implement and to use; it causes outages; it’s uncool, outdated, a dead horse. And then there’s the oft-repeated metaphor that it “burdens the Camel.”

Roy Arends: Let me jump in on the “Camel” for a moment. That metaphor has caused much delay in innovation in the DNS. While folks are trying to innovate to make it simpler, faster, more effective, more efficient, more secure and automated, some grew concerned about the growing complexity in the DNS and warned of expanding the already large number of DNS-related RFCs. Essentially, their message was: “Don’t burden the Camel any further.” Unfortunately, that got a lot of attention and made people cautious, while not making the situation any better. So, for a good eight, nine years, we had no innovation in the DNS. And of course, if you have no innovation, you have no automation.

Indeed. But the list, sadly, goes on: DNSSEC doesn’t do confidentiality, it’s “not what our customers want”, nobody uses it anyway, it’s a thorny protocol from Hell, a juice not worth the squeeze, a necessary evil, an unnecessary evil.

And last but not least, closing the vicious circle: It can’t be any good, because if it were, it would have much better deployment and reputation.

In short, DNSSEC is an antiquated and tricky protocol with serious availability downsides and too little benefit to make up for it—a liability.

A new dawn: initial enthusiasm

That’s a really long shot from how DNSSEC was perceived in what could be called its teens: Back then, in the mid- to late 2000s, for some people, it was obvious that DNSSEC was the future and would be universally deployed. End of story. Or rather: absence of story.

Roy Arends: And there have been some cases in which things played out just like that. In the mid-nineties, Telnet was overtaken by SSH (Secure Shell) in a short period of time. No one really complained: users still needed a username and password, and everything else looked the same, just that instead of Telnet, you used SSH. I was there when this so-called revolution happened. And it was a no-brainer. Around the same time, a similar process, though much slower, happened with HTTPS. It took a bit of deployment tech to get there, and underwater, there was a whole lot of work—we went from SSL 2.0 and SSL 3.0 to TLS 1.0, 1.1, 1.2, and now 1.3. But though people noticed these evolutions, everyone used them, upgraded them, and is still using them today, without looking back. So for me, at the time, DNSSEC was a no-brainer in the same way: “The DNS is just secure now.”

Others almost solemnly described DNSSEC as the key to a brighter future:

“Today is a historic day as the first generic Top-Level Domain (gTLD) has been signed.” says Jeremy Hitchcock in CircleID on February 4th, 2009—and quite emphatically so. And when, about a year later, the root zone gets signed, Ars Technica’s editor Iljitsch van Beijnum gets carried away: “Yesterday, the DNS root zone was signed. This is an important step in the deployment of DNSSEC, the mechanism that will finally secure the DNS against manipulation by malicious third parties.”

Roy Arends: Now, I was as enthusiastic as the rest. In 2009, I had been working on DNSSEC for 10 years. So, it was a really big thing to get the root signed—the end goal, so to speak—and it was achieved just four years after the protocol was deployed. That’s why, at the time, in my mind, I was done with DNSSEC. Little did I know that in 2025, we would still be talking about it.

Advocacy despite reservations

Not that everyone was all-enthusiastic about DNSSEC. In a 2008 post on dnssec.net (a site collecting various statements on “why deploy DNSSEC”), Paul Vixie made this remarkably Janus-faced statement: “DNSSEC is a colossal flop, but not a mistake. It’s an embarrassment, but we’d do it all again if we had to.” But he was all-in anyway: “In spite of all that, I’m asking your indulgence. Be an early deployer, help create a validator population and a secure zone population that others will see and be heartened by. Give the last-movers their advantage, take your payback in the form of satisfaction and early-adopter expertise.”

Roy Arends: Paul Vixie’s choice of words—“colossal flop”, “embarrassment”—may seem strange at first sight, but it is understandable when you think of the time. First, we had RFC 2065, and then RFC 2535, and then RFC 4035, and then we had NSEC and NSEC3. And already in 2004, people were saying: “Stop changing the protocol. Let’s just deploy it.” So by 2008, I think, Paul was kind of tired.

But why that strong advocacy despite the obvious reservations? After Dan Kaminsky had spotted a security hole in the DNS in 2008, the DNS community felt a strong urge to react and mitigate the threat of cache poisoning.

Roy Arends: Indeed, when Kaminsky found this attack, that was really a driver to deploy DNSSEC soon. I mean, people came up with other solutions, like adding more randomization. But that means you’re still not protected from MITM attacks—like the Snowden revelations we all remember. So yes, the DNS is being abused; that’s just a given, and you should generally assume that everything that’s not cryptographically secured is going to be attacked.

That’s why DNSSEC, even if foreseeably rocky in deployment, was hailed as a viable answer, with a utopian ring to it: “Obviously this is not going to be a project with immediate return on investment, it is a long-term strategy to allow us to put similar trust in the Internet as we did 10 years ago.” Said Olaf Kolkman, then director of NLnetLabs. Meaning: 10 years ago, when the Internet was a network of cooperators, free from malicious interference.

In short, to the DNS community, DNSSEC was either a no-brainer, the key to a better world, or a necessary evil. Three different story lines with just one thing in common: DNSSEC was useful.

Thou shalt implement DNSSEC

But then, things went south. The consensual usefulness of the protocol and the urge to take action in DNS security matters converged, and led DNSSEC enthusiasts to promote it in a rather patronizing and polarizing way, sending the (more or less) subliminal message: “If you don’t do DNSSEC, you don’t do security right.”

Roy Arends: I still am convinced of that. At the time, I talked to a whole lot of top-level domains to promote DNSSEC. And I remember telling people: “Just do it. Because it doesn’t matter what you think as a top-level domain, if you don’t deploy DNSSEC, then all the registrations under you will not be able to deploy DNSSEC. So, you need to make this universal decision of deploying it for your community.” In the beginning, some TLDs still had reservations. And understandably so, because DNSSEC is basically setting your zone on fire, and then hopefully, your system can handle it. So, when you’ve never deployed it, it’s a risk. On the other hand, if you want to do DNS right, you need to secure it. And despite the deployment and scaling issues, without DNSSEC, your DNS is vulnerable. So now that the root was signed, top-level domains needed to deploy DNSSEC; otherwise, no one would adopt it. And of course, if nothing is signed, ISPs will never start validating. Why would they?

Decision-makers, all wound up about DNSSEC’s necessity, chimed in and peddled it to everyone regardless of their infrastructure’s technical maturity (one of the most notorious examples being .gov in 2008/2009). That, in turn, led to misconfigurations and, as a consequence, outages.

DNSSEC is a liability: the IANIX list

And as the tech community is very fact-and-number-driven, these outages got thoroughly documented, namely on the IANIX website (referenced to this day as a proof of DNSSEC’s unreliability), as an impressively long and ever-growing list (without any context as to why the outage had happened, but with a collection of bad-tempered quotes by various DNS folks).

Roy Arends: First, I wouldn’t say “thoroughly documented” when speaking of IANIX. Thoroughly documented means you come up with a reason why the outage occurred, and you get statements from the people who have deployed it. So I would just say, the outages got “listed”. Speaking of which: A lot of the outages mentioned there are hyperbole. But when you list them all nicely like that, it makes an impression. What IANIX doesn’t list is the enormous amount of DNS outages independent of DNSSEC, like the one we had for Amazon Web Services recently—that wouldn’t show up on IANIX, because it’s not DNSSEC. I have seen DNS outages of whole TLDs, countries being offline for two or three days. In the early and mid-2000s, there were TLDs having DNS problems without it being DNSSEC, with incomplete zone transfers, and people noticed it only after a day. So there’s a reason why people say: “it’s always DNS”—even if I hate that phrase. But, to get back to IANIX: If you receive all these sources—DNSViz, DNSSEC Debugger, zonemaster.se, zonemaster.nic.cz, Unbound logs—and you look for outages, you will find them.

This led to a massive drop in trust, resulting in low deployment rates for DNSSEC.

DNSSEC is useless: “Against DNSSEC”

It also drew some other people’s attention to DNSSEC’s actual or alleged failures, who in turn felt they should pinpoint DNSSEC as Enemy Number One: In 2015, a roaring blog post called “Against DNSSEC” set a DNSSEC-bashing trend, very effectively relayed by Internet longevity. Indeed, both the IANIX list (whose level of maintenance is difficult to assess, as entries become scarce since 2022) and the blog post (which is both sweeping and by now obsolete) get referenced to this day in forum threads, as soon as the question of DNSSEC’s usefulness comes up.

Roy Arends: This is something I have experienced as well: You go to an IETF, have dinner with your tech mates and start chatting about DNSSEC. Everybody will end up all enthusiastic about it. And then, at the next IETF, you ask: “What happened? Why haven’t you deployed it yet?” And what you hear is this: “I told the decision makers about it. They were open to the suggestion, but then, they read things online and talked to other people, and the prevailing discourse was so negative, it made them shy away.”

That’s why, in the second article of this series, we will not only put the blog post’s claims into perspective by delivering up-to-date information but also suggest more instructive sources for DNSSEC-related outage monitoring and analysis.

Improving the protocol

The second half of the 2010s went by, the IANIX list grew longer and longer, and DNSSEC criticism was copiously aired across the tech community. From no-brainer, savior, necessary evil, DNSSEC had become a former gifted child, or worse, a disruptive young adult.

Yet, amid this factual and reputational mayhem, in February 2019, ICANN publicly restated its commitment to DNSSEC and called “for full deployment of the technology across all domains”.

Roy Arends: ICANN founded its call on “increasing reports of malicious activity targeting the DNS infrastructure” and referenced a “Krebs on Security” blog post on this topic, which had raised a lot of dust.

Meanwhile, seeing the obvious difficulties DNSSEC users were facing, DNSSEC experts (long-lived and new ones) continued their work on the protocol to allow for smooth and reliable implementation and maintenance, namely via automation:

• Standardization work was done with regard to DNSSEC automation (RFC 7344: Automating DNSSEC Delegation Trust Maintenance, RFC 7477: Child-to-Parent Synchronization in DNS → CSYNC, RFC 8078: Managing DS Records from the Parent via CDS/CDNSKEY). (And more recently: RFC 9615: Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone’s Operator), RFC 9859: Generalized DNS Notifications.)
• Some ccTLDs (.ch/.cr/.cz/.li/.se/.uz/.za/..., most of them in Europe, in countries with high validation and secure delegation rates) implemented DNSSEC automation, and: it worked.
• DNS operators (like Cloudflare or deSEC, the non-profit organization I work for) started offering fully automated DNSSEC hosting platforms, showcasing successfully implemented DNSSEC automation—with low support ticket numbers and high customer satisfaction.
• Working group efforts have been made to design a reliable way to handle multi-provider setups, in close coordination with the parties involved.
• Researchers investigated the complex causality dynamics in DNSSEC adoption and found correlation with very non-technical matters.

Roy Arends: That last one is really important. And yes, this was the time when, finally, the nonsense about the Camel went away, and people started innovating again, a lot, not just regarding DNSSEC, but also the DNS. I especially remember CSYNC, QNAME minimization (designed by the DPRIVE working group within the IETF), extended DNS errors, DNS error reporting and, of course, automation. And this last one is indeed crucial, because the fundamental problem is getting information securely up the chain to a parent.

Image trumps facts

All of this happened. But—despite these facts—the image of DNSSEC more or less remained the same, as the tone of a small sample of headlines shows: “DNSSEC claims another victim” (2022), “Another DNSSEC screw-up” (2022), “DNSSEC is notorious for breaking things” (2022), “Calling time on DNSSEC?” (2024)...

In other words, in order to address the massive availability problems caused by flawed implementation and maintenance of DNSSEC, DNSSEC people worked to make deployment approaches more user-friendly and safe. But: Not only did people not reconsider their stand on DNSSEC based on the new developments at hand, they didn’t even notice them (and accordingly, deployment rates remained scarce. That means people got impacted by image, by the story that was being told. But not only that, they got impacted by the story they would be inclined to hear.

Roy Arends: That’s true. It’s called DNSSEC fatigue. If you have been burned by DNSSEC in early deployments, you’re likely to resonate with negative stories and feel skeptical about subsequent improvement claims, because you think you’ve heard it all before.

Indeed, and media professionals have known this for a long time: Humans don’t grant their attention evenly, and—for evolutionary reasons—are more attracted to drastic, menacing and fearsome news items, because these may be relevant for their survival. In his seminal book “Factfulness”, Hans Rosling (Swedish physician and founder of the Gapminder Foundation) has identified this human tendency as one of the biases we actively need to fight in order to get a clearer view of reality. A similar claim is made by the Swiss philosopher and entrepreneur Rolf Dobelli, author of “The Art of Thinking Clearly”, who has dedicated most of his life to tracing potential biases in thinking, and whose description of the “salience effect” (first established by Daniel Kahneman) matches well Rosling’s “instinct of fear”.

This, by the way, would also explain why so many contributions, trying to reclaim the ground for DNSSEC (a blog post called “For DNSSEC” and deconstructing—as early as 2015—every single one of the claims made by “Against DNSSEC”; the insanely comprehensive SIDN webpage on DNSSEC—published in 2022—addressing relentlessly all the urban legends in circulation; a 2023 blog post called “For DNSSEC And Why DANE Is Needed”, staging a very detailed rebuttal of “Against DNSSEC”) would remain unnoticed and wouldn’t spread across the community. Too constructive, too matter-of-factly, too lame.

People are more likely to react to negative storytelling and to let it stick. But, in the case of DNSSEC, they also got impacted by emotions, both in relation to facts and to the story:

• distress and face loss (among those who run servers, had DNSSEC prematurely forced upon them and experienced outages as a result),
• anger (among the tech community, who felt abused by the DNSSEC hype),
• heartbreak and shame (among DNSSEC supporters, after witnessing outages, DNSSEC bad-mouthing and subsequent lack of adoption).

You might wonder why a tech-related article touches on heartbreak and shame. Yet that was precisely the feeling I had when I first encountered the DNS ecosystem. No one would spontaneously confess to be DNSSEC-friendly or confidently speak up for it. And still, very obviously, there was this thing they had with DNSSEC: they secretly cared. Indeed, I felt they were very happy to learn that my colleague Peter Thomassen and I were set to give a new impulse to DNSSEC adoption. But they also appeared to carry an emotional weight, seemingly without even being aware of it—maybe because emotions are not really in the focus of the DNS community, apart from what’s covered by codes of conduct as the IETF’s “Note wells” and ICANN’s “Expected Standards of Behavior”. But—as I didn’t rule out the possibility of being biased myself, as a trained teacher, editor and dramatic advisor—how would I know if there was indeed a reality to match my perception?

So I had this idea: to make people laugh about DNSSEC—as a way of testing the accuracy of both my factual analysis regarding DNSSEC’s image, and my perception of a massive emotional baggage with respect to DNSSEC’s history. So I devised a comedy pecha kucha talk on the subject for the IETF’s informal, but iconic “Bad Attitude Pecha Kucha” evening, admittedly anxious about the outcome.

And God, they laughed. So hard that I was sure: There was a burden indeed. In dramatic theory, you call that catharsis.** **In everyday English, comic relief.

Roy Arends: Oh yeah, absolutely. One of the things I remember from your talk was that all the tech people around me, who basically were on the same path as I was since 2000, looked at each other in recognition. And yes, we were on the floor laughing. It felt really good.

Okay, analysis completed. But how do we go from here?

A pivotal breakthrough: automation

In the 2019 movie “Yesterday”, a soon-to-be world-famous musician asks his manager: “Do I have to have an image?” To which she replies: “Well, if you don’t have an image, then the lack of image becomes an image.” And I would add: “Then other people are gonna craft your image, without your input.”

And that’s exactly what has happened to DNSSEC in the last 15 years. So yes, there is a need to engage in storytelling. And if you think that’s distasteful, remind yourself of two things: storytelling is not bad, it’s just human, and the story doesn’t have to be a mad raving, it can very well be a double-edged account—it will hold just the same, and maybe even better.

And the time to do so is now.

Roy Arends: I really like that part, I wouldn’t change a single word.

But not only is storytelling needed, now is also a good time to engage in it. Why?

First, because, as we have seen, a lot of DNS people are ready to rally around it, because in their hearts and minds, they are convinced DNSSEC is a good thing.

**Roy Arends: **That’s true for long-time DNSSEC supporters, but also for other DNS actors. Think of the CA/B Forum’s current ballots, aiming at making DNSSEC compulsory for CAs.

Second, because the global political context has changed very markedly in the past couple of years (with autocratic and populist tendencies striving, with deep fakes and bot-generated discourse manipulations submerging social media…) and has sharpened the understanding of authenticity and integrity being both valuable and at risk, creating a stronger interest in resiliency.

And third, because the technical maturity of DNSSEC software implementation has much improved now, and will improve even further with increasing automation.

Reclaiming the story, with equanimity

So, given this situation, let’s own the DNSSEC story and tell it afresh. It will have to be both active and reactive, because DNSSEC has had a hard time out there, deserved and undeserved. It will have to be a slightly boring story—one of slow and steady improvement, without the edgy spikes of drama (which would be very convenient to get past people’s dramatic filter)—and will have to deal with the inherent difficulty of promoting a protective device—“Breaking news: Nothing has happened!”.

And yes, in comparison with earlier versions, it will need to be toned down. Because DNSSEC is no savior, but no devil either: it’s a quite useful security protocol, that has evolved into maturity over time and that people should be updated about—in order for them to make an informed decision whether to use it or not, as the experts of their own situation that they are. And that also implies saying goodbye to deployment rates as the core evidence of success, or as Joe Abley (Engineering Director at Cloudflare and member of ICANN’s SSAC) recently put it: “In fact, there are lots of people who have a reasonable option for DNSSEC and who might decide not to use it. That doesn’t mean that DNSSEC has failed. The fact that it’s there and present, available as an option, allows it potentially to be incorporated where it’s useful. It doesn’t have to be universally useful to have succeeded.”

In a nutshell: The DNSSEC maturity gap wasn’t just technical and implementational—it was also human, on both ends of the protocol. Let’s do our best to close it: with technical work, standardization, information, dialogue, patience and—hello salience!—humor.

NORDVPN DISCOUNT - CircleID x NordVPN Get NordVPN [74% +3 extra months, from $2.99/month]