Slack recently shared a great AAR talking to their DNSSEC rollout, providing excruciating details on the various outages / issues they encountered. For those that live in this world, it’s enough to make you cringe and slowly die inside as you live through each issue with them. It also made us sit back and more actively think about DNSSEC.
As I was thinking through DNSSEC, reading their AAR, and digesting the various conversations, found here, here, here, it got me thinking about what DNSSEC was originally built to do and if it’s offering any real value.
Coincidently, even being close to 25 years old, it’s not widely adopted and this article might help explain why. It goes beyond the technical nuances being debated (i.e., government overloads, DANE vs CA, Bloat, Cryptography, Size, blah blah, things that 99.999% of world doesn’t care about) and focuses on the practical reasons.
What is DNSSEC?
It stands for Domain Name System Security Extensions (DNSSEC) and ICANN cites the benefits as three-fold:
What is really interesting about these three benefits is that two are very soft value propositions. For example, does it really decrease the vulnerability to attacks? What was the last attack that was mitigated through the implementation of DNSSEC? Most everything is theoretical in nature, and the best use case is a MX record being hijacked.
Don’t see any good reason for three – it’s essentially saying, because we did it, you should do it.
The first one is probably the strongest case, but it lacks all supporting data into how it’s really “protecting” any aspect of the internet, end users and companies. The failure to do so is what we believe the driving force behind it’s poor adoption.
Let’s see if we can’t better understand why these three pillars fall flat on their face.
For DNSSEC to work, two things must happen according to ICAAN:
So when you read this, you might find yourself thinking to yourself.. “umm, that’s interesting.. so DNSSEC provides validation between the registrant (i.e., Authoritative DNS provider) and the resolver (i.e., DNS resolver).
To help simplify what this looks like, here is an illustration we often use to describe how DNS works – modified to show you where DNSSEC takes place:
That’s right, the “security” being introduced is between the communication of your Authoritative DNS and the DNS resolver. It actually does very little for the you, and your client.
In fact, the problem of the DNS being unencrypted is more a problem between your device and the DNS resolver, more than the Resolver and the Authoritative DNS. It’s actually why encrypted DNS solutions like DNS-over-TLS (DOT) and DNS-over HTTPS (DOH) are more effective at providing consumer security than DNSSEC.
The problem that DNSSEC is trying to solve is an obscure problem with very little examples in the way of real-world practical examples. Yes, yes, I can hear the groans now – “But Tony, just because there are no practical examples it doesn’t mean we shouldn’t do it, does it?” Yes, I concede that is true. But one very important element that must always be taken into consideration is probability of risk. This is one of those controls whose probability of risk should be weighted extremely low, especially when weighed against the high probability risk of failures you will encounter along the way (which will almost always lead to availability issues). And even if you are successful, what material impact did it really have on your security posture outside of saying, “wow, that was fun.”
You see, DNSSEC offers security in the form of authentication – not encryption. All it’s doing is saying that the server providing the IP for the domain is authorized to provide the IP. And it was designed specifically to tackle one problem – Man in The Middle Attacks (MiTM). I still, for the life of me, cannot recall the last MiTM attack that occurred between an Authoritative DNS and DNS resolver that led to a redirect.
Now, there have been cases where a DNS resolver pointed to the wrong Authoritative DNS, which then led to a redirect or an availability issue. A great example of this was when China’s Great Firewall tried to take over the internet.
Security experts are not sure exactly how this happened, but it appears that at least one ISP recently began fetching high-level DNS (domain name server) information from what’s known as a root DNS server, based in China. That server, operated out of China by Swedish service provider Netnod, returned DNS information intended for Chinese users, effectively spreading China’s network censorship overseas.
And in this case it sounds more like a BGP announcement issue than a DNS issue.
Let me explain why:
DNSSEC does nothing to protect the Authoritative DNS. The Authoritative DNS signs your zone keys with it’s private key. If the Authoritative DNS is hacked, well, you guessed it, they can continue to sign with whatever keys are present (good or bad).
DNSSEC does nothing to protect the DNS resolver either. If the DNS resolver is hacked, well, the same applies in terms of being able to manipulate the DNS response as they please. The client, you, is none the wiser if it is, or is not, authenticated.
The client in both cases is none the wiser because clients don’t see any of the additional authentication. In other words, your device has no way of knowing if something has been authenticated between the Resolver and Authoritative DNS, or not.
In fact, the only way it usually knows is when it fails – as so eloquently illustrated by Slack.
More on MiTM Attacks and the Problem DNSSEC is Working to Solve
DNSSEC was designed to solve one very specific problem – Man in the Middle (MiTM) attacks also known as DNS cache poisoning, or spoofing, in the world of DNS.
Site note: there are ofcourse nuances between poisoning and spoofing, but for the purposes of this article let’s just go with it.
This is an attack where a bad actor intercepts communication while on the same network. Here is a rudimentary illustration of the process:
For consumers, we solve this through encryption. But in this case, we try to solve it with authentication. What’s interesting is that a lot of DNSSEC illustrations capture the MiTM incorrectly.
The actual MiTM being accounted for is between the internal communication within the DNS stack itself, not between the client and the stack. This is important to make note of.
You’re probably thinking, umm, ok, but this was created because it’s a real concern, right? Well, to that we’d ask, is it?
Outside of China’s Great Firewall going rogue for a bit, the next probably example was captured in a 2014 study – Probable Cache Poisoning of Mail Handling Domains.
In the study, they highlight that the normal flow of requests to MX records could be thwarted if the DNS for the IP address of the destination of the MX is changed. Here is an illustration of what they provide:
In theory, the paper suggests that DNSSEC should be able to avoid this by ensuring that only the authorized server is allowed to issue the appropriate IP and the resolvers would acknowledge only the authorized server.
The mail message makes an unintended pit stop at the poisonous IP address. That server can then forward the message to its intended destination. Since mail is transmitted asynchronously, the sender and recipient are not likely to notice anything out of the ordinary. The sending IP address in the message header would likely reflect the diversion, but since mail handling often has a few exchanges before the final destination, it is not immediately obvious to anyone along the path that the diversion was out of the ordinary.
You would do this by signing each of the records in your zone (i.e., A, CNAME, MX, CNAME, etc..). They emphasize their point by providing an “easy” example to demonstrate how simple this would be. They say:
Our method for finding this type of hijack is simple enough. We look for two different name servers providing different A records for the same domain.
Ok, sure, no problem. Let’s explore this a bit more…
If the use case here is that two name servers have to be set with your registrar, where one is malicious and one is not, then we’re talking about an issue where your registrar has been compromised and the bad attacker was able to add a malicious nameserver serving a malicious zone file. Yes, this does happen, but I fail to see how DNSSEC would have mitigated this. This is an account hack that allowed the bad actor to abuse settings in their system, not a MiTM attack. It also means that the bad actor could just as easily update their DNSSEC keys create a new Zone Signing Key for their zone.
The real threat in that scenario was a users registrars account (not always the same as their Authoritative DNS) getting hacked and allowing the bad actor to update with a nameserver serving a different zone file.
A true MiTM attack, while always possible, is not very probable.
Is DNSSEC Worth it?
For us, the answer is no.
Are there uses cases in which maybe it makes sense? Sure, if you’re a bank, or a federal entity, etc.. maybe. But in the world of what matters, DNSSEC doesn’t seem to be one of those things.
Don’t believe me? Let’s look at some of the biggest organizations serving consumers in the space who have the most to lose by not implementing it:
| Organization | Implemented? |
|---|---|
| No | |
| Microsoft | No |
| Fastly | No |
| Incapsula | No |
| Bank of America | No |
| Chase | No |
| Wells Fargo | No |
| GoDaddy | No |
| No | |
| No | |
| Netflix | No |
| Ebay | No |
| No | |
| Slack | No |
Ofcourse, I would be remised if I didn’t also share those that were:
| Organization | Implemented? |
|---|---|
| CloudFlare | Yes |
| Akamaii | Yes |
| SalesForce | Yes |
| PayPal | Yes |
Make note that the first version of DNSSEC was released in 1997. It’s been over 20 years (going on 25) since it’s release and somehow network admins are not waking up in night terrors thinking to themselves:
Even in that time, you’d be hard pressed to find a real-world, practical, case in which DNSSEC was the savior, or could have been the savior of a breach. It’s probably because most DNS cache poisoning that we have seen occur locally on the client via endpoint malware, not at the level DNSSEC is supposed to solve for.
The only thing it seems to have going for it is that is’ bundled in this idea of “security” and so by design, as a label, it must be important.
Just look at Slack, what did they get in return of their DNSSEC implementation? 24 hours of downtime, that 99.9% of their customers will never understand. Why? Was it worth it?
You ask the Sales organization, and the answer is a resounding yes! Now they can go after the big dollars. Ask the network / security team, and I would wager the answer was a resounding no, with a “don’t cite my name” caveat.
I suppose we just don’t subscribe to security theater, or check list security.
The Impact of Technical Advancements
Moving beyond our personal feelings, it is worth taking a second to acknowledge some of the technical advancements that call into question if DNSSEC is still a solution we should be even debating.
Hello, HTTPS
First is the HTTPS everywhere world we live in. A very large percentage of the web is now powered by HTTPS communications. Yup, that means that even if a DNS request were intercepted, and a bad actor responds with the wrong IP, you’d be presented with this when you visited the site:
Yup, that’s because the certificate won’t be recognized. Unless the bad actor got their root certificates as well, which would mean the CA is hacked as well. Shoot, let’s not go there…
Hello, Encrypted DNS
Second, encrypted DNS is actually introducing mechanisms that will offer encryption through the full communication chain.
How do we know?
Because we moonlight as a DNS resolver with CleanBrowsing and new advancements are allowing us to implement DOT through the entire communication stack with the Authoritative DNS.
So for us, implementing DNSSEC for 99.999% of the web makes very little sense. It’s definitely not worth the heart ache that comes from the entire process. That being said, we do enforce it with CleanBrowsing as a Resolver and it’s actually the #1 issue that domains have because of bad implementations.