M3AAWG Expert Advisors are renowned specialists selected for their exceptional skills and extensive industry knowledge. They play a crucial role in supporting M3AAWG Committee activities and Initiatives by regularly contributing innovative ideas and fresh perspectives.
Our latest blog series, Ask a M3AAWG Expert Advisor, we asked our Expert Advisors for their thoughts on specific topics of interest to the industry. This series is intended to give industry peers exclusive insight to the experiences, opinions, and perspectives of our highly specialized and knowledgeable Expert Advisors. Readers are encouraged to submit your questions for Expert Advisors.
Question: What’s the story with The Domain Name System Security Extensions (DNSSEC)? Lots of effort with little reward seems to be the verdict by many, but why is that? Bad approach, bad implementation(s), bad marketing, no compelling business model? For a technology that (uniquely) provides for a singular, universal trust anchor that could solve many problems that are being tackled with other arguably inferior approaches, there seems to be little appetite to take advantage of it.
Let’s see what M3AAWG Expert Advisors have to say…
Readers may want to reference the M3AAWG Glossary while reading through this article.
John Levine - M3AAWG Expert Advisor
Like many of the Internet's core services, the Domain Name System (DNS) was designed in an era when the Internet was smaller and less hostile. In the 1990s a few people started to send fake DNS results that "poisoned" web caches with fake results. DNSSEC fixed this by putting cryptographic signatures on DNS responses, so if you have a chain of signed DNS responses from the DNS root to the name you queried for, you can be sure that the answer you got is the one the authoritative servers sent. Ironically, we fixed the cache poisoning problem by making caches more selective about who they accept results from, but DNSSEC has other uses.
The good news about DNSSEC is that it does what it is supposed to, and that it enables some interesting applications. DNS-based Authentication of Named Entities (DANE) puts information about Secure Socket Layer (SSL) certificates into signed DNS records, so a certificate can be checked with a DNS lookup rather than having to involve a third party signing authority. Another project is signing various "real world" documents, such as a driver's license on your phone validated by a DNSSEC signature from your state or province.
The bad news is that DNSSEC is considerably harder to set up than plain DNS, and it is quite fragile. To sign a domain with DNSSEC you not only have to create keys and signatures for all of your DNS records, which your DNS software can do automatically, but you have to set up the link from your domain registrar to your key, which generally involves logging into the registrar's website and copying and pasting long strings of data. If the setup is wrong, your DNS doesn't fall back to unsigned but instead becomes "bogus" and your domain in practice disappears until you fix it. This fragility is severe enough that many large organizations such as Google, have not yet chosen to use DNSSEC. We are working on tools to make management easier, but the progress is slow and the benefits still marginal.
Rod Rasmussen - M3AAWG Expert Advisor
A lot of effort has been put into the development of DNSSEC for nearly 20 years with a lack of “market adoption” that has frustrated many. I see many parallels to the story of Post-it Notes and their development by 3M. Many know the story of a scientist trying to solve a strong aerospace adhesive problem who accidentally came up with the perfect light reusable adhesive that now clutters much of the world’s office space and has provided 3M with a valuable product line. What isn’t as well known is that it took a lot of serendipity, another inventor to step-in, years to convince 3M management to develop the product, a mediocre initial launch, and a dedicated campaign after that initial failure to turn this classic “solution in search of a problem” into the success it became. Is DNSSEC in a similar circumstance, and could it become a ubiquitous foundation for the software and services built on the Internet? Perhaps.
So what can we learn from the Post-it Note analogy? Well, while not as horrible a solution for the original problem DNSSEC was designed for as the 3M adhesive was for aerospace, other solutions that were quicker and easier to implement have largely solved the original problem of DNS cache poisoning DNSSEC was meant to address. And while it provides a more “perfect” solution than those that have been implemented, “perfect is the enemy of the good enough” has largely made that purpose moot given the complexities we currently face in DNSSEC operations. DNSSEC provides something no other technology can right now, or likely will in the future - a “universal trust anchor” for validating the integrity of almost any digital claim being true to the source of the claim. That seems like powerful stuff that could enable solving a host of issues around identity, authentication and trust. Some enterprising folks have come along and looked at the tech and had ideas to use it to solve such problems - DANE being the most promising, with DANE for Simple Mail Transfer Protocol (SMTP) being known and used by many M3AAWG members. Like the initial 3M launch of "Press 'n Peel” (predecessor to the Post-it Note) though, while there has been some take-up, this has not proven to be the “killer app” yet. So do we have the equivalent of the little yellow sticky squares and just need a better marketing effort or do we have a great solution for problems no one will want to solve with it?
Like the pre-success days of the Post-it Note, there are other solutions to the same problems it solves, albeit with serious drawbacks. Digital Certificates and Certificate Authorities are the incumbent solution in this space, all rife with issues around which one to trust, how they manage things, etc.. Blockchain tech and proprietary systems have all been developed to solve many of these trust issues as well. So far, that’s been “good enough”, but like using a piece of tape or thumb-tack to put your note on your monitor, wall, etc., vs. the easy-to-use Post-it Note, these solutions pale in comparison to to a universal trust anchor which can ride on top of the relatively rock-solid DNS infrastructure that is ubiquitous worldwide. So what did 3M do to create the success of the Post-it Note? The Boise Blitz. 3M rethought the approach and relaunched Press ’n Peel as Post-it Notes in a massive marketing campaign to Boise Idaho businesses including traditional and non-traditional marketing. This included providing free samples to get Post-it Notes into peoples' hands so they could experience how superior the product was to their current solutions. Could something analogous be done today for DNSSEC? This may be challenging given the lack of a single entity looking to profit from sales, a lack of “ready-made” end-to-end solutions, and a lack of a simple form factor. However, thinking about this historical example can provide two things: inspiration that these seemingly insurmountable market-based challenges aren’t impossible to overcome, and a roadmap for how to do so. While current efforts to simplify the implementation of DNSSEC are a necessary part, to gain a true breakthrough, a new Boise Blitz approach is probably going to be needed. A rebrand and simple tools based on DNSSEC that solve some of today’s most challenging trust issues? A coordinated outreach campaign to get open source tools into business’s hands to try? Sounds like a campaign and a roadmap needs to be drawn up and supported.
Who's ready to take the lead on that?
Laurin Weissinger - M3AAWG Expert Advisor
The non-adoption of DNSSEC is an interesting area to discuss. Why are we not seeing this technology adopted more? Is it not useful or functional?
First of all, DNSSEC does what it promises: DNSSEC works from a cryptographic, protocol, and networking perspective, allowing us to verify the identity of root and authoritative servers, as well as the authenticity of records, which in turn deny (or at least significantly hamper) various attacks on the DNS, including Cache Poisoning.
Yet, DNSSEC is not a complete DNS security solution: crucially for many, anyone on the wire can still see all our communications. Thus, we have no confidentiality or privacy benefits. Furthermore, DNSSEC arguably decreases availability — as things go with cryptographic protocols, what seems like a small misconfiguration breaks the system. Unfortunately for users and those who fail to configure everything correctly, failure does not lead to a fallback to DNSSEC-free DNS, but breaks resolution. Thus, those who want to use the functionality of DNSSEC need to address the complexity and intricacy of the protocol and system.
Besides being core to the functioning of the internet, the DNS is central for a variety of security protocols and approaches, be this for transport encryption or email. DNSSEC would allow securing many of those records systemically and thus globally in a way that other DNS transport encryption like DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) simply cannot. Glossing over issues with administrator control and visibility (which are important), these protocols do protect integrity and confidentiality but only address the network link between individual machines. Thus, they cannot offer global protection like DNSSEC.
In short, DNSSEC works and offers something unique in a global, verifiable trust anchor for the DNS and beyond. Unfortunately, due to the distributed nature of DNS, as well as the resulting complexity, setting things up “properly” is risky; as mentioned, deploying a working configuration might be complicated for a single party. —, Additionally, and more importantly, reaping the benefits of DNSSEC is only really possible if other players or systems play ball… These include, but are not limited to, the resolver (provider) and all those in the DNS hierarchy sitting “above” the player wanting to enable DNSSEC. As per usual, coordinating and troubleshooting all this across different organizations, infrastructures, and software implementations requires time, effort, and resources. But even then, there is a risk that things go wrong, leading to outages and, for technical folk, unpleasant meetings with management.
While not a perfect analogy, this situation may remind some of the tragedy of the commons — if everyone paid their dues, i.e. took the risk to deploy DNSSEC, DNS security would go up considerably, complicating many attacks and mitigating risk. Yet, without a critical mass of players choosing to use DNSSEC (and the better tooling, automations, and processes that would come with it), the individual decision maker is taking a gamble. Do we flick the switch on a security solution that is not that common, deep down in the infrastructure where customers and management don’t look, and possibly not well supported enough in the ecosystem to make a difference, in return for the risk of things breaking — including in places where we do not have visibility or control? Right now, many will make the choice to avoid DNSSEC, as for the individual player in the current environment, the risks seem to outweigh the benefits. The only way to possibly change this would be a new push targeting key players and the development of tooling that further simplifies DNSSEC deployment, testing, and use.
While DNSSEC offers a robust and unique solution for establishing a universal trust anchor on the Internet, its clear adoption has been hindered by complexities in implementation and the risks associated with potential misconfigurations. The insights from our M3AAWG Expert Advisors highlight the need for improved tools, better marketing strategies, and a coordinated push from key industry players to realize the full potential of DNSSEC. As we continue to explore and address these challenges, the opportunity remains for DNSSEC to become a foundational element in enhancing Internet security and trust. Who will take the lead in driving this transformation?