18 ms·
Calling time on DNSSEC: The costs exceed the benefits
- X-Istence 3y agoI 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.
- tptacek 3y agoWhich 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.
- 616c 3y agoWhy might re FedRAMP?
- tptacek 3y agoThere's a historic DNSSEC requirement from the USG, which is actually a big chunk of the reason anyone invested in DNSSEC in the early 201x's. But then it got rescinded, but then it stuck in some of the OMB documents, and it's become a weird political football (in the fleeting moments anybody thinks about it) so we're in a weird limbo where every once in awhile teams like Slack turn it on to close some FedGov business and fall off the entire Internet for a half day when DNSSEC eats them.
- skissane 3y agoThe Australian government’s offical cybersecurity guidelines recommend - but do not require - Australian government agencies to implement DNSSEC, “where possible” and especially on their “principal domains”. In a competitive procurement, if another vendor says “you want DNSSEC? No problem!”, while you are saying “we don’t support that” or trying to argue against the recommendation - that is unlikely to help in winning the deal. If your product is miles ahead of the competition, it might not matter; if it is close, this might be the thing that loses it. https://www.cyber.gov.au/sites/default/files/2023-03/5.%20Gateway%20Security%20Guidance%20package%20-%20Gateway%20Technology%20Guides.pdf https://www.cyber.gov.au/sites/default/files/2023-03/5.%20Ga... page 18 I imagine many other (wealthy country) governments worldwide would have similar internal guidance.
- anonymousiam 3y agoIt's funny how the USG might be conflicted with both an interest in DNSSEC adoption, and an interest in preventing its adoption. Less than a year ago I was having DNS problems reaching a subnet in the spaceforce.mil domain (via AFRC Desktop Anywhere). After some troubleshooting, I determined that the DNS server for their subnet was not configured for DNSSEC and my client was configured to refuse unauthenticated resolvers. Everything worked fine once I turned off DNSSEC locally. DNSSEC can prevent spoofing via MITM, which is something that lots of governments do, so I can see why they might not want everyone to adopt it. On the other hand, DNSSEC can help to secure network communication, so I can see why they might want to adopt it.
- nightpool 3y ago> DNSSEC can prevent spoofing via MITM, which is something that lots of governments do, so I can see why they might not want everyone to adopt it. Only if you're NOT using HTTPS, right? In which case your traffic is already trivially spoofable, so you're not really gaining anything else by using DNSSEC there.
- tptacek 3y agoDNSSEC is literally a key escrow system for the North American TLDs. There's no conflict: the USG people who know what DNSSEC is want it bad.
- X-Istence 3y agoIt's a requirement from some of our customers in the financial industry, as well as gov't. It's something various security firms have asked for, and it's a checkbox we will continue to just check. No matter how useless I think it is.
- tptacek 3y agoThat's fine, I understand. I'm not telling you how to live your life. All I'll say is: there are SOC2 firms that will also tell you to turn DNSSEC on. You can tell them to go fuck themselves, and you'll be just fine. I don't know if that's the case with your NY-FI customers (none of the major investment banks are signed, nor are any of the exchanges, nor are the largest hedge funds and prop traders, but that's neither here nor there); only you know how to handle them. I'm just here to establish that the mainstream security audits definitely don't require DNSSEC. :)
- amluto 3y agoThe finance systems I’m familiar with generally don’t rely on DNS for security and, more commonly, don’t rely on it at all. For systems operating over the open Internet, the most common security mechanisms involve pre-shared key pairs. For systems not on Internet, IP (v4) addresses are generally used directly. I’m actually generally disappointed that TLS in the context of web browsers essentially only uses the CA system for identification and security. It’s wrong at both ends of the spectrum. There are systems where manual key distribution would be fine, and avoiding the CAs as a weak point would be beneficial. And there are systems where the CA system flat out does not work (e.g. anything where the servers are not connected to the Internet and do not even have every-few-days Internet access). Neither of these use cases are handled well by web browsers. (DNSSEC doesn’t help either, of course.)
- bruce511 3y ago>> (e.g. anything where the servers are not connected to the Internet and do not even have every-few-days Internet access Actually it's possible to use the CA system on a closed LAN. A) register a domain. For example company-lan.com. B) assign each server on your Lan with a name and (local) address. Eg, daisy.company-lan.com, resolving to say 192.168.1.1 Clearly this address is only useful when used inside your lan. C) provision certificates for this address using the DNS-Challenge approach rather than the HTTP-challenge approach. (Bonus tip; using a DNS provider with a good API makes the process automateable).
- donttellmypeers 3y agoDoes 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?
- X-Istence 3y agoRoute53 signs the zone itself, and the key is managed using AWS KMS.
- donttellmypeers 3y agoThat's an answer to a different question. I asked if they let you put a DNSKEY RR in the RRset they serve. (To be clear: I'm not asking if they will import private keys and sign with them or anything like that, just if they'll let you place an additional DNSKEY in the RRset they serve.)
- wlonkly 3y agoI had to add a DS record to a Route53 zone just the other day, and when I did, I didn't see a DNSKEY option in the list of records. Don't count on that 100% because I wasn't looking for it, but I definitely don't recall seeing it.
- deleted 3y ago[deleted]
- adrr 3y agoRoute53 doesn't even let you add your key without making multiple entries and splitting the key.
- X-Istence 3y agoYou still have the add the DS records for the hosted zones to the parent hosted zone... The key for a hosted zone is managed using AWS KMS.
- hannob 3y agoThis is an argument against checkbox "audits", not an argument for DNSSEC.
- jedisct1 3y agoEven Google doesn't enable DNSSEC. In the future, ECH may become a justification for enabling it, though.
- exabrial 3y agoWe 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".
- donttellmypeers 3y agoIt'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.
- thayne 3y agoThere 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.
- tptacek 3y agoOn-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.
- silisili 3y agoAre they doing full chain TCP lookups? Asking earnestly as I don't know. If they aren't, they absolutely should be.
- AndyMcConachie 3y agoYou're probably correct in your assessment, but it does still happen. https://medium.com/s2wblog/post-mortem-of-klayswap-incident-through-bgp-hijacking-en-3ed7e33de600#d138 https://medium.com/s2wblog/post-mortem-of-klayswap-incident-... https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.pdf https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.p...
- tptacek 3y agoI think it's quite telling that the examples here all involve BGP subversion, which DNSSEC doesn't coherently mitigate: universal DNSSEC deployment would change the exploit you'd deploy to exploit BGP, but it wouldn't break the vulnerability.
- pabs3 3y agoI wonder if it is time to move past DNS altogether.
- Luker88 3y agoThe 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.
- jedisct1 3y ago> 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.
- Luker88 3y agoyes, but that was my point. You publish on an unsecure channel(DNS) the public key. Then, after the resolver gets the key, everything is safe. But getting the key might not be safe at all. DNSCrypt has been out a couple of years but does not yet have a standard RFC and is not used by the dns root servers. Or did I miss something in the chain of trust?
- jedisct1 3y ago> DNSCrypt has been out a couple of years but does not yet have a standard RFC https://datatracker.ietf.org/doc/draft-denis-dprive-dnscrypt/ https://datatracker.ietf.org/doc/draft-denis-dprive-dnscrypt... It's not used by DNS root servers because it's designed to secure communications between clients and caches, not between caches and authoritative servers.
- hannob 3y ago> 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).
- jedisct1 3y agoThe 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.
- teddyh 3y agoYou are conflating “registrar” and “DNS server provider”.
- anticristi 3y agoSwedish 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.
- patrakov 3y agoThey 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.
- peanut-walrus 3y agoThose same people with guns can also force your registrar to request removal of the DS record. Or in the case of ccTLDs, the people with guns might already control your TLD operator and can just answer the acme-challenges themselves.
- teddyh 3y ago> 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.
- viraptor 3y agoI'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.
- teddyh 3y agoYou frequently saw even large sites being down with an expired HTTPS certificate in the past, for days, or even longer. And if you mess up your HSTS headers, what recourse do you have? None, from what I recall.
- viraptor 3y agoIf you get an expired certificate, you can fix it close to immediately. It's all under your control. For dnssec you can't do anything until the cache expires. If the large sites were down for days because of expiry that's their own failures, not because of unexpected complexity.
- teddyh 3y ago
- silisili 3y agoFor 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.
- growse 3y ago> 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.
- quink 3y ago> I ran DNSSEC for hundreds of TLDs as a one man team That’s not a good thing?
- KaiserPro 3y agothe 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.
- thraxil 3y agoI 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?
- agwa 3y agoYou 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-rollout/ 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.
- peanut-walrus 3y agoHere's the full list of DNS attacks DNSSEC protects against: * Resolver cache poisoning * MitM upstream from resolver That's it. That is all that DNSSEC does. Meanwhile, here's some attacks or concerns that are actually seen in the real-world and which DNSSEC does nothing for: * Passive data collection * Malicious DNS resolvers * Registrar account compromises * Local network MitM against endpoints And these are the real-world attacks which are enabled or made worse by DNSSEC: * 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) Add to this the complexity of key handling and the risk of breaking your own zones and the calculation is pretty clear - on the whole, DNSSEC is actively making things worse and not providing a clear benefit for anyone.
- teddyh 3y ago> 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.
- teddyh 3y ago> 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.
- crest 3y agoTLS 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.
- api 3y agoHow does letsencrypt guard against this?
- jaas 3y agoThanks in large part to our research partnership with the group at Princeton CITP, Let's Encrypt has deployed a system we call multi-perspective validation. We validate domain control from multiple network perspectives so that an attacker would have to pull off several simultaneously successful BGP attacks in order to hijack our validation. It's not perfect but it makes it very difficult to do. There are other improvements coming that will further improve effectiveness. https://www.cs.princeton.edu/~jrex/papers/multiva20.pdf https://www.cs.princeton.edu/~jrex/papers/multiva20.pdf I believe the Google Trust Services CA recently announced that they have started doing this as well.