There are nearly 20 million DNSSEC-enabled zones [1], which is a drop in the bucket compared to the internet as whole obviously. But 20 million is not nothin’.
The problem with that 20MM number is that it's in large part the result of registrars auto-signing names (especially in Europe). There's 2 issues with that:
1. The overwhelming majority of those names are meaningless, just as it doesn't change anything about Internet security if I do or don't sign the "paulgra-ham.com" domain I bought on Hover years ago when I was drunk.
2. Registrar signatures are more or less security theater, because those customers aren't even controlling their own keys.
The total adoption of DNSSEC in commercial zones is between 1-4% right now, right?
DNSSEC has no shortage of problems, but this IMO isn’t really one of them:
> 2. Registrar signatures are more or less security theater, because those customers aren't even controlling their own keys.
It would be nifty if DNSSEC (or some superior technology) provided a degree of protection against a compromised registrar, but I don’t think that’s the primary benefit. Of course the registrar can change the DNS data.
DNSSEC purports to secure the transfer of data from the combination of the registrar and the domain owner to the resolver. For example, the combination of DNSSEC and CAA can, in principle, prevent even an arbitrarily privileged attacker on the network from getting a bogus certificate issued. Without DNSSEC, services like Let’s Encrypt rely on a degree or network voodoo to protect against MITM attack.
(Of course, a much simpler and more robust mechanism could accomplish the same goal. For example, there could be a standardized out of band mechanism by which a CA could securely ask a registry for the certificate policy for a domain. Something like this wouldn’t have the admin-screwed-up—and-the-whole-domain-is-down failure modes.)
edit: It looks like RDAP is moderately close to being able to do that out-of-band verification. I wonder if anyone is working on CAA integration with RDAP.
I know that, at least for .ch and .li, there was the plan that registrars have to pay extra for all domains that don’t have DNSSEC enabled starting some time next year. Some registrars just set up DNSSEC not because they believe it has value, but because they would have to explain a price increase to the customer.
There's also another article from 2015 titled "For DNSSEC" which is sort of a response[0] to the one posted here. That article was discussed[1] on HN late last year.
Weird to see this here, but OK! I keep debating writing a follow-up post called "Stick A Fork In It", declaring DNSSEC finally dead and buried, and (wisely) have decided not to call it quite yet. Factors motivating "Stick A Fork In It":
* The increasing salience of multi-perspective verification at CAs (LetsEncrypt won't depend on a single DNS response to domain-validate a certificate request, but will distribute that request to resolvers around the world and make sure they agree with each other).
* The potential inclusion of RDAP, the successor to Whois, as a mechanism for verifying domain ownership for certificates --- instead of doing a weird DNS dance, you can just ask the registrar directly.
* The design and deployment of MTA-STS, the HSTS-style TLS continuity protocol for SMTP; SMTP is basically the final use case for DNSSEC, where DNSSEC can serve as a signaling mechanism to ensure that SMTP connections actually use TLS and aren't negotiated down to plaintext by a MITM. MTA-STS was designed specifically to replace DNSSEC for this use case, by the major email providers.
* The ironic increase in domain takeover attacks --- ironic because they're overwhelmingly (probably universally?) done by compromising registrar accounts rather than playing games with the DNS protocol, such that even after a forklift upgrade to enable DNSSEC, we'd still mostly have the same DNS security problem.
* The mass adoption of DNS-over-HTTPS, which is "bottom-up" DNS security that (unlike DNSSEC) protects the "last mile" between browsers and the DNS servers they talk to; in a world where most users talk to just a couple trusted DNS resolvers, all of which speak DoH, DoH might be all the DNS security we need?
* The rise in BGP4 takeover attacks, which completely bypass name resolution altogether; as these attacks continue to mainstream, they too strike right at the heart of the problem DNSSEC was supposed to solve.
* The incredibly bad track record DNSSEC has for reliability; for instance, Slack had a multi-hour total sitewide outage earlier this year that came from attempting to turn it on. This was predicted --- it's predicted in the "Against DNSSEC" post! --- and it's come to pass: DNSSEC is easy to screw up, easier than TLS, and when you screw DNSSEC up, your site falls of the entire Internet without warnings.
* The success of Certificate Transparency and CA surveillance in the WebPKI, to the point where the largest and most commercially important CAs were actually ripped out of browsers after surveillance systems detected misissuance. Also, the most trusted CA on the Internet in 2022 is... free? The WebPKI of 2022 is just not the WebPKI of 2015.
Against this backdrop, the important thing to know about DNSSEC is that it is simply not widely deployed; you can quickly measure this by taking any list of the top domains (the "Moz 500" is an easy-to-download version) and then feeding it through dig:
for DOMAIN in $(cat list); do
dig ds $DOMAIN +short
done
That DNSSEC isn't widely deployed doesn't, of course, mean it never will be. But it's important to get a sense of the costs we're talking about: it would be one thing if the work of rolling DNSSEC out had already been done, the costs had been sunk, and we were just trying to extract some value of it. But the opposite is true!
I see a much different (and worse) opportunity cost to DNSSEC: if we stick a fork in it, we can get to work on something better. I think we've more or less established that a top-down government-controlled PKI is not the future of Internet security. Maybe DNS is worth protecting anyways! Ending the 26-year DNSSEC boondoggle would free us up to explore alternate models with clearer, more realistic trust models.
At any rate: I feel like the ~8 years since I wrote this post have pretty much totally vindicated my argument. I felt a little like I was going out on a limb when I wrote it. Now I fe...
You're missing the key difference: with the web PKI model, you have to trust every CA not to maliciously issue an unwanted certificate for your domain, whereas with DNSSEC, the owners of .ru (for example) can't affect your domain if it's under the .us TLD.
> And you're missing the fact that CAs that misissue certificates can and will be distrusted by Chrome and Mozilla
That doesn't protect against attacks from occurring, it only protects against future attacks from the same people who already attacked (assuming the same people don't create a new CA?).
And when Chrome and Mozilla distrusts a new CA, good luck on updating the certificate chains included in the operating systems of all the devices in the world, especially those that never update (old Android phones? IoT devices?).
> there's no way to revoke .COM
I think there is no need to revoke .COM because .COM can attack any domain within .COM anyway, even with/without DNSSEC and/or with/without CAs? Or what am I missing?
> I think there is no need to revoke .COM because .COM can attack any domain within .COM anyway, even with/without DNSSEC and/or with/without CAs? Or what am I missing?
The point is you don't build a system that assumes DNS is trustworthy, because it isn't.
> The point is you don't build a system that assumes DNS is trustworthy, because it isn't.
But the current CA PKI system already assumes DNS is trustworthy, even much more than if you were using DNSSEC-protected DNS PKI system, since it is not only vulnerable to almost all the same attackers/attacks, but it is also vulnerable to many more attackers (since any CA can also do an attack at any time, regardless of any possible future consequences it may experience or not).
I'm not saying it exists right now, I'm saying it could be created for a DNS PKI system if it was found to be necessary (like you seem to be implying)?
I'm not trying to be a jerk, I'm just saying, this thing you're talking about doesn't exist. Moreover: it's unlikely ever to exist. CT didn't get rolled out because the CA's wanted CT; I assume they actively detest it (other than LetsEncrypt). CT got rolled out because the browsers required it. The browsers have no leverage to make the DNS PKI do anything, because, once again, they can't revoke .COM.
Giving more power to a too-big-too-fail monopolist and hoping it will behave well is not a sensible system. CAs have been doing shady stuff before CT and there's no reason why they wouldn't resurrect MITM-for-cash business given DANE.
With WebPKI we have multiple mutually-distrusting parties keeping each other in check. It has become a better system.
> Giving more power to a too-big-too-fail monopolist and hoping it will behave well is not a sensible system.
It's not more power, it's the same power it already has!
This too-big-to-fail monopolist you're talking about can already hijack your domain, regardless of whatever WebPKI does.
> CAs have been doing shady stuff before CT and there's no reason why they wouldn't resurrect MITM-for-cash business given DANE.
Sorry, but I don't follow. Given DANE, CAs wouldn't even exist.
Unless you're talking about the transition period, which would be strictly better than what we have now, because the not-yet-transitioned domains would use WebPKI like today, while the already-transitioned domains would use DANE which has superior guarantees.
Currently Verisign can't sell certs directly, and would be caught by a CT log/report if they hijacked DNS to do this. If DANE was used, they could do whatever they want. I don't think the fact that Verisign has already too much power is a good reason to lean on them even more.
I'm not talking about transition period. DANE makes TLD owners effectively a CAs. The technical details are different, but the role of root-trust-anchored private-key-holding ownership-attesting authority is the same. And unlike WebPKI CAs, browsers can't remove DNSSEC roots for abuse of trust.
DANE is setting up a centralized system ripe for monopolistic abuse, where there are no checks and no consequences for fucking up. This isn't just a technical problem of a protocol for securing packets. It's also a meta problem of ensuring the organizations involved behave in a trustworthy way, even when it would be profitable to cheat, even when NSA and other 3-letter agencies put pressure on them.
> Currently Verisign can't sell certs directly, and would be caught by a CT log/report if they hijacked DNS to do this.
And then what? Like you said, browsers can't remove Verisign for abuse of trust, because Verisign isn't part of their roots of trust.
And they can't remove the certificate authority who issued the certificate because 1) the certificate authority is not at fault in that scenario, and 2) Verisign could just use another one to issue a new certificate.
Whatever answer you give here would apply to DANE as well.
> If DANE was used, they could do whatever they want
See above: they can already do whatever they want, so you wouldn't be leaning on them more than you are right now.
> DANE is setting up a centralized system ripe for monopolistic abuse, where there are no checks and no consequences for fucking up.
We already have a centralized system of trust, called the DNS system. It's just that currently it is still relatively insecure (DNSSEC is not widely deployed yet), so we have another fake security layer on top of it (the CA PKI system) which, because it's backed by Google and other organizations that people like so much, for some reason people trust that layer even though its security depends on the security of DNS and is actually even more flawed (since it has even more points of attack).
> DANE is setting up a centralized system ripe for monopolistic abuse, where there are no checks and no consequences for fucking up.
You can implement a CT-like system on top of it which would give you more transparency regarding what certificates are being used (where clients, rather than certificate authorities, would publish new certificate fingerprints to CT logs or even directly to some server managed by the domain owner).
But of course, the real issue is how to deal with Verisign if it starts hijacking domains, but this is already exactly the same problem we have today with the CA PKI system.
You cannot implement a CT-like system on top of DNS. You've said that a couple times in the thread, but ignored the reasons why it won't work for DNS. It only works in the WebPKI because browsers are able to force CAs to participate, by distrusting CAs that don't include SCTs in their signed certificates.
You have to understand how CT works before you (a) dismiss it, like someone else did upthread when they claimed CAs can just ignore CT, or (b) assume it trivially ports over to DNS.
> You cannot implement a CT-like system on top of DNS.
[citation needed]
> It only works in the WebPKI because browsers are able to force CAs to participate, by distrusting CAs that don't include SCTs in their signed certificates.
So? In a DNS PKI system, browsers would already distrust ALL CAs. So by that argument, it's in a much better footing to begin with.
What's happening is that you're thinking that in a DNS PKI system, TLD operators like Verisign would be equivalent to certificate authorities.
Except that they wouldn't, because Verisign couldn't create rogue certificates for other TLDs like certificate authorities can. And even if Verisign could create rogue certificates for .COM domains, this is already something that they can do today with the WebPKI system in place, since they can hijack any .COM domain at any time.
And even if Verisign is caught hijacking a domain to create rogue certificates with the WebPKI system, the browsers can't do anything about it, because Verisign is not part of their roots of trust.
So basically, you wouldn't be any worse than today (because Verisign can still attack your domain, regardless) but you'd certainly be much better, because you wouldn't have to keep a database of certificate authorities from all over the world who can create certificates for any domain in the entire world.
Oh, by the way, we're talking about a database of fully-trusted authorities that even if they are caught in any wrongdoing, can never actually be distrusted (like you mention) in hundreds of millions of deployed systems out there who might take months or even years to update, or worse, who never update (Android devices, IoT devices, etc).
You're not saying anything here. What I think has happened in this thread is that at least a couple of people have determined for themselves that CT is something CA's opt into, and that they can just randomly decide to issue certificates that aren't logged. But that's not how CT works: it's a continuous log of everything issued, and you can't skip entries. If you spot a certificate without an SCT tied to the log, you have dispositive evidence of misissuance, and you kill the CA. You need all the pieces of this system for it to work: not just the log, but the SCTs (which don't exist in the DNSSEC protocol, and which browsers can't compel).
All you're saying at this point is that CT doesn't, in your opinion, matter. But now you're contradicting your own argument, which was, previously, that DNSSEC can easily copy CT to do DNS PKI transparency.
If you wanted something like certificate transparency for a DNS PKI, you wouldn't want an exact copy of WebPKI's CT system as it exists right now. That wouldn't work, obviously! That's not the point at all.
In fact, a certificate transparency-like system for DNS PKI would probably be a lot easier and more scalable to implement, as you'd need to store a log of at most 1 DNSKEY and/or DS records per TLD per day (as per their usual TTL), or much less actually, because those DNSKEYs don't actually change often, I believe.
You don't even need the TLDs' cooperation to do it, as those public keys are publicly available, unlike certificates issued by certificate authorities!
You'd then need a way to check that the keys match what you've got from the upstream DNS server. You could probably implement this at the DNS server and DNSSEC resolver level. You'd return an error if the keys that you've got aren't available in the log. You could discard old keys, so a locally-stored copy of the log would be really small and wouldn't keep growing indefinitely.
The point is, something like this would be doable and has nothing to do with all the other points I've been making which are a lot more important.
You're trying, and failing (you don't have all the available keys, because servers can selectively change their responses) to design a transparency scheme for the DNS PKI, one that does not currently exist, which is deliberately different than Certificate Transparency, now that you've learned that Certificate Transparency won't work for DNSSEC. You've vindicated my argument.
> you don't have all the available keys, because servers can selectively change their responses
Well, that's the entire point of the log, isn't it? To make sure that everybody is seeing the same keys.
If the keys you got from the upstream link in the DNS chain doesn't match the one in the log, you reject them, because you are being spoofed.
> to design a transparency scheme for the DNS PKI, one that does not currently exist, which is deliberately different than Certificate Transparency
> now that you've learned that Certificate Transparency won't work for DNSSEC
It wouldn't work exactly like it is, obviously, which is why I've been saying "CT-like" system, not the exact same CT incantation that exists right now which was explicitly designed for WebPKI, not a DNS PKI.
Your argument is like saying in the year 2002: "electric vehicles can't possibly work because gas stations are not designed for electric vehicles". Well, not exactly a sound argument you have there, now is it? :)
... which only works for browsers. What about all the other uses of certificates?
TLS itself is used for securing almost every network communication that goes over the Internet nowadays, including SMTP (and even DNS with DNS-over-TLS or DoH, ironically).
So how does Mozilla notice that a CA misissued a certificate for my SMTP server or my upstream DNS server? (Answer: it doesn't).
What do you mean, more dependence? How does DANE make a domain more dependent on the TLD owners than they already are?
Specifically, what kind of attack would a TLD owner be able to perform on a domain that uses DANE that they wouldn't be able to perform if the domain weren't using DANE?
> The mass adoption of DNS-over-HTTPS, which is "bottom-up" DNS security that (unlike DNSSEC) protects the "last mile" between browsers and the DNS servers they talk to; in a world where most users talk to just a couple trusted DNS resolvers, all of which speak DoH, DoH might be all the DNS security we need?
Of course those "couple trusted DNS resolvers" (and all the ones operated by enthusiastic "Home labs" types) need to know whether the answers are trustworthy, otherwise we're just centralising the problem not fixing it.
You're a smart person so I'm sure you guessed what the canonical solution is, it's DNSSEC.
> The potential inclusion of RDAP, the successor to Whois, as a mechanism for verifying domain ownership for certificates
This is technology, wishful thinking won't move the bar. ACME RDAP isn't a thing, doesn't appear to have even a draft, don't think it was even discussed. So this "potential" seems rather nebulous. RDAP is a cute trick, it'd be nice if it someday displaces WHOIS properly but it doesn't really have great applicability to this problem.
> explore alternate models with clearer, more realistic trust models.
I have experience with the "Surely anything would be better than this" crowd, they voted for Brexit. You presumably don't need to ask how that's going since I believe in your country they voted for Trump.
This is just begging the question. There's a top-down security model for DNS, where you deploy a global PKI, and there's a bottom-up security model where you protect all the links. If the top-down approach reaches all the leaves, so all lookups are signed and verified, it can succeed. Likewise, if the bottom-up model reaches the roots, it too succeeds: if every link DNS uses is protected, then the only avenues for compromise are outside the scope of the DNS anyways --- in the same way that registrar compromise today, the primary vector for DNS takeovers, is out of scope for DNSSEC.
What you're saying here is, "if you do bottom-up DNS security, all you know is that the links were secure; you still don't know if the data was authentic". Sure, but that's not dispositive, because:
(a) Bottom-up DNS security can continue to succeed to the point where it links resolvers and caches to authority servers
(b) Regardless of whether it does, the costs attackers incur against DoH-protected hosts might be wildly higher than the benefits (the risk-of-failure-adjusted value of a misissuance via a DNS attack).
So, I guess what I'm saying is that it's clear on it's face that there's no "canonical solution" to this problem; there's a solution space. DNSSEC advocates have been telling us for (checks notes) 27-28 years that DNSSEC is "the canonical solution" to DNS security. The information security field has ignored the DNSSEC advocates, and, I'd argue, largely vindicated themselves in that approach.
Britain, for what it's worth, was already a member of the EU when they voted for Brexit. The circumstances of DNSSEC are not similar. It's a weird, inapposite emotional appeal either way, but the premise fails, too.
> (a) Bottom-up DNS security can continue to succeed to the point where it links resolvers and caches to authority servers
Even if that would happen, the client would have no way to know if all the links were indeed secured. And even it would know it, it would have no way to know if any of the resolvers in those links forged a DNS response.
With DNSSEC the client can verify that the response is indeed authentic.
> (b) Regardless of whether it does, the costs attackers incur against DoH-protected hosts might be wildly higher than the benefits (the risk-of-failure-adjusted value of a misissuance via a DNS attack).
Actually, it can be profitable for the DoH-protected hosts themselves to forge DNS responses, no attacker is needed. There are many consumer ISPs that do that already to display advertisements, collect statistics or straight up hijack domain names (e.g. due to piracy laws). DoH does nothing to prevent that, while a client resolver with DNSSEC support does protect against that.
In fact, DNSSEC can work just as well with DoH, which is what I do on my laptop. These two technologies are not mutually exclusive and I see no reason why we can't use both at the same time.
What does it matter if the client knows or doesn't know the whole chain from the resolver to all its peers? There's nothing the client can do about it. DNS data is either hard to spoof (even now, that's the case) or it isn't. This idea that bottom-up DNS security is suspect because the client can't verify the whole chain would be easier to take if it wasn't for the fact that all of DNSSEC security collapses down to a single, resolver-controlled header bit on the link between your browser and your DNS server.
> What does it matter if the client knows or doesn't know the whole chain from the resolver to all its peers? There's nothing the client can do about it.
If the client expected all the links to be secured (which is what you propose with a bottom-up security model) and if it would know whether they are or not, then it could fail to resolve if any link is not currently secured, if the user so desired.
In your bottom-up security model proposal, this would protect against any external man-in-the-middle attack in the entire chain (but not an attacker within the chain).
If the client doesn't know if all links are secured, then it is vulnerable as long as any link in the chain can be attacked (except for its own link), not to mention of course, by attackers within the chain as well. Since it has no way to know whether it was attacked or not, it has no way to prevent forged responses.
> DNS data is either hard to spoof (even now, that's the case)
It's really not hard. Otherwise, this page wouldn't list ongoing cases that affect millions of users right now, every single day:
> if it wasn't for the fact that all of DNSSEC security collapses down to a single, resolver-controlled header bit on the link between your browser and your DNS server.
Maybe on your system, not mine.
If you use a local caching resolver with DNSSEC support (and why wouldn't you, unless you're using a microcontroller with close to zero resources?) then no application on your local system will get a forged response from domains with DNSSEC support (unless it was attacked at the source, origin DNS server or at the TLD level, of course, no way to prevent that), regardless of what your DNS server does or pretends to be doing, or any other DNS server in the chain, or even an external attacker that tries to attack any link in the chain, for that matter.
You could also implement a DNS resolver with DNSSEC support on your browser, if you really wanted. But a local caching resolver is an even more generic solution, as it protects all local applications, not just your browser.
First: the page you're citing talks (1) about stub-to-cache DNS lookups that DNSSEC doesn't protect at all, but DoH does (again: DNSSEC collapses down to the "authenticated data" bit in the ISP-controlled last mile) and (2) about "hijacks" that are actually registrar ATOs.
Second: whatever weird thingy your system does, I respect it, but it is simply not the case that millions of mainstream users are going to run fully recursive DNS caches on their phones and laptops any time soon. People love to point out that they can just run their own DNS server on their Linux box, which is obviously true, because that's how ISPs run DNS servers, too. I'm suitably impressed with your sysop ability, but I don't know what that has to do with Internet security.
> the page you're citing talks (1) about stub-to-cache DNS lookups that DNSSEC doesn't protect at all, but DoH does
Both DNSSEC and DoH can protect against DNS hijacking. DNSSEC can give you end-to-end protection if you use a DNSSEC-enabled resolver and the domain supports DNSSEC, while DoH can only protect one link in the chain, no matter what you do.
> whatever weird thingy your system does, I respect it
What is weird about running a local caching resolver? Most modern Linux systems do that, as far as I know. I simply use one that does DNSSEC verification by default.
I don't see why Android/iOS phones or Windows systems wouldn't be able to do that by default in 2022, if their developers really wanted to implement that.
> it is simply not the case that millions of mainstream users are going to run fully recursive DNS caches on their phones and laptops any time soon.
Not with any attitude: what you and the phone sysadmins propose is, effectively, to eliminate all shared DNS caching from the Internet. A beautiful dream! But that's all it is.
That no mainstream operating system in the world does this is all the evidence I need to dispose of this part of the argument.
> Not with any attitude: what you and the phone sysadmins propose is, effectively, to eliminate all shared DNS caching from the Internet. A beautiful dream! But that's all it is.
No, a local caching resolver (with or without DNSSEC verification enabled by default) would talk to the upstream DNS server by default, like a stub resolver, so it benefits from the upstream DNS server cache.
Nah, what I'm saying is that huge numbers of people, today, trust a DNSSEC verifying DNS server, often one run by Google or Cloudflare, and thanks to DoH that "last mile" connection (from a client to a trusted DNS server) is secured. We're actually more or less done.
It's neither "top down" nor "bottom up", it's horses for courses. (Is that phrase clear? I have a feeling it might not translate but I'm not sure what the equivalent is in American)
> (a) Bottom-up DNS security can continue to succeed to the point where it links resolvers and caches to authority server
From my reading of dnsop the IETF isn't likely to reach consensus on how authoritative traffic should do encryption anytime soon. Remember DoH and DoT for stub to resolver traffic happened because of the browser people, not the DNS people. Unfortunately the browser people don't have the same leverage elsewhere, or we'd have seen more come from the Cloudflare/Facebook DoT experiment by now.
> Slack had a multi-hour total sitewide outage earlier this year that came from attempting to turn it on.
I don't particularly want to defend DNSSEC here but Slack picked Route 53, who both have had and continue to have well known compliance issues with DNS, and they expected them to get DNSSEC right. I'm a little surprised it's gone as well as it has and that they still have DNSSEC on.
Apple's recent revisiting of DNSSEC is possibly the only glimmer of hope for more mainstream adoption of DNSSEC. Their software's got a large installed base and their API is opt-in for DNS consuming software. It'd be nice if more DNSSEC implementations made DNSSEC opt-in but the evangelical DNSSEC set wouldn't abide that.
> I think we've more or less established that a top-down government-controlled PKI is not the future of Internet security. Ending the 26-year DNSSEC boondoggle would free us up to explore alternate models with clearer, more realistic trust models.
I don't think that's clear at all. What is clear is that the DNS hasn't moved much in that period and that the only things that have been adopted are things that authorities and resolvers can silently implement. Putting a fork in DNSSEC won't change much. At this point whatever replaces DNS will be how this space gains some security.
> * The incredibly bad track record DNSSEC has for reliability; for instance, Slack had a multi-hour total sitewide outage earlier this year that came from attempting to turn it on.
It was actually from turning it _off_, relying on expert advice that turned out to be incorrect:
>Our Traffic team was confident that reverting the DS record published in MarkMonitor was sufficient to eventually resolve DNS resolution problems. As things were not getting any better, and given the severity of the incident, we decided to rollback DNSSEC signing in our slack.com authoritative and delegated zones, wanting to recover our DNS configuration to the last previous healthy state, allowing us to completely rule out DNSSEC as a problem.
>As soon as the rollback was pushed out things got much worse; our Traffic team was paged due to DNS resolution issues for slack.com from multiple resolvers across the world.
>Based on expert advice, our understanding at the time was that DS records at the .com zone were never cached, so pulling it from the registrar would cause resolvers to immediately stop performing DNSSEC validation. This assumption turned out to be untrue. The ‘.com.’ zone will ask resolvers to cache the slack.com DS record for 24h by default (non modifiable by zone owners). Luckily, some resolvers cap that TTL with a lower value (i.e. Google’s 8.8.8.8 has a 6h TTL on DS records).
I'm not buying into the whole "top-down government-controlled" argument against the DNS system. Yes, the US has control over ICANN and therefore the root name servers, but the power lies with the configuration of a device's DNS resolver. Any recursive resolver is free to configure other root servers (e.g. OpenNIC). It's currently the ISPs' choice and it more and more transfers over to central resolver like Cloudflare's 1.1.1.1 or Google's 8.8.8.8. Even operating system vendors have a lot of influence on the default settings for DNS resolver (take the ones advertised via DHCP or choose some other ones). Even browsers could choose to look up names directly at a resolver of their choosing instead of relying on the OS. What gets in the way of this are local corporate-wide domains and the like, but there are several ways to deal with this. The main argument I want to make is, that the power over DNS is not as much with the US Government as you might think.
The owner of com. (which is effectively the US govt) can hand out whatever records it likes for anything under .com.
All DNSSEC gives you is a false sense of security as you merrily validate signatures on spoofed records because they're generated by the same people who own the DS record responses.
And what happens when you (and everyone else) finds out you can no longer trust DNSSEC signatures on .com.? Stop using all of .com?
> but the power lies with the configuration of a device's DNS resolver. Any recursive resolver is free to configure other root servers (e.g. OpenNIC).
How does OpenNIC know how to answer the question "where is ycombinator.com"?
> All DNSSEC gives you is a false sense of security as you merrily validate signatures on spoofed records because they're generated by the same people who own the DS record responses.
As opposed to the current system, which also gives you a false sense of security while being vulnerable to exactly the same .COM attack, but also to even more types of attacks?
First of all that doesn't matter, because people trust what DNS does regardless of whether it claims to be secure or not. I've never seen anyone or any software distrust a DNS response unless they already know what it was supposed to be. The only exception I know of is Let's Encrypt, which does check DNS responses from multiple sites around the world to verify that they're the same, something which isn't really a security guarantee, it's just a heuristic. And which practically nobody else does and which normal users aren't capable of doing.
Furthermore, what we build on top of DNS and which is supposed to protect from DNS attacks and does claim to be secure, like the CA PKI system, actually depends on DNS to be secure (which it isn't) in order to obtain the certificates. Not to mention the CA PKI system also depends on all certificates authorities in the entire world to be well-behaved.
Stipulate that you can spoof, for any non-LetsEncrypt CA in the world, any DNS response you want. Pick any CA in the Mozilla trust store that you choose. Spoof a response to verify a MAIL.GOOGLE.COM certificate. What do you think happens next?
What would happen next is that the attacker would succeed in getting his certificate for mail.google.com signed by the CA (remember, there are certificate authorities including Let's Encrypt that sign certificates based on DNS responses alone, but selectively spoofing the A record for the HTTP server would also work).
Presumably the CA would have to have published an entry to the CT log for this certificate. This would allow browsers to verify that the certificate generated by the attacker can be trusted and therefore it could be used by the attacker to perform a man-in-the-middle attack on the Gmail interface against any user in the entire world, without anyone noticing it during the attack.
Some time after the attack has already occurred, Google or someone else would presumably notice that the certificate wasn't actually created by Google, even though everything was correctly published in the CT logs like it was expected for any other normal certificate (I'm being very generous here, multiple companies don't even notice their domains are about to expire until it's too late, including Microsoft).
At this point, it would be expected for browser vendors like Mozilla and Google to distrust this CA because they would assume the CA generated a certificate for a Google domain fraudulently. However, the CA wasn't actually the perpetrator of the attack but it also couldn't prove that it wasn't, and since the browsers don't trust them anymore, the innocent company would be ruined and all their employees would be fired and become miserable.
Meanwhile, hundreds of millions or possibly billions of devices (like Android smartphones) who don't update their system software for months or years (or even never) would still have the now-bankrupt CA in their certificate root stores for a very long time (remember, not all certificate root stores are managed by browsers, some are installed at the OS level), so the attacker could still keep attacking these devices, almost indefinitely, without any issue (especially if he repeats the attack, which he can do indefinitely, ruining many CAs until he somehow got caught).
This is all assuming we're talking about a certificate for an HTTPS server, which is the best case scenario.
If we're talking about a certificate for an SMTP server or a DNS server then the problem is even worse, not in this exact scenario, but in the scenario where one of the many certificate authorities behaves maliciously and generates a fraudulent certificate itself (signing it) but doesn't publish an entry to a CT log, so the attack would never be noticed because SMTP servers and DNS servers don't check SCTs.
There are a lot more mail domains signed with DNSSEC/DANE than with MTA-STS. So using your argument that DNSSEC is dead because no one is using it actually works in DANE's favor in this instance. MTA-STS is dead. DANE ate its lunch.
Once again: there are literally millions of domains signed with DNSSEC because registrars, especially in Europe, auto-sign. That doesn't mean anything. I get that you're probably joking here, but the idea of the 28-year-old DNSSEC project, deployed on less than 4% of .COM and virtually nowhere in the actual industry, declaring victory over an RFC from 2018 is, of course, risible. I assume that was the intention, though.
Can you not mitm the CA's dns lookups for http, tls-alpn challenges and make them sign the certificates for you? How does letsencrypt prevent this? Do they check with multiple resolvers around the world?
We need a better alternative to DNSSEC. Its design is outdated and it's implementations can be very clunky. It's like HTML and Javascript in a way.
However, it's the system we've got. Unless you do some kind of on-the-fly domain generation or an outdated DNS registrar, it's quite easy to enable and it helps prevent all kind of weird DNS malarkey for those that care about their internet security.
1. It's not the system we've got, because we don't got it. Less than 4% of .COM is signed. Virtually no important domains are signed, particularly at the companies with the largest security teams. The root DNSSEC keys could land on Pastebin tonight and nobody would need to be paged.
2. It's not quite easy to enable it. Evidence for that position: the litany of stories where companies have tried to enable it, like Slack did, and had multi-hour worldwide outages as a result.
The worst is, computer clocks drift, and ntp's domains are signed, so if your clock drifts enough, you cannot update your time, because dnssec invaliates time server records.
Good times.
Seen more than one org disable dnnsec, in bind, because of this.
You would have the same issue with TLS or any other scheme. When OpenNTPD added TLS-authenticated constraints, I immediately began having problems on one of my PCEngines APU with a broken RTC (same model as all my other ones, but clock would always reset when power removed, no matter how many times I changed the battery). I had to disable TLS constraints. Eventually they added a special "trusted" qualifier to NTP server directives for bypassing constraint checking.
Authenticated time synchronization faces intrinsic dilemmas no matter the technology.
Hmm - my discord client wasn't updating and I suspected it was something with DNS - tried all kinds of things. Turned dnssec off and BAM! discord immediatel updated.
1. It's the system I've got. 57.8% of .nl domains are validated by DNSSEC, and those are the ones I use and it works great.
2. All I needed to do was enable a checkbox and paste a key (that I generated myself because I didn't want to hit the "generate" button) so I know it can be easy. Most companies aren't Slack or Google with their custom resolver setups and complicated cloud configurations.
DNSSEC doesn't yet support multi-provider DNS solutions and Route53 only recently (little over a year ago) started to support it.
Other note is I've had exactly two people who it prevented from using a site. One was at a coffee shop and another in a hospital where I assume they both were rewriting DNS for some reason.
Last time this was posted, I asked for an example of any real-world incident which would have been prevented by DNSSEC. I have never seen one, but it would be interesting.
P.S. Lots of hypothetical examples were given, but I'd like to see an actual case.
P.P.S. tptacek try to hold your tongue for at least a little bit before piping in with your usual response. :)
With DNSSEC there is an authenticated chain from the root down. Without the private key materials for a delegation a hijacker wouldn't be able to provide appropriate signatures and so resolution would fail.
Do you mean, like all the DNS hijacking attacks listed here, occurring every single day for millions of users spanning multiple countries and including all the consumer ISPs in Indonesia, for example?
DNSSEC gives you end-to-end protection against DNS hijacking if your local resolver does DNSSEC verification and the domain being looked up uses DNSSEC.
All you have to do is install a local resolver like https://www.knot-resolver.cz which does DNSSEC verification by default.
It can be configured to talk to your upstream DNS servers or some other DNS-over-TLS servers if you want (like the Cloudflare DNS servers).
This is the second time you've posted this on the thread. None of this has anything to do with DNSSEC. This is ISPs hijacking DNS for their customers, which DNSSEC doesn't prevent (it's server-to-server, not endpoint-to-server --- the fact that you can run a server on your bespoke Linux machine isn't relevant to the analysis), and registrar ATO.
> This is ISPs hijacking DNS for their customers, which DNSSEC doesn't prevent
It does if you run a local caching resolver with DNSSEC validation which is what I mentioned in the post you replied to.
This caching resolver works as your system resolver, i.e., it sits on your machine and acts as an intermediary between your local apps and the upstream ISP DNS servers to cache responses and also rejects any spoofed DNS response from the upstream ISP as long as the domain has DNSSEC enabled.
You are only considering DNSSEC from the point of view of a stub resolver, which nowadays is more appropriate for a microcontroller-based system rather than a modern system (including things like smartphones, home routers and cheap Raspberry Pi-like machines).
Note that many modern Linux systems and home routers already have caching resolvers, it's just that most of them are not DNSSEC-validating (by default, at least).
running a local resolver that validates DNSSEC is all well and good for the HN crowd, but for the 99.9% of people that do not know what DNS is, let alone what a "stub resolver" is, DNSSEC would be more of a hinderance than help.
also, it'd receive enormous pushback from governments if microsoft/apple were to start validating DNS, as it would prevent them from blocking sites in the most common way, rewriting DNS queries for illegal sites (for example, in australia, we have blocks on various torrent sites like thepiratebay)
> for the 99.9% of people that do not know what DNS is, let alone what a "stub resolver" is, DNSSEC would be more of a hinderance than help
Sorry but I don't follow. The 99.9% of people that do not know what DNS is, don't need to know what DNSSEC is either. It works regardless of whether you know what it is.
All you need is for microsoft/apple to start validating DNS, like you mention below.
> also, it'd receive enormous pushback from governments if microsoft/apple were to start validating DNS, as it would prevent them from blocking sites in the most common way, rewriting DNS queries for illegal sites (for example, in australia, we have blocks on various torrent sites like thepiratebay)
No, because DNSSEC doesn't prevent DNS responses from being blocked, so the governments and ISPs can continue doing that.
DNSSEC validation only prevents responses from being spoofed/forged. The ISP DNS server can still refuse to answer queries if it wants.
DoH is what can prevent DNS queries from being blocked, and DoH has already been implemented in Firefox and Android as far as I know.
Also, DNSSEC and DoH can (and should) be implemented together, they are not mutually exclusive, rather, they complement each other, as DoH by itself doesn't protect against forgeries by the upstream DNS server.
Apparently systemd-resolved, which I think is the DNS resolver used on most modern Linux distros, defaults to DNSSEC=allow-downgrade, which means it will validate DNSSEC if it's working, and disable validation otherwise.
Supposedly this still has some compatibility problems, which is why Fedora (at least) still has DNSSEC=no as the default, overriding the upstream systemd-resolved default.
It would be great to identify and fix the majority of those compatibility problems so that DNSSEC validation could be enabled by default.
Once a large enough mass of users would have DNSSEC validation enabled by default, the incentive would then be on the network operators to fix the remaining compatibility problems, as the users' devices would work just fine on other networks and they would perceive the fault to be on the incompatible network they were using, not on their device.
It's worth noting here that when 'wizeman says "enough users have DNSSEC validation enabled", he's referring to a fictitious state of "DNSSEC validation" where the clients perform full recursive validation up to the roots. No mainstream operating system does that today, so when you look at statistics about the (low but significant) percentage of DNS queries done with validation enabled, bear in mind that all of those queries are done the standard way: the stub resolver does no verification itself, and the DNS server simply communicates back to the resolver that verification was done with the `AD` bit.
Obviously, an ISP can simply flip the `AD` bit in any DNS response it wants to edit.
... by default. Doesn't mean that the software doesn't support it (by simply flipping DNSSEC=no to DNSSEC=yes in resolved.conf). It also doesn't mean they can't switch the default once most compatibility issues are solved.
> Obviously, an ISP can simply flip the `AD` bit in any DNS response it wants to edit.
... which would be rejected by DNSSEC validation in the client.
Besides, many DNSSEC queries are currently validated by trusted DNS servers like Cloudflare's and Google's which don't flip the `AD` bit and can communicate to the clients via a secure protocol like DNS-over-HTTPS (implemented in Firefox and Android) or DNS-over-TLS.
So don't dismiss the value that it already has, even without client-side DNSSEC validation.
I'm not actually an expert on this, so I can't say for sure. I know of only 2 compatibility issues, by order of decreasing importance (IMHO):
1) Some DNS servers don't yet support DNSSEC (presumably including the DNS servers of some ISPs?)
Presumably this could be solved by contacting the admins of the affected DNS servers and asking them to update their DNS server software. I think this is the biggest issue I know of.
2) The hostnames of NTP servers on DNSSEC domains can't be resolved when the client's clock is too out-of-sync.
As another poster mentioned, this is not an inherent problem with DNSSEC, as TLS or any other similar security scheme would have the same problem.
Presumably, until the issue can be solved in some better way, you'd have to have a couple of NTP servers on your config on non-DNSSEC domains or addressed by their IP addresses. For corporate networks, perhaps you could have a trusted NTP server (or servers) with stable clocks (or even GPS clocks) on your private network and address them by IP address.
Maybe it’s not compatibility issue, and DNSSEC doesn’t provide meaningful security improvements, so deploying it increases the risk of breakage without any tangible benefit to the threat model.
This is such a weird analysis. Again: less than 4% of .com is signed. It's not just a question of people updating their server software; it's getting a critical mass of the Internet to reconfigure their DNS, in an environment where the last several years shows well-funded shops blowing themselves up just trying to get this done.
Further: when Apple and Microsoft operating systems rely on the `AD` bit for DNSSEC verification, they are using the protocol as it was designed. That's what the bit is there for. The protocol was designed to trust the link between the OS stub resolver and the DNS server, because it was designed in 1995 when even small networks ran and trusted their own BIND servers.
You can see that this fully-recursive verification thing isn't what the DNSSEC designers want just from the fact that they themselves attempted to solve this problem, over a decade ago, with TSIG (iirc; it might have been a different weirdo DNS subprotocol). There was an actual stub-to-server DNS protocol. Nobody uses it because nobody in the real world cares about DNSSEC.
What you're really saying is that Linux nerds can just run their own DNS servers. They can! But we don't design global Internet security to serve people who want to sysadmin their own phones. It has to work for normal people.
> it's getting a critical mass of the Internet to reconfigure their DNS, in an environment where the last several years shows well-funded shops blowing themselves up just trying to get this done.
You mentioned yourself that DNSSEC can be activated automatically by registries, like what has been done in Europe, so I don't really see that as being an issue.
Sure, you can fuck up if you start messing around with DS records and whatnot, like Slack did (and BTW, they're still using DNSSEC even after experiencing that outage), but once you start messing around with DNS you can also fuck up in many other ways that have nothing to do with DNSSEC. So that is not really a problem with DNSSEC itself.
> The protocol was designed to trust the link between the OS stub resolver and the DNS server, because it was designed in 1995 when even small networks ran and trusted their own BIND servers.
Sure, but we're not in 1995 anymore, so there's no issue with running a resolver with DNSSEC validation at the client level anymore.
> What you're really saying is that Linux nerds can just run their own DNS servers.
No, I'm saying OS manufacturers like Google, Apple and Microsoft can implement DNSSEC validation on the DNS resolvers of their OSes, just like Google implemented DNS-over-HTTPS transport (which also wasn't an option in 1995).
> But we don't design global Internet security to serve people who want to sysadmin their own phones.
Registrars auto-sign the zones that randos create in Europe. They don't fuck with the important zones. That's part of what makes registrar auto-signing so silly.
> Not with any attitude: what you and the phone sysadmins propose is, effectively, to eliminate all shared DNS caching from the Internet. A beautiful dream! But that's all it is.
No, a local caching resolver (with or without DNSSEC verification enabled by default) would talk to the upstream DNS server by default, like a stub resolver, so it benefits from the upstream DNS server cache.
a question on this actually: can i pin for a certain domain a key or a key at a specific date (and all successfull rollovers) in /etc/resolv.conf or with one of the popular caching dnsserver software?
104 comments
[ 4.5 ms ] story [ 180 ms ] thread[1]: https://stats.dnssec-tools.org/
1. The overwhelming majority of those names are meaningless, just as it doesn't change anything about Internet security if I do or don't sign the "paulgra-ham.com" domain I bought on Hover years ago when I was drunk.
2. Registrar signatures are more or less security theater, because those customers aren't even controlling their own keys.
The total adoption of DNSSEC in commercial zones is between 1-4% right now, right?
> 2. Registrar signatures are more or less security theater, because those customers aren't even controlling their own keys.
It would be nifty if DNSSEC (or some superior technology) provided a degree of protection against a compromised registrar, but I don’t think that’s the primary benefit. Of course the registrar can change the DNS data.
DNSSEC purports to secure the transfer of data from the combination of the registrar and the domain owner to the resolver. For example, the combination of DNSSEC and CAA can, in principle, prevent even an arbitrarily privileged attacker on the network from getting a bogus certificate issued. Without DNSSEC, services like Let’s Encrypt rely on a degree or network voodoo to protect against MITM attack.
(Of course, a much simpler and more robust mechanism could accomplish the same goal. For example, there could be a standardized out of band mechanism by which a CA could securely ask a registry for the certificate policy for a domain. Something like this wouldn’t have the admin-screwed-up—and-the-whole-domain-is-down failure modes.)
edit: It looks like RDAP is moderately close to being able to do that out-of-band verification. I wonder if anyone is working on CAA integration with RDAP.
https://blog.majid.info/hsts-preload/
https://news.ycombinator.com/item?id=8894902
[0] https://easydns.com/blog/2015/08/06/for-dnssec/
[1] https://news.ycombinator.com/item?id=29381778
* The increasing salience of multi-perspective verification at CAs (LetsEncrypt won't depend on a single DNS response to domain-validate a certificate request, but will distribute that request to resolvers around the world and make sure they agree with each other).
* The potential inclusion of RDAP, the successor to Whois, as a mechanism for verifying domain ownership for certificates --- instead of doing a weird DNS dance, you can just ask the registrar directly.
* The design and deployment of MTA-STS, the HSTS-style TLS continuity protocol for SMTP; SMTP is basically the final use case for DNSSEC, where DNSSEC can serve as a signaling mechanism to ensure that SMTP connections actually use TLS and aren't negotiated down to plaintext by a MITM. MTA-STS was designed specifically to replace DNSSEC for this use case, by the major email providers.
* The ironic increase in domain takeover attacks --- ironic because they're overwhelmingly (probably universally?) done by compromising registrar accounts rather than playing games with the DNS protocol, such that even after a forklift upgrade to enable DNSSEC, we'd still mostly have the same DNS security problem.
* The mass adoption of DNS-over-HTTPS, which is "bottom-up" DNS security that (unlike DNSSEC) protects the "last mile" between browsers and the DNS servers they talk to; in a world where most users talk to just a couple trusted DNS resolvers, all of which speak DoH, DoH might be all the DNS security we need?
* The rise in BGP4 takeover attacks, which completely bypass name resolution altogether; as these attacks continue to mainstream, they too strike right at the heart of the problem DNSSEC was supposed to solve.
* The incredibly bad track record DNSSEC has for reliability; for instance, Slack had a multi-hour total sitewide outage earlier this year that came from attempting to turn it on. This was predicted --- it's predicted in the "Against DNSSEC" post! --- and it's come to pass: DNSSEC is easy to screw up, easier than TLS, and when you screw DNSSEC up, your site falls of the entire Internet without warnings.
* The success of Certificate Transparency and CA surveillance in the WebPKI, to the point where the largest and most commercially important CAs were actually ripped out of browsers after surveillance systems detected misissuance. Also, the most trusted CA on the Internet in 2022 is... free? The WebPKI of 2022 is just not the WebPKI of 2015.
Against this backdrop, the important thing to know about DNSSEC is that it is simply not widely deployed; you can quickly measure this by taking any list of the top domains (the "Moz 500" is an easy-to-download version) and then feeding it through dig:
That DNSSEC isn't widely deployed doesn't, of course, mean it never will be. But it's important to get a sense of the costs we're talking about: it would be one thing if the work of rolling DNSSEC out had already been done, the costs had been sunk, and we were just trying to extract some value of it. But the opposite is true!I see a much different (and worse) opportunity cost to DNSSEC: if we stick a fork in it, we can get to work on something better. I think we've more or less established that a top-down government-controlled PKI is not the future of Internet security. Maybe DNS is worth protecting anyways! Ending the 26-year DNSSEC boondoggle would free us up to explore alternate models with clearer, more realistic trust models.
At any rate: I feel like the ~8 years since I wrote this post have pretty much totally vindicated my argument. I felt a little like I was going out on a limb when I wrote it. Now I fe...
Just one place to go to for all those TLDs. ccTLD support is hit or miss.
Also good info here: https://about.rdap.org
That doesn't protect against attacks from occurring, it only protects against future attacks from the same people who already attacked (assuming the same people don't create a new CA?).
And when Chrome and Mozilla distrusts a new CA, good luck on updating the certificate chains included in the operating systems of all the devices in the world, especially those that never update (old Android phones? IoT devices?).
> there's no way to revoke .COM
I think there is no need to revoke .COM because .COM can attack any domain within .COM anyway, even with/without DNSSEC and/or with/without CAs? Or what am I missing?
> I think there is no need to revoke .COM because .COM can attack any domain within .COM anyway, even with/without DNSSEC and/or with/without CAs? Or what am I missing?
The point is you don't build a system that assumes DNS is trustworthy, because it isn't.
But the current CA PKI system already assumes DNS is trustworthy, even much more than if you were using DNSSEC-protected DNS PKI system, since it is not only vulnerable to almost all the same attackers/attacks, but it is also vulnerable to many more attackers (since any CA can also do an attack at any time, regardless of any possible future consequences it may experience or not).
If they are caught — and CT has made that very likely, but hijinks like in Kazakhstan sidestep CT.
Why do you seem to always be talking like if DNSSEC is incompatible with other security technologies?
DNSSEC isn't incompatible with DoH either, but you also seem to be implying that we need to only use one or the other?
I'm not trying to be a jerk, I'm just saying, this thing you're talking about doesn't exist. Moreover: it's unlikely ever to exist. CT didn't get rolled out because the CA's wanted CT; I assume they actively detest it (other than LetsEncrypt). CT got rolled out because the browsers required it. The browsers have no leverage to make the DNS PKI do anything, because, once again, they can't revoke .COM.
With WebPKI we have multiple mutually-distrusting parties keeping each other in check. It has become a better system.
It's not more power, it's the same power it already has!
This too-big-to-fail monopolist you're talking about can already hijack your domain, regardless of whatever WebPKI does.
> CAs have been doing shady stuff before CT and there's no reason why they wouldn't resurrect MITM-for-cash business given DANE.
Sorry, but I don't follow. Given DANE, CAs wouldn't even exist.
Unless you're talking about the transition period, which would be strictly better than what we have now, because the not-yet-transitioned domains would use WebPKI like today, while the already-transitioned domains would use DANE which has superior guarantees.
I'm not talking about transition period. DANE makes TLD owners effectively a CAs. The technical details are different, but the role of root-trust-anchored private-key-holding ownership-attesting authority is the same. And unlike WebPKI CAs, browsers can't remove DNSSEC roots for abuse of trust.
DANE is setting up a centralized system ripe for monopolistic abuse, where there are no checks and no consequences for fucking up. This isn't just a technical problem of a protocol for securing packets. It's also a meta problem of ensuring the organizations involved behave in a trustworthy way, even when it would be profitable to cheat, even when NSA and other 3-letter agencies put pressure on them.
And then what? Like you said, browsers can't remove Verisign for abuse of trust, because Verisign isn't part of their roots of trust.
And they can't remove the certificate authority who issued the certificate because 1) the certificate authority is not at fault in that scenario, and 2) Verisign could just use another one to issue a new certificate.
Whatever answer you give here would apply to DANE as well.
> If DANE was used, they could do whatever they want
See above: they can already do whatever they want, so you wouldn't be leaning on them more than you are right now.
> DANE is setting up a centralized system ripe for monopolistic abuse, where there are no checks and no consequences for fucking up.
We already have a centralized system of trust, called the DNS system. It's just that currently it is still relatively insecure (DNSSEC is not widely deployed yet), so we have another fake security layer on top of it (the CA PKI system) which, because it's backed by Google and other organizations that people like so much, for some reason people trust that layer even though its security depends on the security of DNS and is actually even more flawed (since it has even more points of attack).
> DANE is setting up a centralized system ripe for monopolistic abuse, where there are no checks and no consequences for fucking up.
You can implement a CT-like system on top of it which would give you more transparency regarding what certificates are being used (where clients, rather than certificate authorities, would publish new certificate fingerprints to CT logs or even directly to some server managed by the domain owner).
But of course, the real issue is how to deal with Verisign if it starts hijacking domains, but this is already exactly the same problem we have today with the CA PKI system.
You have to understand how CT works before you (a) dismiss it, like someone else did upthread when they claimed CAs can just ignore CT, or (b) assume it trivially ports over to DNS.
[citation needed]
> It only works in the WebPKI because browsers are able to force CAs to participate, by distrusting CAs that don't include SCTs in their signed certificates.
So? In a DNS PKI system, browsers would already distrust ALL CAs. So by that argument, it's in a much better footing to begin with.
What's happening is that you're thinking that in a DNS PKI system, TLD operators like Verisign would be equivalent to certificate authorities.
Except that they wouldn't, because Verisign couldn't create rogue certificates for other TLDs like certificate authorities can. And even if Verisign could create rogue certificates for .COM domains, this is already something that they can do today with the WebPKI system in place, since they can hijack any .COM domain at any time.
And even if Verisign is caught hijacking a domain to create rogue certificates with the WebPKI system, the browsers can't do anything about it, because Verisign is not part of their roots of trust.
So basically, you wouldn't be any worse than today (because Verisign can still attack your domain, regardless) but you'd certainly be much better, because you wouldn't have to keep a database of certificate authorities from all over the world who can create certificates for any domain in the entire world.
Oh, by the way, we're talking about a database of fully-trusted authorities that even if they are caught in any wrongdoing, can never actually be distrusted (like you mention) in hundreds of millions of deployed systems out there who might take months or even years to update, or worse, who never update (Android devices, IoT devices, etc).
All you're saying at this point is that CT doesn't, in your opinion, matter. But now you're contradicting your own argument, which was, previously, that DNSSEC can easily copy CT to do DNS PKI transparency.
In fact, a certificate transparency-like system for DNS PKI would probably be a lot easier and more scalable to implement, as you'd need to store a log of at most 1 DNSKEY and/or DS records per TLD per day (as per their usual TTL), or much less actually, because those DNSKEYs don't actually change often, I believe.
You don't even need the TLDs' cooperation to do it, as those public keys are publicly available, unlike certificates issued by certificate authorities!
You'd then need a way to check that the keys match what you've got from the upstream DNS server. You could probably implement this at the DNS server and DNSSEC resolver level. You'd return an error if the keys that you've got aren't available in the log. You could discard old keys, so a locally-stored copy of the log would be really small and wouldn't keep growing indefinitely.
The point is, something like this would be doable and has nothing to do with all the other points I've been making which are a lot more important.
Well, that's the entire point of the log, isn't it? To make sure that everybody is seeing the same keys.
If the keys you got from the upstream link in the DNS chain doesn't match the one in the log, you reject them, because you are being spoofed.
> to design a transparency scheme for the DNS PKI, one that does not currently exist, which is deliberately different than Certificate Transparency > now that you've learned that Certificate Transparency won't work for DNSSEC
It wouldn't work exactly like it is, obviously, which is why I've been saying "CT-like" system, not the exact same CT incantation that exists right now which was explicitly designed for WebPKI, not a DNS PKI.
Your argument is like saying in the year 2002: "electric vehicles can't possibly work because gas stations are not designed for electric vehicles". Well, not exactly a sound argument you have there, now is it? :)
> You've vindicated my argument.
I highly doubt that :)
TLS itself is used for securing almost every network communication that goes over the Internet nowadays, including SMTP (and even DNS with DNS-over-TLS or DoH, ironically).
So how does Mozilla notice that a CA misissued a certificate for my SMTP server or my upstream DNS server? (Answer: it doesn't).
Specifically, what kind of attack would a TLD owner be able to perform on a domain that uses DANE that they wouldn't be able to perform if the domain weren't using DANE?
Of course those "couple trusted DNS resolvers" (and all the ones operated by enthusiastic "Home labs" types) need to know whether the answers are trustworthy, otherwise we're just centralising the problem not fixing it.
You're a smart person so I'm sure you guessed what the canonical solution is, it's DNSSEC.
> The potential inclusion of RDAP, the successor to Whois, as a mechanism for verifying domain ownership for certificates
This is technology, wishful thinking won't move the bar. ACME RDAP isn't a thing, doesn't appear to have even a draft, don't think it was even discussed. So this "potential" seems rather nebulous. RDAP is a cute trick, it'd be nice if it someday displaces WHOIS properly but it doesn't really have great applicability to this problem.
> explore alternate models with clearer, more realistic trust models.
I have experience with the "Surely anything would be better than this" crowd, they voted for Brexit. You presumably don't need to ask how that's going since I believe in your country they voted for Trump.
What you're saying here is, "if you do bottom-up DNS security, all you know is that the links were secure; you still don't know if the data was authentic". Sure, but that's not dispositive, because:
(a) Bottom-up DNS security can continue to succeed to the point where it links resolvers and caches to authority servers
(b) Regardless of whether it does, the costs attackers incur against DoH-protected hosts might be wildly higher than the benefits (the risk-of-failure-adjusted value of a misissuance via a DNS attack).
So, I guess what I'm saying is that it's clear on it's face that there's no "canonical solution" to this problem; there's a solution space. DNSSEC advocates have been telling us for (checks notes) 27-28 years that DNSSEC is "the canonical solution" to DNS security. The information security field has ignored the DNSSEC advocates, and, I'd argue, largely vindicated themselves in that approach.
Britain, for what it's worth, was already a member of the EU when they voted for Brexit. The circumstances of DNSSEC are not similar. It's a weird, inapposite emotional appeal either way, but the premise fails, too.
Even if that would happen, the client would have no way to know if all the links were indeed secured. And even it would know it, it would have no way to know if any of the resolvers in those links forged a DNS response.
With DNSSEC the client can verify that the response is indeed authentic.
> (b) Regardless of whether it does, the costs attackers incur against DoH-protected hosts might be wildly higher than the benefits (the risk-of-failure-adjusted value of a misissuance via a DNS attack).
Actually, it can be profitable for the DoH-protected hosts themselves to forge DNS responses, no attacker is needed. There are many consumer ISPs that do that already to display advertisements, collect statistics or straight up hijack domain names (e.g. due to piracy laws). DoH does nothing to prevent that, while a client resolver with DNSSEC support does protect against that.
In fact, DNSSEC can work just as well with DoH, which is what I do on my laptop. These two technologies are not mutually exclusive and I see no reason why we can't use both at the same time.
This just isn't a real problem.
If the client expected all the links to be secured (which is what you propose with a bottom-up security model) and if it would know whether they are or not, then it could fail to resolve if any link is not currently secured, if the user so desired.
In your bottom-up security model proposal, this would protect against any external man-in-the-middle attack in the entire chain (but not an attacker within the chain).
If the client doesn't know if all links are secured, then it is vulnerable as long as any link in the chain can be attacked (except for its own link), not to mention of course, by attackers within the chain as well. Since it has no way to know whether it was attacked or not, it has no way to prevent forged responses.
> DNS data is either hard to spoof (even now, that's the case)
It's really not hard. Otherwise, this page wouldn't list ongoing cases that affect millions of users right now, every single day:
https://en.wikipedia.org/wiki/DNS_hijacking
> if it wasn't for the fact that all of DNSSEC security collapses down to a single, resolver-controlled header bit on the link between your browser and your DNS server.
Maybe on your system, not mine.
If you use a local caching resolver with DNSSEC support (and why wouldn't you, unless you're using a microcontroller with close to zero resources?) then no application on your local system will get a forged response from domains with DNSSEC support (unless it was attacked at the source, origin DNS server or at the TLD level, of course, no way to prevent that), regardless of what your DNS server does or pretends to be doing, or any other DNS server in the chain, or even an external attacker that tries to attack any link in the chain, for that matter.
You could also implement a DNS resolver with DNSSEC support on your browser, if you really wanted. But a local caching resolver is an even more generic solution, as it protects all local applications, not just your browser.
Second: whatever weird thingy your system does, I respect it, but it is simply not the case that millions of mainstream users are going to run fully recursive DNS caches on their phones and laptops any time soon. People love to point out that they can just run their own DNS server on their Linux box, which is obviously true, because that's how ISPs run DNS servers, too. I'm suitably impressed with your sysop ability, but I don't know what that has to do with Internet security.
Both DNSSEC and DoH can protect against DNS hijacking. DNSSEC can give you end-to-end protection if you use a DNSSEC-enabled resolver and the domain supports DNSSEC, while DoH can only protect one link in the chain, no matter what you do.
> whatever weird thingy your system does, I respect it
What is weird about running a local caching resolver? Most modern Linux systems do that, as far as I know. I simply use one that does DNSSEC verification by default.
I don't see why Android/iOS phones or Windows systems wouldn't be able to do that by default in 2022, if their developers really wanted to implement that.
> it is simply not the case that millions of mainstream users are going to run fully recursive DNS caches on their phones and laptops any time soon.
Yeah, not with that attitude :)
That no mainstream operating system in the world does this is all the evidence I need to dispose of this part of the argument.
No, a local caching resolver (with or without DNSSEC verification enabled by default) would talk to the upstream DNS server by default, like a stub resolver, so it benefits from the upstream DNS server cache.
It's neither "top down" nor "bottom up", it's horses for courses. (Is that phrase clear? I have a feeling it might not translate but I'm not sure what the equivalent is in American)
From my reading of dnsop the IETF isn't likely to reach consensus on how authoritative traffic should do encryption anytime soon. Remember DoH and DoT for stub to resolver traffic happened because of the browser people, not the DNS people. Unfortunately the browser people don't have the same leverage elsewhere, or we'd have seen more come from the Cloudflare/Facebook DoT experiment by now.
I don't particularly want to defend DNSSEC here but Slack picked Route 53, who both have had and continue to have well known compliance issues with DNS, and they expected them to get DNSSEC right. I'm a little surprised it's gone as well as it has and that they still have DNSSEC on.
Apple's recent revisiting of DNSSEC is possibly the only glimmer of hope for more mainstream adoption of DNSSEC. Their software's got a large installed base and their API is opt-in for DNS consuming software. It'd be nice if more DNSSEC implementations made DNSSEC opt-in but the evangelical DNSSEC set wouldn't abide that.
> I think we've more or less established that a top-down government-controlled PKI is not the future of Internet security. Ending the 26-year DNSSEC boondoggle would free us up to explore alternate models with clearer, more realistic trust models.
I don't think that's clear at all. What is clear is that the DNS hasn't moved much in that period and that the only things that have been adopted are things that authorities and resolvers can silently implement. Putting a fork in DNSSEC won't change much. At this point whatever replaces DNS will be how this space gains some security.
It was actually from turning it _off_, relying on expert advice that turned out to be incorrect:
>Our Traffic team was confident that reverting the DS record published in MarkMonitor was sufficient to eventually resolve DNS resolution problems. As things were not getting any better, and given the severity of the incident, we decided to rollback DNSSEC signing in our slack.com authoritative and delegated zones, wanting to recover our DNS configuration to the last previous healthy state, allowing us to completely rule out DNSSEC as a problem.
>As soon as the rollback was pushed out things got much worse; our Traffic team was paged due to DNS resolution issues for slack.com from multiple resolvers across the world.
>Based on expert advice, our understanding at the time was that DS records at the .com zone were never cached, so pulling it from the registrar would cause resolvers to immediately stop performing DNSSEC validation. This assumption turned out to be untrue. The ‘.com.’ zone will ask resolvers to cache the slack.com DS record for 24h by default (non modifiable by zone owners). Luckily, some resolvers cap that TTL with a lower value (i.e. Google’s 8.8.8.8 has a 6h TTL on DS records).
https://slack.engineering/what-happened-during-slacks-dnssec...
All DNSSEC gives you is a false sense of security as you merrily validate signatures on spoofed records because they're generated by the same people who own the DS record responses.
And what happens when you (and everyone else) finds out you can no longer trust DNSSEC signatures on .com.? Stop using all of .com?
> but the power lies with the configuration of a device's DNS resolver. Any recursive resolver is free to configure other root servers (e.g. OpenNIC).
How does OpenNIC know how to answer the question "where is ycombinator.com"?
As opposed to the current system, which also gives you a false sense of security while being vulnerable to exactly the same .COM attack, but also to even more types of attacks?
Furthermore, what we build on top of DNS and which is supposed to protect from DNS attacks and does claim to be secure, like the CA PKI system, actually depends on DNS to be secure (which it isn't) in order to obtain the certificates. Not to mention the CA PKI system also depends on all certificates authorities in the entire world to be well-behaved.
Presumably the CA would have to have published an entry to the CT log for this certificate. This would allow browsers to verify that the certificate generated by the attacker can be trusted and therefore it could be used by the attacker to perform a man-in-the-middle attack on the Gmail interface against any user in the entire world, without anyone noticing it during the attack.
Some time after the attack has already occurred, Google or someone else would presumably notice that the certificate wasn't actually created by Google, even though everything was correctly published in the CT logs like it was expected for any other normal certificate (I'm being very generous here, multiple companies don't even notice their domains are about to expire until it's too late, including Microsoft).
At this point, it would be expected for browser vendors like Mozilla and Google to distrust this CA because they would assume the CA generated a certificate for a Google domain fraudulently. However, the CA wasn't actually the perpetrator of the attack but it also couldn't prove that it wasn't, and since the browsers don't trust them anymore, the innocent company would be ruined and all their employees would be fired and become miserable.
Meanwhile, hundreds of millions or possibly billions of devices (like Android smartphones) who don't update their system software for months or years (or even never) would still have the now-bankrupt CA in their certificate root stores for a very long time (remember, not all certificate root stores are managed by browsers, some are installed at the OS level), so the attacker could still keep attacking these devices, almost indefinitely, without any issue (especially if he repeats the attack, which he can do indefinitely, ruining many CAs until he somehow got caught).
This is all assuming we're talking about a certificate for an HTTPS server, which is the best case scenario.
If we're talking about a certificate for an SMTP server or a DNS server then the problem is even worse, not in this exact scenario, but in the scenario where one of the many certificate authorities behaves maliciously and generates a fraudulent certificate itself (signing it) but doesn't publish an entry to a CT log, so the attack would never be noticed because SMTP servers and DNS servers don't check SCTs.
However, it's the system we've got. Unless you do some kind of on-the-fly domain generation or an outdated DNS registrar, it's quite easy to enable and it helps prevent all kind of weird DNS malarkey for those that care about their internet security.
2. It's not quite easy to enable it. Evidence for that position: the litany of stories where companies have tried to enable it, like Slack did, and had multi-hour worldwide outages as a result.
Good times.
Seen more than one org disable dnnsec, in bind, because of this.
Authenticated time synchronization faces intrinsic dilemmas no matter the technology.
Sigh.
2. All I needed to do was enable a checkbox and paste a key (that I generated myself because I didn't want to hit the "generate" button) so I know it can be easy. Most companies aren't Slack or Google with their custom resolver setups and complicated cloud configurations.
Other note is I've had exactly two people who it prevented from using a site. One was at a coffee shop and another in a hospital where I assume they both were rewriting DNS for some reason.
P.S. Lots of hypothetical examples were given, but I'd like to see an actual case.
P.P.S. tptacek try to hold your tongue for at least a little bit before piping in with your usual response. :)
https://www.icann.org/en/system/files/files/sac-121-en.pdf
The attackers took over the authoritative DNS servers and answered queries with lies.
https://en.wikipedia.org/wiki/DNS_hijacking
DNSSEC gives you end-to-end protection against DNS hijacking if your local resolver does DNSSEC verification and the domain being looked up uses DNSSEC.
All you have to do is install a local resolver like https://www.knot-resolver.cz which does DNSSEC verification by default.
It can be configured to talk to your upstream DNS servers or some other DNS-over-TLS servers if you want (like the Cloudflare DNS servers).
It does if you run a local caching resolver with DNSSEC validation which is what I mentioned in the post you replied to.
This caching resolver works as your system resolver, i.e., it sits on your machine and acts as an intermediary between your local apps and the upstream ISP DNS servers to cache responses and also rejects any spoofed DNS response from the upstream ISP as long as the domain has DNSSEC enabled.
You are only considering DNSSEC from the point of view of a stub resolver, which nowadays is more appropriate for a microcontroller-based system rather than a modern system (including things like smartphones, home routers and cheap Raspberry Pi-like machines).
Note that many modern Linux systems and home routers already have caching resolvers, it's just that most of them are not DNSSEC-validating (by default, at least).
also, it'd receive enormous pushback from governments if microsoft/apple were to start validating DNS, as it would prevent them from blocking sites in the most common way, rewriting DNS queries for illegal sites (for example, in australia, we have blocks on various torrent sites like thepiratebay)
Sorry but I don't follow. The 99.9% of people that do not know what DNS is, don't need to know what DNSSEC is either. It works regardless of whether you know what it is.
All you need is for microsoft/apple to start validating DNS, like you mention below.
> also, it'd receive enormous pushback from governments if microsoft/apple were to start validating DNS, as it would prevent them from blocking sites in the most common way, rewriting DNS queries for illegal sites (for example, in australia, we have blocks on various torrent sites like thepiratebay)
No, because DNSSEC doesn't prevent DNS responses from being blocked, so the governments and ISPs can continue doing that.
DNSSEC validation only prevents responses from being spoofed/forged. The ISP DNS server can still refuse to answer queries if it wants.
DoH is what can prevent DNS queries from being blocked, and DoH has already been implemented in Firefox and Android as far as I know.
Also, DNSSEC and DoH can (and should) be implemented together, they are not mutually exclusive, rather, they complement each other, as DoH by itself doesn't protect against forgeries by the upstream DNS server.
Supposedly this still has some compatibility problems, which is why Fedora (at least) still has DNSSEC=no as the default, overriding the upstream systemd-resolved default.
It would be great to identify and fix the majority of those compatibility problems so that DNSSEC validation could be enabled by default.
Once a large enough mass of users would have DNSSEC validation enabled by default, the incentive would then be on the network operators to fix the remaining compatibility problems, as the users' devices would work just fine on other networks and they would perceive the fault to be on the incompatible network they were using, not on their device.
Obviously, an ISP can simply flip the `AD` bit in any DNS response it wants to edit.
... by default. Doesn't mean that the software doesn't support it (by simply flipping DNSSEC=no to DNSSEC=yes in resolved.conf). It also doesn't mean they can't switch the default once most compatibility issues are solved.
> Obviously, an ISP can simply flip the `AD` bit in any DNS response it wants to edit.
... which would be rejected by DNSSEC validation in the client.
Besides, many DNSSEC queries are currently validated by trusted DNS servers like Cloudflare's and Google's which don't flip the `AD` bit and can communicate to the clients via a secure protocol like DNS-over-HTTPS (implemented in Firefox and Android) or DNS-over-TLS.
So don't dismiss the value that it already has, even without client-side DNSSEC validation.
You're right, good point. Let's give up on DNSSEC then. :)
1) Some DNS servers don't yet support DNSSEC (presumably including the DNS servers of some ISPs?)
Presumably this could be solved by contacting the admins of the affected DNS servers and asking them to update their DNS server software. I think this is the biggest issue I know of.
2) The hostnames of NTP servers on DNSSEC domains can't be resolved when the client's clock is too out-of-sync.
As another poster mentioned, this is not an inherent problem with DNSSEC, as TLS or any other similar security scheme would have the same problem.
Presumably, until the issue can be solved in some better way, you'd have to have a couple of NTP servers on your config on non-DNSSEC domains or addressed by their IP addresses. For corporate networks, perhaps you could have a trusted NTP server (or servers) with stable clocks (or even GPS clocks) on your private network and address them by IP address.
Further: when Apple and Microsoft operating systems rely on the `AD` bit for DNSSEC verification, they are using the protocol as it was designed. That's what the bit is there for. The protocol was designed to trust the link between the OS stub resolver and the DNS server, because it was designed in 1995 when even small networks ran and trusted their own BIND servers.
You can see that this fully-recursive verification thing isn't what the DNSSEC designers want just from the fact that they themselves attempted to solve this problem, over a decade ago, with TSIG (iirc; it might have been a different weirdo DNS subprotocol). There was an actual stub-to-server DNS protocol. Nobody uses it because nobody in the real world cares about DNSSEC.
What you're really saying is that Linux nerds can just run their own DNS servers. They can! But we don't design global Internet security to serve people who want to sysadmin their own phones. It has to work for normal people.
You mentioned yourself that DNSSEC can be activated automatically by registries, like what has been done in Europe, so I don't really see that as being an issue.
Sure, you can fuck up if you start messing around with DS records and whatnot, like Slack did (and BTW, they're still using DNSSEC even after experiencing that outage), but once you start messing around with DNS you can also fuck up in many other ways that have nothing to do with DNSSEC. So that is not really a problem with DNSSEC itself.
> The protocol was designed to trust the link between the OS stub resolver and the DNS server, because it was designed in 1995 when even small networks ran and trusted their own BIND servers.
Sure, but we're not in 1995 anymore, so there's no issue with running a resolver with DNSSEC validation at the client level anymore.
> What you're really saying is that Linux nerds can just run their own DNS servers.
No, I'm saying OS manufacturers like Google, Apple and Microsoft can implement DNSSEC validation on the DNS resolvers of their OSes, just like Google implemented DNS-over-HTTPS transport (which also wasn't an option in 1995).
> But we don't design global Internet security to serve people who want to sysadmin their own phones.
Fortunately, that's not what I'm proposing.
> It has to work for normal people.
Agreed :)
> Not with any attitude: what you and the phone sysadmins propose is, effectively, to eliminate all shared DNS caching from the Internet. A beautiful dream! But that's all it is.
No, a local caching resolver (with or without DNSSEC verification enabled by default) would talk to the upstream DNS server by default, like a stub resolver, so it benefits from the upstream DNS server cache.