Systems Approach Last week I turned on DNSSEC (Domain Name System Security Extensions) for the systemsapproach.org domain. No need to applaud; I was just trying to get an understanding of what the barriers to adoption might be while teaching myself about the technology.
It turns out that, if you have your domain hosted by a big provider (we happen to use GoDaddy), it’s easy to turn on DNSSEC. But I think it says a lot that it took us this long (and the stimulus of working on a new security book) to get us to turn on DNSSEC. By contrast, we would never think of running a website in 2025 without HTTPS.
For the last couple of months, my focus for the new book has been on infrastructure security. Because these technologies are not directly end-user focused, it has been a challenge to gather information about what is really going on in terms of deployment. As I reported a few weeks back, there are some bright spots in the long and slow process of securing internet routing, notably the adopting of route origin validation (ROV, now over 50 percent) and the introduction of AS Provider Authorization (ASPA [PDF]). But the domain name system is also a critical piece of infrastructure with well-known vulnerabilities to attack – how are we doing at securing it?
The heart of the problem with DNSSEC is lack of user visibility
The Internet Society has a helpful dashboard of deployment stats for a number of “enabling technologies” supporting the internet, and DNSSEC is arguably the worst performing technology at 34 percent. HTTP version 3 has reached only 25 percent, but it has done so in four years as compared to the 28 years since publication of the first DNSSEC RFC. Meanwhile HTTPS, which is roughly the same age as DNSSEC, is enabled at 96 percent of the top 1,000 websites globally.
In addition to the dashboard, I found two blogs that shed light on the failures of DNSSEC: Geoff Huston from APNIC has written “Calling Time on DNSSEC?” and Edward Lewis of the Internet Society followed up with “Where did DNSSEC go wrong?” The cumulative list of drawbacks and suboptimal design decisions enumerated in those two blogs left me pretty convinced that we’re not going to see a big uptick in DNSSEC deployment anytime soon, even as I added one more domain to the deployment list myself.
Huston notes the similar timing of DNSSEC development relative to SSL/TLS and HTTPS, and the different trust models that they deliver. Both appeared on the scene in the mid 1990s as the Web was bringing the Internet to a much larger audience. Attacks on DNS have been known since 1990. What DNSSEC tries to do is assure a client that the name-to-address translation function of DNS has been done correctly without interference from an attacker. In other words, DNSSEC assures me that I really am talking to the IP address corresponding to the domain name that I entered.
By contrast, TLS assures me that I am talking to a server controlled by the entity named in the certificate. Of course, most people don’t look at either IP addresses or certificates; the standard TLS implementations show a padlock icon in the browser when all is well (and raise warnings when the certificate is invalid). This is usually enough for the user to feel reassured that the security of the site is OK.
I think this gets to the heart of the problem with DNSSEC: a lack of user visibility. DNSSEC does not directly make a user aware that they are connected to the site they wanted to connect to. I was able to turn on DNSSEC for systemsapproach.org because it was free and easy, but the experience of visitors to our site didn’t change. How much would I have been willing to pay for that service if my DNS provider wanted to charge for it?
We’re not going to see a big uptick in DNSSEC deployment anytime soon,
By contrast, I actually did pay for a TLS certificate a few years ago for another domain I control (for a local running club) because I believed it delivered real value: making the site more discoverable in search engines, and making it look more “trustworthy” to users. I’m not sure I’m getting enough value from DNSSEC to pay extra for it – thankfully I didn’t have to.
DNSSEC validation
In the absence of a little padlock icon to tell me whether DNSSEC was working properly, I looked around for some tools to validate our DNSSEC operation, and I found a couple of good ones: the DNSSEC Debugger from Verisign and the open source DNSviz tool. Both of them show that we have successfully established a chain of trust from the root zone via the .org zone and on to the systemsappproach.org zone.
The website DNSviz very nicely produces a very detailed graphical representation of the chain of trust for any website. Here’s what it produced for systemsappproach.org.
A diagram of the DNSSEC authentication chain for systemsapproach.org created at dnsviz.net – click to enlarge
If you’re familiar with how chains of trust are established by certification authorities for Transport Layer Security (TLS) then this should look pretty familiar.
One interesting detail that distinguishes this chain of trust from TLS, however, is that there are no choices of CA when it comes to getting your key signed: since our domain sits within .org, we depend on the .org domain to sign our key. If we happened to be sitting under a parent domain that did not implement DNSSEC (as is the case for about 30 percent of country-level domains, for example), we’d be out of luck. That dependence on implementation all the way from root to leaf is another reason why DNSSEC hasn’t progressed the way HTTPS has done.
While our prior comparison between TLS and DNSSEC might suggest that we can just relax and let our security be handled between browser and website using TLS, there are plenty of reasons to remain concerned about the security of the DNS. Modification of DNS traffic is routinely used as a tool for censorship, as was well reported in “The Collateral Damage of DNS Censorship.” One of the surprises in that paper is the extent to which DNS censorship within China has an impact on queries that originate and terminate outside China but have the misfortune to pass through a Chinese ISP.
- To progress as an engineer career-wise, become a great communicator
- What does it mean to build in security from the ground up?
- Contrary to some, traceroute is very real – I should know, I helped make it work
- Will passkeys ever replace passwords? Can they?
And this isn’t limited to China. (Will the US need its own great firewall to prevent access to the Chinese version of TikTok, for example?) A more recent report on how DNS is used for censorship is The Lock Net. Working around censorship is a big enough topic to need its own post (if not a book). I raise this issue to suggest that we should not simply give up on securing DNS.
With today’s widespread adoption of TLS it should come as no surprise that there are now standard ways to send DNS queries and responses over TLS-secured channels. There have been a few similar proposals to achieve this outcome, with the IETF having standardized both DNS over TLS (DoT) and DNS over HTTPS (DoH) in RFC 8484. There is some debate about the merits of each but for the purposes of this post the differences are not too significant. You can configure DoH in most web browsers.
While these approaches ensure that we have a secure channel to the intended DNS resolver, they lack assurance that the DNS information being provided by the resolver is correct. We can be sure of the identity of the resolver we are connected to, since that is provided by its TLS certificate, and the fact that the query sent and response issued by the resolver have not been modified or observed by an intermediary, since they are both encrypted and authenticated. But if the resolver itself is giving bad information, perhaps because the information provided to it from upstream in the DNS hierarchy has been corrupted, the client will be none the wiser.
So while the need to deploy DNSSEC all the way up the hierarchy is something of an impediment to deployment, it does provide a level of security that isn’t provided by simply securing the client-to-resolver channel. Indeed we can think of DNSSEC and DoH/DoT as complementary: DNSSEC ensures the validity of information in the resolver, and DoH/DoT gets you a secure channel from client to resolver.
For completeness, I want to mention Oblivious DNS, which extends DoH to make surveillance of DNS traffic more difficult. It’s actually one of several technologies used in Apple’s Private Relay and there is a blog about it from Cloudflare.
So where does this leave us? Well, the poor rate of deployment of DNSSEC seems like an outage to me, but most of the internet’s users don’t care about DNS resolution as much as they care about application-level security that is provided by HTTPS. But since DNS remains fundamental to the operation of the internet, and since attacks continue, I hope that there will be continued efforts to improve its security, even if DNSSEC itself turns out to be a bit of a failed experiment. ®
Source: https://www.theregister.com/
