▲ 115 points
back
181 comments
Here's the full list of DNS attacks DNSSEC protects against:
* Resolver cache poisoning
* MitM upstream from resolver
* Passive data collection
* Malicious DNS resolvers
* Registrar account compromises
* Local network MitM against endpoints
* DNS Amplification DDoS
* DNS server denial of service (on-the-fly signing or validating signed responses adds non-trivial overhead)
* Zone enumeration (NSEC and NSEC3 are hilarious)
* DNS server compromise through RCE exploits (not exclusive to DNSSEC, but handling signed responses adds a lot of complexity to servers and almost all DNS RCE exploits we've seen recently have been in the DNSSEC handling part)
> MitM upstream from resolver
And even this part is also mostly solved by DoH. (Unless someone can mitm you and spoof certificates, which means you're targeted by some organisations with serious resources...)
The problem with DoH is that it reinforces the certificate hegemony.
Anyone can set up DNSSEC and run it without applying for authorisation from another party. But DoH requires a certificate signed by a CA trusted globally.
> * Resolver cache poisoning
> * MitM upstream from resolver
Only for clients that do DNSSEC validation. Ignoring the additional latency it comes with, virtually no home routers nor operating systems do.
This is a super important point! The parent post, which is quite good, forgets the qualifier that in practice DNSSEC is exclusively a server-to-server protocol: it's what your DNS server uses to attempt to authenticate records from other servers. But when you get the records, you don't get the signatures; you just get a single bit in the header that says "I pinky swear that I checked the signatures".
It's wild that we're even considering rolling more of this out in 2023.
> That's it. That is all that DNSSEC does.
Thus providing an interesting foundation to build upon, for example DANE or SSHFP. Not very known or common things, but they show the potential of what is possible when there's a way to publish cryptographically authenticated records in DNS.
DANE isn't happening. Browsers tried a decade ago and gave up: https://www.imperialviolet.org/2015/01/17/notdane.html
In both cases what it boils down to is that "it's an alternative to the current CA system". Sure, alternatives are good, but why does it need to be coupled to DNS? If I have a .ly domain, do I really want to be forced to trust the Libyan government for my security?
> made worse by DNSSEC:
> * DNS Amplification DDoS
Not really; with SPF, huge TXT records are all over the place, and can be used instead of having to use RRSIG records.
> * DNS server denial of service (on-the-fly signing or validating signed responses adds non-trivial overhead)
People said this about HTTPS, too. They were wrong.
> * Zone enumeration (NSEC and NSEC3 are hilarious)
Firstly, NSEC5. Secondly, no secret data should be in DNS. It’s not designed for it.
> * DNS server compromise through RCE exploits (not exclusive to DNSSEC, but handling signed responses adds a lot of complexity to servers and almost all DNS RCE exploits we've seen recently have been in the DNSSEC handling part)
Not on the authoritative server side, surely? Sounds like a DNS resolver problem.
NSEC5 is a research paper, not a deployed standard. But thanks for calling this out, because it gives us an opportunity to reflect on the fact that, confronted with the problem of enumerable sensitive DNS labels, the best cryptographic minds of the IETF DNS working group came up with a 1990s password file.
One of the ways you can tell that DNSSEC advocates are operating in bad faith is by catching them attempting to argue that nothing in the DNS is secret to begin with. First, that's obvious gaslighting; disabling public zone transfers has been a security best practice since the mid-1990s, and no network security audit would fail to flag you for enabling them. Second, if the DNSSEC advocates actually believed that, they wouldn't have done NSEC3, whitelies, and (now, apparently, at some point in the distant future, NSEC5).
Can't have it both ways on this.
> Meanwhile, here's some attacks or concerns that are actually seen in the real-world and which DNSSEC does nothing for:
DNSSEC also does not press your suit or iron your shirt. How is this a criticism against DNSSEC? A security technology can not possibly solve all problems, and not solving some specific problems should never be a strike against it.
There is one case where I think DNSSEC provides a lot of value: domain validation for the purpose of issuing a TLS certificate.
To get a DV certificate, the most common kind, you just have to prove you own the domain. If someone can MitM the DNS request to verify domain ownership, then they can issue a certificate for your domain. Transperency logs help protect against this, as long as you are watching them, and notice the bad cert issued before too much damage is done. Granted, there isn't a big risk of MitM between the nameserver and the CA, hopefully with multiple locations. But a state actor might be able to do it.
Still, I'm not sure that is worth the complexity of DNSSEC. Especially since you really only need signed records for specific records.
On-the-ball CAs are already doing multi-perspective lookups from multiple global POPs to reduce the theoretical potential for this attack (which is probably extraordinarily rare). By far the most common way people lose control of their domains (and their certificate identities) is by getting their registrar account phished.
You can read more about multi-perspective validation here:
> On-the-ball CAs are already doing multi-perspective lookups from multiple global POPs to reduce the theoretical potential for this attack (which is probably extraordinarily rare).
It was certainly visible when a previous employer tasked me to go looking for it, in I'd guess 2018 or so. I have no details from that work because by convention I keep nothing, although by mistake I do still have a front door key to the office, which I really ought to get back to them one day.
IIRC the main targets were military and government entities in less important (so not G7) countries. We were focused on email at the time, but these days perhaps you would target other infrastructure and the shape of the attacks would look different. Since "Governments of poor countries" isn't an attractive sales target for a startup I don't think that work progressed beyond my investigation.
The Web PKI assumes the DNS is trustworthy, which in practice means DNSSEC or else just hoping. You are in team hope, and I think you ought to make that clear to people.
State actors don't need to MitM the CA, they just order a CA they have leverage over to issue them a certificate.
> Some see the current DNSSEC costs simply as teething problems that will reduce as the software and tooling matures to provide more automation of the risky processes and operational teams learn from their mistakes or opt to simply transfer the risk by outsourcing the management and complexity to larger providers to take care of.
> I don’t find these arguments compelling. We’ve already had 15+ years to develop improved software for DNSSEC without success. What’s changed that we should expect a better outcome this year or next? Nothing.
We’ve had the X.509 certificate infrastructure for 30+ years, and it’s only recently become mostly safe and automated enough for people to deploy without risk. (This includes new risks, like accidentally sending HSTS headers with too large timeouts to the world.) DNSSEC will get there, too.
> We’ve had the X.509 certificate infrastructure for 30+ years, and it’s only recently become mostly safe and automated enough for people to deploy without risk. (This includes new risks, like accidentally sending HSTS headers with too large timeouts to the world.) DNSSEC will get there, too.
The WebPKI didn't improve on its own; it got there largely because web browser makers have high-leverage points to exert influence, which they used to make sure improvements got done.
How do you envision DNSSEC getting there?
I'm not sure what you mean about deploying without risk only recently. X509 without extra recent additions like hsts could never lock out your users for extended periods of time. If you really messed up in some way, they could still ignore errors and continue while you buy/deploy a new cert.
With dnssec you can be down for days by messing up just the very basics.
> We've had the X.509 certificate infrastructure for 30+ years, a
You could argue that because TLS is both free and ubiquitous, DNSSEC is just added burden given the outages. Personally, I don't see BigTech pouring resources, like they do at HTTP/TLS/WebPKI.
I work in a field where we deploy software as a service for customers in various regulated fields, and DNSSEC is something that auditors look for as a checkbox to check that DNS is secured.
So far we've let AWS Route53 deal with the whole DNSSEC thing, but it has made moving hosted zones from one AWS account to another more difficult and more troublesome than it should have been, and making sure that DNSSEC is setup on all of them is frustrating and annoying.
Thankfully we haven't encountered any issues with DNSSEC signing causing downtime, but I expect it will happen when someone misconfigures a DNSSEC record somewhere and now we gotta wait for the caches to empty/clear.
Which audit requires DNSSEC? SOC2 certainly doesn't. ISO doesn't. HITRUST doesn't. PCI doesn't. FedRAMP might (we'll see how much longer that remains the case).
Most firms aren't DNSSEC-signed, most especially those with well-resourced security teams, the kind that collect all the available audit certifications because they have teams dedicated to doing that.
Even Google doesn't enable DNSSEC.
In the future, ECH may become a justification for enabling it, though.
Does Route53 let you manage the DNSKEY RRset (so you can add a DNSKEY to the set yourself) or do they have some sort of facade you have to interact with instead?
Route53 doesn't even let you add your key without making multiple entries and splitting the key.
This is an argument against checkbox "audits", not an argument for DNSSEC.
The most common attack against DNS is actually people's registrar accounts being compromised. That even happened to Google.
This is used a ton by malware authors, who silently add records to host malicious websites on benign domain names.
DNSSEC is completely useless here.
You are conflating “registrar” and “DNS server provider”.
For some reason I get rather annoyed by people who write lengthy blog posts about hot topic news of the day, especially those who mostly do handwaving.
> Even if you have a team of DNS experts maintaining your zone and DNS infrastructure, the risk of routine operational tasks triggering a loss of availability (unrelated to any attempted attacks that DNSSEC may thwart) is very high - almost guaranteed to occur.
What an absurd statement. Yeah, some people have had issues. But most of those did not have a trained DNS team. Or even person. I ran DNSSEC for hundreds of TLDs as a one man team. I'm not particularly smart or special...most TLDs have not had a DNSSEC outage. NZ did because they made mistakes, which could happen with any technology. Expired certs, for example, are much more prevalent. Should we throw away the CA system too?
I'm not even a DNSSEC advocate, really. I just find it bizarre so many people attack is as impossible to do. It's not. Attack it on its merits or lack of necessity instead.
> What an absurd statement. Yeah, some people have had issues. But most of those did not have a trained DNS team. Or even person. I ran DNSSEC for hundreds of TLDs as a one man team. I'm not particularly smart or special...most TLDs have not had a DNSSEC outage. NZ did because they made mistakes, which could happen with any technology.
The evidence base is growing that even with a well funded, competent DNS, it's very possible to completely shoot yourself in the foot with a minimum time to recovery not entirely within your control. This is not a good technology with well-thought-through failure modes.
> Expired certs, for example, are much more prevalent. Should we throw away the CA system too?
When my website cert expires, my entire domain and all its endpoints don't completely become unreachable with no easy workaround. The impact is very different.
> I'm not even a DNSSEC advocate, really. I just find it bizarre so many people attack is as impossible to do. It's not. Attack it on its merits or lack of necessity instead.
It's a bit like the arguments around programming languages like C/C++. Just because you think you can write C with zero memory issues, doesn't mean we should be encouraging everyone else to.
> I ran DNSSEC for hundreds of TLDs as a one man team
That’s not a good thing?
We should have started with DNSCurve and moved later to DNSSEC. The problem the engineer/developer persona is we intrinsically don't understand the value in "progress, not perfection".
It's pretty easy to say what people back in the 90s should have been working on in retrospect. The zeitgeist around privacy only really changed in the late 2000s if I recall. Shortly afterward DNSCurve appeared and since it's arguably easier to deploy than DNSSEC it's noteworthy how little impact it has had.
The worst part is actually that very few of the TLD support dnssec, so it still is a chinken-and-egg problem (and the available tooling remains atrocius).
But what alternative is there for securing the dns chain?
DNS-over-HTTP requires time sync, the usual CA problems and it only works for the resolver to the client, it's not used for authoritative servers.
DNSCrypt? Sounds good, but the server key is published in the NS record, which gets published in the old cleartext DNS. So we are still not securing the authoritative part.
Unfortunately DNSSEC is still the only option to secure the whole DNS chain.
> But what alternative is there for securing the dns chain?
You're asking the wrong question. The better question would be: What do I want to achieve by securing the DNS chain, and can I do that in a different way?
What you ultimately want is to make sure you're communicating with the correct other party. And the way to achieve this is TLS with certificates, validated via the WebPKI.
I'm not saying TLS+WebPKI is perfect. But it works certainly a lot better than DNSSEC (which, let's be honest, does not work in practice).
> The worst part is actually that very few of the TLD support dnssec
Almost every TLD does. What in the world prompted such a statement?
> The worst part is actually that very few of the TLD support dnssec
???
All the "regular" TLDs support DNSSEC: .com, .net, .org, co.uk
> DNSCrypt? Sounds good, but the server key is published in the NS record, which gets published in the old cleartext DNS
What is published in DNS records are the public certificates, not their signatures.
Swedish regulation requires DNSSEC for government domains (MSBFS 2020:7 for the DevLegalOps nerds like me out there).
I mostly agree with the author, except for one issue: ACME is currently vulnerable to DNS MitM attacks. LetsEncrypt reduces this risk by spreading validation across the globe, to decrease the likelihood of a successful DNS MitM. However, I feel that DNSSEC is the sound solution here.
They are protecting against the wrong attack. MitM is mostly theoretical. An irresistable government order (supplemented with people holding guns) for the DNS provider to insert the "correct" _acme-challenge record is something real, and DNSSEC makes this attack impossible.
TLS isn't worth much if someone hijacks your zone and obtains X.509 certificates for your services. A smart attacker with enough resources could even re-encrypt the intercepted traffic and control enough addresses to avoid running into per prefix resource limits or other obvious failure modes.
How does letsencrypt guard against this?
I have to confess that I don't deeply understand DNSSEC. I've set it up on domains in AWS (Route53) and GCP (Cloud DNS) and found it pretty simple and never had any issues (only .com and .org, no weirder TLDs). Are all the problems that people complain about only relevant if you manage all the DNS infrastructure yourself (rather than just letting GCP/AWS handle the KSK, rotation, etc)? Or have I set up a ticking timebomb that's going to be a big outage at some point?
You should be fine as long as you don't try to disable DNSSEC or transfer your domain to a different DNS provider.
You may find this blog post about Slack's DNSSEC-related outage useful: https://slack.engineering/what-happened-during-slacks-dnssec...
One of Slack's issues was that Route 53 had a bug in their DNSSEC support, which is why I said "should" above.
I wonder if it is time to move past DNS altogether.
Might be a good consideration technically, but is there any momentum?
...to?
the point of DNSSEC for tlds is to prove that the data coming from the server is actually correct.
for TLS to work, you need to validate the authenticity of the host you are connected to. Obviously you can use mutual auth, but you still need to authenticate the CN. You can use a custom CA, but that involves previous setup.
DNSSEC proves nothing about correctness, it just helps show that a record was published by someone with access to the private key pointed to in the DS record.
What's "correct" or not is an entirely more nebulous thing.