Also, this ignores the main argument against DNSSEC / DANE:
> With DANE, you only have to trust ICANN, the country your TLD resides in, and your DNS service provider. This is far from ideal, but the traditional CA system requires trusting all of those entities and over 600 others.
Those 600 CAs are accountable to browsers -- the bad certificates are detected, and companies which misbehave are kicked out (see StartCom [0] for example).
With DANE, there is no such mechanism. Your TLD provider leaked the key and is denying it? Nothing you (or anyone) can do without losing your domain name. The crypto has been broken and needs upgrades (see SHA-1), but provider does not want to do this? No way to force this.
In the field of cybersecurity, I trust a combination of Mozilla/Apple/Google more than any government agency.
The obvious problem with storing certificate chains in TXT records is that it deeds control over your site cryptography to the government that controls your TLD, and, likely, to the "Five Eyes" IC consortium that probably exerts de facto control over the DNS roots themselves. We don't have to wonder whether governments manipulate the DNS for policy reasons; they do so loudly and proudly. People assume governments can simply suborn CAs directly, but that leads us to our next issue:
A slightly less obvious problem with storing certificate chains in the DNS is that you can't revoke the DNS. You can, in fact, revoke entire chunks of the WebPKI. Not only have Chrome and Mozilla done so before, they did it to the largest and most famous CA. Google cannot revoke .COM; in fact, in practical terms, they can't even leave .COM, because hundreds of millions of users are trained to reach them at .COM.
An even less obvious problem with storing certificate chains in the DNS is that virtually no software --- especially not the low-level library code that everything is built on --- is designed to assume that the DNS can fail for policy reasons. When certificates are for whatever reason rejected, you get a UI flow telling you what's going on. It doesn't do a very good job, but it's better than nothing, which is what you get with DNSSEC: your site silently falling off the Internet, as if it had never existed.
There are other reasons too, but these are some of the high-level ones.
This depends on your threat model. Here is mine, in order of importance:
1. Compromised local network (such as bad public wifi, tampering by ISP)
2. Compromised registrar (DNS or CA)
3. Compromised backbone internet (possibly because of state-level interference)
4. Compromised infrastructure of the website I am visiting
("4" is all the way at the end of the list because if the website is compromised, they likely can get access to DB/web server directly, and DNS/TLS things don't really matter)
So even without HSTS, you are protected against 1 and 3; and, thanks to Certificate Transparency, have a good way to detect 2 (because Let's Encrypt does DNS queries from multiple regions and writes all certificates to CT Log). This is all live and works right now. And the threat of browser removal really causes CA to pay attention to browser security.
Compared to this, the DNSSEC solves 1 (at least so I've heard, the original spec was vulnerable); does not solve 2 and removes all the pressure for registrars to improve; and just gives up on 3 when the state is involved.
Additionally, your "upload a certificate chain" approach sounds like you want to skip using CT, which means that detection of 2 and 3 is also gone.
In the past there were more reasons to use DNSSEC. But now, when Let's Encrypt exists, and the state-endorsed internet interference happens in multiple countries, it simply makes no sense.
DNSSEC absolutely does not solve #1. Between you and your local resolver, DNSSEC collapses down to a single header bit, and while we have made large strides in signature cryptography, we have not yet secured single-bit signatures. Your ISP can trick you simply by flipping the "authenticated data" bit off or on in DNS headers.
Problem #1 is why DoH exists. DoH does a good job at dealing with untrusted local DNS! In fact: it addresses most of the real on-the-wire threats to DNS, full stop. But it has nothing to do with DNSSEC.
I agree that CAs are pretty dumb, but the certificate transparency logs are pretty nice to have. If a certificate must be logged to be used and if the logs are publicly accessible, I have a chance of noticing if someone got a certificate issued for my domain (either by tricking a CA, a nefarious CA, or by compromising DNS).
I don't think I have a chance of noticing if certificates are just TXT records and someone can compromise DNS (especially if it's selective). Maybe if you also require DANE certificates to have certificate transparency records, but automation of ACME is probably simpler than automation of DNS changes.
2. Getting CT working for the WebPKI was a lot of work, done in tandem by a lot of very talented people, and because virtually nobody in the industry uses DNSSEC (go look!), there's no incentive for that work to happen.
There's no question that the IETF could get a working group together to specify a transparency log for DNSSEC... eventually. I'd happily start a pool to bet on how long it would take them to bikeshed it out. But actually getting it deployed to the level of effectiveness that CT has today is a totally different story.
It has been over twenty years of work just getting DNSSEC to the (very bad) place it's at today. We should factor that in when we talk about what DNSSEC can and can't do. A think DNSSEC can't do today: provide transparency logs, like the WebPKI does.
Keep going! It gets funnier as you keep looking. (For those playing the home game, it's just `host -t ds <domain>` to check for DNSSEC; `host -t ds salesforce.com` is what it looks like when you do have DNSSEC enabled.)
To save some trouble: other companies that haven't enabled DNSSEC include Mozilla, Netflix, Stripe, Bank of America, Citigroup, Microsoft, Adobe, Oracle, Amazon, Intel, IBM, Atlassian, Coinbase, Equinix, Datadog, Twilio, Ebay, and Shopify.
Speaking of Salesforce: the chatter is that the real reason Slack enabled DNSSEC briefly is because Salesforce --- their parent company --- already had it enabled, presumably for the same bogus FedRAMP reason.
Cloudflare is probably the most notable DNSSEC user. But then: Cloudflare sells DNSSEC services.
Some more without: mit.edu, harvard.edu, ucla.edu, usc.edu
Some more with: berkeley.edu, stanford.edu, caltech.edu
(Dammit...now I'm curious about what is actually in those records, because the 'host -t ds' output for all of them is 3 apparently decimal numbers, a long hex string, and a short hex strings except for Caltech's, which is missing the final short hex string).
> (Dammit...no I'm curious about what is actually in those records, because the 'host -t ds' output for all of them is 3 apparently decimal numbers, a long hex string, and a short hex strings except for Caltech's, which is missing the final short hex string).
Those are DS records, what host(1) prints is their presentation format [1]:
> The presentation format of the DS record consists of three numbers (key tag, algorithm, and digest type) followed by the digest itself presented in hex
Digest type 1 (as for caltech.edu) is for SHA-1 [2], type 2 (as for stanford.edu) is for SHA-256 [3]. So caltech.edu just uses a shorter hash, and whitespace is allowed in the presentation [4].
FWIW, one can also check and verify that/whether DNSSEC works with delv(1) (similar to dig(1), but with validation).
Nah. That's probably relevant for what Thomas imagines doing, but in reality what CT does is provide independent researchers with an easy way to see anomalies. I've done this a few times, academics have done it here and there, and when there are incidents everybody involved will be staring at crt.sh these days.
There was a recent m.d.s.policy policy change idea about requiring CAs to publish the SHA256s of problem certificates, perhaps as crt.sh links because again, in practice people are going to look at them on crt.sh (but SHA256 because one day crt.sh will go away and it'd be a shame to have opaque database row numbers instead of SHA256)
For example, suppose I find a certificate with a 1024-bit RSA public key issued last Thursday by a particular CA. Before CT if I told m.d.s.policy, you can be 100% sure the CA would say "Oops. But that's the only one, we know what happened and we've definitely fixed it". But with CT, they won't even bother with that lie, because they know a researcher is already running a crt.sh database query to find the others they probably issued. They're going to need to actually find and fix the problem. Ugh. Work.
This was a much bigger problem for the Web PKI than it is for DNS today, which is why CT was built.
Why? Because of "private" systems. For DNS, we're used to not worrying about private systems at all. You probably have or know somebody who has, a Pi-Hole, which deliberately trashes DNS in order to reduce the amount of advertising you see. It can't trash my DNS this way, and it couldn't trash DNS for somebody using say, Google's DoH servers (but when pointed out this actually makes HN readers angry!) so we don't fret about it.
But for the Web PKI "private" systems are a big problem. We don't want a CA selling you a certificate for *.ad-network.example so that you can block their ads "just on your private network". Because we don't trust that it'll stay on your network. Years ago we had a problem where some end users believed "int" was a TLD for internal use, and much worse some CAs believed them. It isn't so of course the certificates for testwww4.int and windows2000dev.int are a big problem even though the people who had them never intended to set up a server claiming to be "testwww4.int" on the public Internet
> For DNS, we're used to not worrying about private systems at all. You probably have or know somebody who has, a Pi-Hole, which deliberately trashes DNS in order to reduce the amount of advertising you see. It can't trash my DNS this way, and it couldn't trash DNS for somebody using say, Google's DoH servers, so we don't fret about it.
Just yesterday, I got banned by gatekeepers at privacyguides.org for pointing out the disconnect between their "must support DNSSEC" stance and the content-blocking scenarios made possible by services like Pi-Hole.
I wish I was as eloquent and convincing as you are.
Indeed. I did change my mind, but I changed my mind to being much less sceptical of the Web PKI partly as a result of the changes Ryan talked about on Thomas' podcast and partly after taking more active part in m.d.s.policy and seeing that it was possible to make a difference.
I remain of the opinion (as do many other people who can't just wish away the problem) that we need DNSSEC, or at least, that we need to do what DNSSEC does and we have DNSSEC so we should just use that. Thomas disagrees fervently, as you have seen.
I think you're wrong about that even in the general sense --- that I don't believe we even need what DNSSEC is trying to accomplish, even if we had a sane design to do it. And I strenuously disagree that the DNSSEC design we have today --- DNSSEC-ter? DNSSEC-quater? --- has a positive risk/benefit. I think we will all be worse off in the unlikely event that it's adopted; we'll be worse off even in the best case of universal adoption where nothing goes wrong except that we're all locked into RSA and ECDSA P-Curve signatures, and I think there are much worse things that are likely to happen.
But I'll do my best to disagree more respectfully! I missed the mark badly downthread, and I'm sorry for that.
> There's no question that the IETF could get a working group together to specify a transparency log for DNSSEC... eventually. I'd happily start a pool to bet on how long it would take them to bikeshed it out.
Don't tempt the IETF...
The ADD group has been working on service bindings for DNS to signal the supported set of secure transports for a DNS server. The DNS Privacy Working Group is working on this topic. And now there is DANCE, attempting to apply DANE for network client authentication. And there’s DNSOP of course. One should never underestimate the potential for the IETF to solve the same problem thirty times in thirty different ways. Just think 'IPv6 Transition Mechanisms' to understand just how well the IETF can explore and standardize every possible option, to the inevitable confusion of all!https://blog.apnic.net/2021/11/18/dns-at-ietf-112/
With WebPKI there are many roots that can MITM you.
With DNSSEC there is only one.
Once we have CT for DNSSEC it will be easier to watch that root and the CA for each label in the domainname on the way to the QName than it is to watch tens of CAs in WebPKI.
Did you accidentally respond to the wrong thread? I do that all the time. The thread you're commenting on is one where the previous commenter suggested that you could mitigate DNSSEC's reliance on a government controlled PKI by substituting your own DNS roots.
I assume this is a response to my 2015 "Against DNSSEC", and that it's here today because Slack published a postmortem of the 5 different ways DNSSEC screwed them over last month, which linked to my post. I stand by what I wrote.
We have another episode coming with a special DNSSEC-relevant guest making the case against Ryan here. :)
(I revere Sleevi and, while I think he's totally wrong about this, I believe he's grudgingly wrong about it, not gleefully wrong like the people who got Slack into this mess.)
In some sense that podcast episode is much more interesting than a 2015 article of course.
The transcript you linked in particular is a giggle if you actually know what's going on because of course it's wrong all over the place in ways somebody who doesn't know can't fix. A few of them are generic (e.g. it's normal for English speakers to say "fifty-two eighty" to mean 5280 and then of course the transcript renders that as 52 80, and it's normal to pronounce ETSI "Etsy") but many more are not (if you know Ryan is saying PKIX then you can recognise that, but if you don't then "Peak X" or indeed "Peacocks" is a fair stab). [Maybe one of the many PKIX implementations should name itself "Peacocks" in the same way that "Secret Rabbit Code" stands out from other Sample Rate Converter libraries]
I assume the transcript is at least human curated to be as coherent as it is, but maybe not.
Ryan doesn't mention it on that podcast because it wasn't official yet, but much of the public role of Ryan (Sleevi) is now played by Ryan (Dickson).
The entire "How to be a Certificate Authority" podcast premise seems to be er, what if the "Honest Achmed" Bugzilla ticket, but a podcast. Which you know, fine but you are very late people - did you already do a "Steamed Hams" episode? Also, I'd be fascinated to hear from anybody, in any sector with auditors, who thinks they're actually getting something like that Affleck / Kendrick movie "The Accountant". Maybe Thomas thinks he's Ben Affleck? I've worked with auditors, both internal and external. They're like a code review from a junior. They might see something you missed but they aren't going to find anything you actually hid. Thus audit is valuable, until it isn't. Should I talk about that?
In fact Thomas has already brought up Symantec so why not, if you go back and look at that, one of the things I highlighted very early there was that Symantec are relying on auditors, and we know auditors are the worst option other than nothing. So, this is the right choice if your alternative was nothing, but Symantec had lots of better alternatives and didn't take them.
And this is one of the many places where I think Thomas is just obviously wrong, he describes CAs as "A force for evil" but er, no. We don't see a lot of evil. Now, honestly I'm not looking for evil, but even if I looked I don't expect to find much. What we see are the usual human failings: Laziness and incompetence. Maybe some greed. But mostly laziness and incompetence. I talked about hiding earlier. Isn't that evil? Nope. Just laziness again. You could fix the problem but it's a lot of work, so lie instead. Not evil, just lazy.
For a technical podcast they're not very helpful but they are funny. Does a human curate them? I'm genuinely curious how automatic or otherwise they are now.
And thanks for trying. Realistically alas being snarky at each other is unlikely to make any difference to whether DNSSEC is more or less successful. Otherwise presumably many of the things we both agree are a good idea would long since be universal...
They are extremely automatic. They're generated from Descript, and they're not just a transcript; in theory, we can edit the podcast by editing that transcript. (We just hired an editor to do this for us, and I'm probably going to start proofing the transcripts --- we definitely don't do that now).
Now that Let's Encrypt and ZeroSSL give (almost) anyone certs if they can add a DNS record or serve a file over HTTP on a domain, your argument against DNSSEC on the grounds of increased government/registry control doesn't really make sense. Given that you can get a cert by controlling DNS now anyway, why not use DNSSEC and DANE rather than just trusting that Let's Encrypt's routes to DNS servers are trustworthy?
Mis-issued certificates are (1) highly visible, (2) revocable, and (3) inherently time-limited. Governments have permanent, de jure control over the DNS hierarchy. My snarky reply to this is usually just "OK, go exploit DNS to get a GMail certificate issued. It's just DNS, you should have no problem."
One of my previous employers was interested in this problem (I'm pretty sure the list of my previous employers is a matter of public record if you're curious enough) and assigned me to look at the actual facts using raw DNS data from the network.
It was clear that somebody (presumably nation state actors, although likely not via the DNS hierarchy itself) tampers with DNS, in particular for military or "civil order" type authorities in certain countries. However, they don't usually bother using this to obtain a Web PKI certificate even though they easily could.
Can you guess why? What they want is credentials. So, hijack DNS answers for the mail server, user likely connects without TLS (or in a "fail open" setup supported by many mail clients so that TLS was abandoned once it didn't work) and you get their credentials - they don't even need to do anything, their mail client probably passively does this every few minutes while they sleep. But even for the web a lot of lay users don't type https://server.name.example/ to reach the site, they just type server.name.example and the redirect secures it... until one day it doesn't. You'd notice. I'd notice. 99% of users would not notice, especially before browsers all added affirmative warnings in the last few years.
Both Let's Encrypt and ZeroSSL participate in Certificate Transparency, so you at least have the detection of unusual certificates.
Let me turn around your question: Now that Let's Encrypt and ZeroSSL give (almost) anyone certs, why should we bother implementing all new system with less features and less accountability?
TLS certificates are not just used for web stuff either, many protocols use TLS. For example in IoT world, MQTT over TLS is common.
One non-TLS-based protocol I can think of is SSH, and I agree that SSHFP does sound useful. But given the limited use case of this, SSH's native certificate support, and how easy it is to pre-fill the known_hosts file, I don't think this feature is worth implementing DNSSEC.
It doesn't seem like there's any reason DANE is incompatible with Certificate Transparency. Support could potentially even be integrated with public revolvers to automatically submit certs to a CT log when a TLSA record is looked up[1]. You can use both DANE and a CA-issued certificate at the same time if you want.
With Let's Encrypt and the CA system, you have to trust Let's Encrypt, the DNS servers[2] Let's Encrypt uses, every router between Let's Encrypt and the DNS servers[2], and in most setups every other CA Mozilla/Google/your OS vendor ships too.
With DANE, you need to trust the people with the keys for the DNS servers[2] still, but you don't have the MITM risk, assuming local validation which is the only thing that makes sense with modern computers.
What features are possible with the CA system but not DANE?
[1]: This would require making a TLS connection to the server since only the hash is in the TLSA record which isn't ideal, but it would be possible.
[2]: I'm talking about the DNS servers needed for recursive resolution, so the root servers, the domain's TLD's namesevers, and the authoritative nameserver for the domain.
There's nothing about DANE that is fundamentally incompatible with Ed25519 signatures. But DANE is going to be an RSA ecosystem for the foreseeable future, because merely saying "DANE should be Ed25519" doesn't accomplish anything, and the installed base of DNS is firmly wedged into RSA (about once a year, Geoff Huston publishes a survey of how much of DNSSEC breaks when you try to use NIST P-curve signatures with it).
And there is a major organizational incompatibility with DANE and CT. The CA's don't do CT because they want to (in fact, many of them actively hate it, for reasons 'tialaramex discusses downthread). They do it because Google and Mozilla forced them to, and because Google and Mozilla will nuke them from the skies if they try to stop. The same is emphatically not the case with the operators of the DNS hierarchy, who are absolutely unaccountable to Google, which cannot revoke or even productively leave .COM.
But, of course, the simplest bit of evidence for an argument about why CT doesn't work with DANE is that CT doesn't work with DANE. The system you're discussing in generalities does not exist. CT works today for the WebPKI.
P-256[1] and P-384[2] just have 2.1% less support than RSA with SHA-256[3] and ed25519 has 15.6% less[4], which isn't ideal, but with client-side validation, which is needed for security and browsers would implement, ed25519 would work fine.
I agree that the CA system is better right now, but I think DANE is conceptually a better solution and with some effort from browser vendors it could easily become a viable alternative. Also, browser vendors don't need to pressure TLDs, they're mostly already set up well enough for DANE to work.
I misunderstood CT (I didn't realize CAs had to submit certificates to logs) but it still should work if:
1) The DNSSEC chain is embedded in the certificate. The problem is there's no standard way of doing so. RFC 9102 defines a serialization format, but not a way to include the chain in a certificate. Chrome had an implementation a while ago, but it was removed and never documented as far as I can tell.
2) SPKI mode is used for the TLSA record. (Using the certificate hash would be impossible.)
3) Someone runs a CT log that accepts certificates verified with DANE and not just ones signed by a (semi-)trusted CA.
Once the DNSSEC-chain-in-certificate problem is solved, Let's Encrypt (or some other CA) could single-handedly solve the rest of the issues by making a new challenge type (dns02?) that is more or less equivalent to dns01 but uses a TLSA record instead of a TXT record. This would allow DANE/CA hybrid certificates that would be in CT logs and be accepted by browsers (and other clients) already, as a stopgap measure. Browsers could then also implement DANE (Potentially using the embedded DNSSEC chain to avoid the DNS lookup, allowing for faster client-side validation and bypassing misbehaving resolvers), removing the need for CAs, and it should all just work.
You don't need to assume anything, since I (author of For DNSSEC) contacted you asking for your input directly. You refused to engage or correct any of the points I debunked in your original post. It's sad that you continue to advocate against securing DNS through podcasts, etc.
If you'd raised any objection to that 2015 article that hadn't been asked and answered in the time between it and your own article, I'd spend more time with it. As it stands, there's nothing I see you saying that I couldn't answer with a link I pulled out of the search bar at the bottom of this page.
If you want me to engage with some argument of yours, you're going to have to be specific about which one it is. I'm not going to spend a bunch of time point-by-pointing it. The only reason any of us are commenting on this story is that DNSSEC spectacularly blew up for Slack, and their writeup of what went down linked my article, which yours is an attempted rebuttal to.
You wrote two weeks ago¹ that you’d rather have Google running the Internet key infrastructure, than the current government-approved solution using multiple key holders from international stakeholders, etc. Do you still stand by this?
Given that Google is ultimately subject to US government jurisdiction, I don't really see how is that any better. Unless of course you're saying that governments are too incompetent to be trusted with operating the core infrastructure reliably.
Governments are indeed too incompetent to be trusted with operating core infrastructure reliably, but that's only part of the argument. You can find the original context of this discussion in the search bar to see what I was saying more precisely.
offtopic a bit - Why does COMCAST insist on handling residential DNS, despite alternates available in the USA ? from what I see at one site in California, the DNS has to come from the local router via IP address, which is directly run by COMCAST.
Offering a recursive DNS server is one of the basic jobs of an ISP intended for regular users.
It's not strictly required, but it makes everyone a lot happier, since most consumer oriented operating systems don't include a recursive resolver (or they're not enabled out of the box). I can't find a changelog for the root hints, but I don't think they change that often. I can see L changed IPs in 2007 (and IPv6 in 2015), D in 2012, H in 2015; B in 2017 (and also 2004); I'm not sure if there were changes before then too, but I'm pretty sure even if you had a really old list from 1991, at least a few of the roots are still there, and you could bootstrap from there.
There's value in a shared, somewhat local cache though. And also value in your ISP doing the recursion without the delay imposed by the last mile physical protocol.
"DNSSEC is vital to the security of the internet." If this is true, I'm curious: in the six years since this post, what attacks or security incidents occurred which could have been prevented by DNSSEC?
Sometimes after a DNSSEC outage, DNSSEC fans will say "see, this is exactly the kind of attack DNSSEC protects us from!" Except there was no attack, just a misconfiguration (easy to do with DNSSEC).
Good question and would be interesting to hear about cases, although at least on-path attacks aren't going to make the news since they don't really reveal any unexpected weaknesses.
But even for off-path attacks, non-DNSSEC cache poisoning countermeasures have everything hanging by a thread and occasionally those fail, eg like this: https://www.bleepingcomputer.com/news/security/dns-cache-poi... - this is not often the easiest way to break into something, but it's not exactly good and robust either.
> Imagine if a DNS cache your computer (the client) had been relying on to lookup bleepingcomputer.com's IP, returned to you an incorrect IP address instead of ours?
A "certificate not valid" error would let me know, or since they don't enable HSTS, in the HTTP downgrade case, my browser would at least show "not secure". Yeah there may be some UI issues but "vital to the security of the internet" this is not.
One of the advantages of DNSSEC, is that it allows you to use DNS as a secure validator for things like public ssh keys (SSHFP records), CA/TLSA records and other data which needs integrity.
Meanwhile, in reality, people already have SSH PKIs that they control themselves (for instance, in order to tie SSH to SSO IdPs), and those PKIs have nothing whatsoever to do with DNSSEC.
"If anything, DNSSEC would allow one to prove that the .ly TLD had published bogus DNS records."
No it wouldn't. If you can force the registry to change name servers records then they can change DS records as well and your new bogus name servers are nicely signed and legit.
I think DNSSEC has potential but its a chicken and egg. So few places use it that its more of a risk than a benefit.
The number one issue I see at the registries I manage happen when someone moves their shiny domain to a new provider who know nothing about DNSSEC, but the previous registrar had it signed. Instant foot gun which of course seems to be working for most places but not all because not that many recursive nameservers are set up to check for dnssec. Its really hard to diagnose if you've never used DNSSEC before.
I agree with all points here. Most anti-DNSSEC talk is just silly, especially if you ignore DANE. The two are separate protocols with separate use cases.
Some of the arguments brought up ("but Libya could pown bit.ly") are complete nonsense because as the TLD owners, they already control EVERYTHING, including who the rightful owner is. With DV certificates like Let's Encrypt the whole idea of CA's somehow stopping the regime from a takeover becomes completely silly. If you want control not to fall in the hands of a foreign military regime, don't host your domain with said military regime.
All this talk reminds me about the strong resistance against HTTPS in browsers. Certificate validation was broken in many browsers just like validation of DNSSEC responses is broken today.
The outages due to DNSSEC Slack reported were all because of buggy software, with buggy software written by Amazon in their last failed rollout. Route 53 was incredibly late to the party, only introducing DNSSEC less than a year ago, so it makes sense that their implementation still contains bugs. I fail to see why this would be DNSSEC's fault.
European TLDs (.no, .cz, .nl, .se) seem to be ahead of the curve on DNSSEC with adoption rates already above 50% and most American TLDs have basically no DNSSEC adoption at all. It'll take a while for DNS to be verifiable with no interest from the major TLDs and no suggested alternatives.
Virtually every outage is because of buggy software. When we evaluate the resilience of protocols, what we're really talking about is how difficult it is to build reliable implementations of those protocols. DNSSEC has a particularly clumsy design (it's heavily encumbered by decisions made by government contractors in the mid-1990s, when it was widely believed that DNS servers simply wouldn't be powerful enough to "do" cryptography).
I'd have a problem with DNSSEC even without the wretched design it has now (it would remain a government-controlled PKI), but the 1990s design is most of what animates me about it.
Our current TLS PKI is already government controlled PKI. Several governments control their own certificate authorities. Perhaps it's better this way because at least it's not just the American government, bit it's hardly an argument against the change.
I don't really see what the "1990s design" argument is all about. If we'd design such a system today, we'd get the same system with maybe some more JSON or a blockchain of sorts, centralised around a few profit-oriented companies. Look at DoH (the version with and without the intermediate proxy server) to see what I mean.
You're right that the idea of assumptions about CPU power for DNS servers are outdated, but with modern software that's hardly a problem. DNS servers already solve this problem in every existing DNSSEC server I know.
Yes, we agree, DNS servers are fully capable of implementing modern cryptography. The problem is that the protocol is designed to assume they can't, and it's a series of creaky workarounds for that fact --- much of DNSSEC's jankiness comes from the protocol requirement for offline-only signers.
But that's the thing, common server software already collapses that part of the protocol into a single operation for the query itself. To enable DNSSEC for most systems, you just tell your nameserver to sign the zone and copy the necessary keys over to your registrar. That's two commands in PowerDNS, one to sign the records and one to fetch the keys. In BIND it requires some manual key generation and config, but that's still hardly a challenge for someone who can manage their own DNS zones. CDS/CDNSKEY can automate the communication with the TLD provider, but that's completely optional.
The real jankiness is hidden away in the bespoke implementations on the backend that are designed to have their own complex DNS logic. Those systems don't need to abide by the weird offline-signing DNSSEC standards at all, because there's no reason for them to be compatible with other servers unless you're glueing your own code to an existing server. The offline signing quirk also actually helps you if you use a master/slave DNS setup because you don't need to set up a complicated multi-keyed DNS system to have many resolvers serve your records; one place signs it, and the other servers just forward the responses.
The client does nothing more complex than validating the chain of trust like we're already doing for every other part of our modern connections, and all the server needs to do is respond with the right records (be it signed responses or signed errors).
Someone not well informed on the matter was rumoured to say that DNSSEC does not work well with ECDSA P-256. This is far from the case. New implementations are increasingly ECDSA, and further bulk rollovers will happen. Many resolvers are not yet ready for EdDSA 25519 or Ed448, so those will not happen in bulk in the short term. Need a few more LTS OS releases that lack Ed25519 support to be phased out before that happens.
It has been said about fundamental science that progress happens one funeral at a time... Something like that is applicable to core infrastructure, it is rarely upgraded, more typically replaced. So the lifecycles are somewhat longer.
In fact ECDSHAP256SHA256(13) will shortly be the most prevalent DNSSEC algorithm, and already has been a few times but for recent algorithm rollovers from the deprecated RSASHA1(7) (90% down from peak and falling) to RSASHA256(8) that temporarily put RSA(8) back in front.
The TLDs have been a bit slower to adopt P256, just 45 so far, but these include e.g. .cz, .br, .ch and .fr. There will be more TLDs switching to ECDSA in 2022.
Trends in eTLD+1 zone (effective TLD + 1, e.g. example.com, example.co.uk, ...) DNSSEC algorithm adoption. The graph plots the number of delegated domains with a given DNSKEY algorithm in the corresponding DS RRset published in the parent (eTLD) zone.
77 comments
[ 0.20 ms ] story [ 147 ms ] threadAlso, this ignores the main argument against DNSSEC / DANE:
> With DANE, you only have to trust ICANN, the country your TLD resides in, and your DNS service provider. This is far from ideal, but the traditional CA system requires trusting all of those entities and over 600 others.
Those 600 CAs are accountable to browsers -- the bad certificates are detected, and companies which misbehave are kicked out (see StartCom [0] for example). With DANE, there is no such mechanism. Your TLD provider leaked the key and is denying it? Nothing you (or anyone) can do without losing your domain name. The crypto has been broken and needs upgrades (see SHA-1), but provider does not want to do this? No way to force this.
In the field of cybersecurity, I trust a combination of Mozilla/Apple/Google more than any government agency.
[0] https://en.wikipedia.org/wiki/StartCom
Anyway, without HSTS, if your resolver is lying you are in bad waters and most (all?) CAs allow validation through dns records already.
I'd much much prefer that as it would not be more insecure than "trusting" hundreds of third parties but would bypass a ton of useless organisations.
A slightly less obvious problem with storing certificate chains in the DNS is that you can't revoke the DNS. You can, in fact, revoke entire chunks of the WebPKI. Not only have Chrome and Mozilla done so before, they did it to the largest and most famous CA. Google cannot revoke .COM; in fact, in practical terms, they can't even leave .COM, because hundreds of millions of users are trained to reach them at .COM.
An even less obvious problem with storing certificate chains in the DNS is that virtually no software --- especially not the low-level library code that everything is built on --- is designed to assume that the DNS can fail for policy reasons. When certificates are for whatever reason rejected, you get a UI flow telling you what's going on. It doesn't do a very good job, but it's better than nothing, which is what you get with DNSSEC: your site silently falling off the Internet, as if it had never existed.
There are other reasons too, but these are some of the high-level ones.
1. Compromised local network (such as bad public wifi, tampering by ISP)
2. Compromised registrar (DNS or CA)
3. Compromised backbone internet (possibly because of state-level interference)
4. Compromised infrastructure of the website I am visiting
("4" is all the way at the end of the list because if the website is compromised, they likely can get access to DB/web server directly, and DNS/TLS things don't really matter)
So even without HSTS, you are protected against 1 and 3; and, thanks to Certificate Transparency, have a good way to detect 2 (because Let's Encrypt does DNS queries from multiple regions and writes all certificates to CT Log). This is all live and works right now. And the threat of browser removal really causes CA to pay attention to browser security.
Compared to this, the DNSSEC solves 1 (at least so I've heard, the original spec was vulnerable); does not solve 2 and removes all the pressure for registrars to improve; and just gives up on 3 when the state is involved.
Additionally, your "upload a certificate chain" approach sounds like you want to skip using CT, which means that detection of 2 and 3 is also gone.
In the past there were more reasons to use DNSSEC. But now, when Let's Encrypt exists, and the state-endorsed internet interference happens in multiple countries, it simply makes no sense.
Problem #1 is why DoH exists. DoH does a good job at dealing with untrusted local DNS! In fact: it addresses most of the real on-the-wire threats to DNS, full stop. But it has nothing to do with DNSSEC.
I don't think I have a chance of noticing if certificates are just TXT records and someone can compromise DNS (especially if it's selective). Maybe if you also require DANE certificates to have certificate transparency records, but automation of ACME is probably simpler than automation of DNS changes.
1. It doesn't exist right now.
2. Getting CT working for the WebPKI was a lot of work, done in tandem by a lot of very talented people, and because virtually nobody in the industry uses DNSSEC (go look!), there's no incentive for that work to happen.
There's no question that the IETF could get a working group together to specify a transparency log for DNSSEC... eventually. I'd happily start a pool to bet on how long it would take them to bikeshed it out. But actually getting it deployed to the level of effectiveness that CT has today is a totally different story.
It has been over twenty years of work just getting DNSSEC to the (very bad) place it's at today. We should factor that in when we talk about what DNSSEC can and can't do. A think DNSSEC can't do today: provide transparency logs, like the WebPKI does.
yes: Cloudflare
no: easyDNS, Google, Apple, Facebook, Wikipedia/media, Twitter, Reddit
I knew DNSSEC wasn't well-deployed, but I didn't realize how little.
To save some trouble: other companies that haven't enabled DNSSEC include Mozilla, Netflix, Stripe, Bank of America, Citigroup, Microsoft, Adobe, Oracle, Amazon, Intel, IBM, Atlassian, Coinbase, Equinix, Datadog, Twilio, Ebay, and Shopify.
Speaking of Salesforce: the chatter is that the real reason Slack enabled DNSSEC briefly is because Salesforce --- their parent company --- already had it enabled, presumably for the same bogus FedRAMP reason.
Cloudflare is probably the most notable DNSSEC user. But then: Cloudflare sells DNSSEC services.
Some more with: berkeley.edu, stanford.edu, caltech.edu
(Dammit...now I'm curious about what is actually in those records, because the 'host -t ds' output for all of them is 3 apparently decimal numbers, a long hex string, and a short hex strings except for Caltech's, which is missing the final short hex string).
Those are DS records, what host(1) prints is their presentation format [1]:
> The presentation format of the DS record consists of three numbers (key tag, algorithm, and digest type) followed by the digest itself presented in hex
Digest type 1 (as for caltech.edu) is for SHA-1 [2], type 2 (as for stanford.edu) is for SHA-256 [3]. So caltech.edu just uses a shorter hash, and whitespace is allowed in the presentation [4].
FWIW, one can also check and verify that/whether DNSSEC works with delv(1) (similar to dig(1), but with validation).
[1] https://datatracker.ietf.org/doc/html/rfc3658#section-2.5
[2] https://datatracker.ietf.org/doc/html/rfc3658#section-5
[3] https://datatracker.ietf.org/doc/html/rfc4509#section-2.1
[4] https://datatracker.ietf.org/doc/html/rfc4034#section-5.3
3. The lack of a standardised DELEGATION_ONLY flag.
work on which was being pursued in the IETF[0] (and included a little shout out to you[1]) but sadly seems to have stagnated.
[0] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-deleg...
[1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-deleg...
There was a recent m.d.s.policy policy change idea about requiring CAs to publish the SHA256s of problem certificates, perhaps as crt.sh links because again, in practice people are going to look at them on crt.sh (but SHA256 because one day crt.sh will go away and it'd be a shame to have opaque database row numbers instead of SHA256)
For example, suppose I find a certificate with a 1024-bit RSA public key issued last Thursday by a particular CA. Before CT if I told m.d.s.policy, you can be 100% sure the CA would say "Oops. But that's the only one, we know what happened and we've definitely fixed it". But with CT, they won't even bother with that lie, because they know a researcher is already running a crt.sh database query to find the others they probably issued. They're going to need to actually find and fix the problem. Ugh. Work.
This was a much bigger problem for the Web PKI than it is for DNS today, which is why CT was built.
Why? Because of "private" systems. For DNS, we're used to not worrying about private systems at all. You probably have or know somebody who has, a Pi-Hole, which deliberately trashes DNS in order to reduce the amount of advertising you see. It can't trash my DNS this way, and it couldn't trash DNS for somebody using say, Google's DoH servers (but when pointed out this actually makes HN readers angry!) so we don't fret about it.
But for the Web PKI "private" systems are a big problem. We don't want a CA selling you a certificate for *.ad-network.example so that you can block their ads "just on your private network". Because we don't trust that it'll stay on your network. Years ago we had a problem where some end users believed "int" was a TLD for internal use, and much worse some CAs believed them. It isn't so of course the certificates for testwww4.int and windows2000dev.int are a big problem even though the people who had them never intended to set up a server claiming to be "testwww4.int" on the public Internet
Just yesterday, I got banned by gatekeepers at privacyguides.org for pointing out the disconnect between their "must support DNSSEC" stance and the content-blocking scenarios made possible by services like Pi-Hole.
I wish I was as eloquent and convincing as you are.
[0] https://github.com/privacyguides/privacyguides.org/discussio...
I remain of the opinion (as do many other people who can't just wish away the problem) that we need DNSSEC, or at least, that we need to do what DNSSEC does and we have DNSSEC so we should just use that. Thomas disagrees fervently, as you have seen.
But I'll do my best to disagree more respectfully! I missed the mark badly downthread, and I'm sorry for that.
Don't tempt the IETF...
The ADD group has been working on service bindings for DNS to signal the supported set of secure transports for a DNS server. The DNS Privacy Working Group is working on this topic. And now there is DANCE, attempting to apply DANE for network client authentication. And there’s DNSOP of course. One should never underestimate the potential for the IETF to solve the same problem thirty times in thirty different ways. Just think 'IPv6 Transition Mechanisms' to understand just how well the IETF can explore and standardize every possible option, to the inevitable confusion of all! https://blog.apnic.net/2021/11/18/dns-at-ietf-112/
Incorrect. You can sign your own root zone anytime you like, and we could see alt-roots if the root misbehaves.
With WebPKI there are many roots that can MITM you.
With DNSSEC there is only one.
Once we have CT for DNSSEC it will be easier to watch that root and the CA for each label in the domainname on the way to the QName than it is to watch tens of CAs in WebPKI.
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
[1] transcript (search for DNSSEC or DANE): https://securitycryptographywhatever.buzzsprout.com/1822302/...
(I revere Sleevi and, while I think he's totally wrong about this, I believe he's grudgingly wrong about it, not gleefully wrong like the people who got Slack into this mess.)
The transcript you linked in particular is a giggle if you actually know what's going on because of course it's wrong all over the place in ways somebody who doesn't know can't fix. A few of them are generic (e.g. it's normal for English speakers to say "fifty-two eighty" to mean 5280 and then of course the transcript renders that as 52 80, and it's normal to pronounce ETSI "Etsy") but many more are not (if you know Ryan is saying PKIX then you can recognise that, but if you don't then "Peak X" or indeed "Peacocks" is a fair stab). [Maybe one of the many PKIX implementations should name itself "Peacocks" in the same way that "Secret Rabbit Code" stands out from other Sample Rate Converter libraries]
I assume the transcript is at least human curated to be as coherent as it is, but maybe not.
Ryan doesn't mention it on that podcast because it wasn't official yet, but much of the public role of Ryan (Sleevi) is now played by Ryan (Dickson).
The entire "How to be a Certificate Authority" podcast premise seems to be er, what if the "Honest Achmed" Bugzilla ticket, but a podcast. Which you know, fine but you are very late people - did you already do a "Steamed Hams" episode? Also, I'd be fascinated to hear from anybody, in any sector with auditors, who thinks they're actually getting something like that Affleck / Kendrick movie "The Accountant". Maybe Thomas thinks he's Ben Affleck? I've worked with auditors, both internal and external. They're like a code review from a junior. They might see something you missed but they aren't going to find anything you actually hid. Thus audit is valuable, until it isn't. Should I talk about that?
In fact Thomas has already brought up Symantec so why not, if you go back and look at that, one of the things I highlighted very early there was that Symantec are relying on auditors, and we know auditors are the worst option other than nothing. So, this is the right choice if your alternative was nothing, but Symantec had lots of better alternatives and didn't take them.
And this is one of the many places where I think Thomas is just obviously wrong, he describes CAs as "A force for evil" but er, no. We don't see a lot of evil. Now, honestly I'm not looking for evil, but even if I looked I don't expect to find much. What we see are the usual human failings: Laziness and incompetence. Maybe some greed. But mostly laziness and incompetence. I talked about hiding earlier. Isn't that evil? Nope. Just laziness again. You could fix the problem but it's a lot of work, so lie instead. Not evil, just lazy.
Here's an example picked quickly:
"this became, what's known as lid peacocks. And so lippy kicks is, like six layers of sea macros"
Did Ryan say that on your podcast? No? Because he was talking about libPKIX.
And thanks for trying. Realistically alas being snarky at each other is unlikely to make any difference to whether DNSSEC is more or less successful. Otherwise presumably many of the things we both agree are a good idea would long since be universal...
It was clear that somebody (presumably nation state actors, although likely not via the DNS hierarchy itself) tampers with DNS, in particular for military or "civil order" type authorities in certain countries. However, they don't usually bother using this to obtain a Web PKI certificate even though they easily could.
Can you guess why? What they want is credentials. So, hijack DNS answers for the mail server, user likely connects without TLS (or in a "fail open" setup supported by many mail clients so that TLS was abandoned once it didn't work) and you get their credentials - they don't even need to do anything, their mail client probably passively does this every few minutes while they sleep. But even for the web a lot of lay users don't type https://server.name.example/ to reach the site, they just type server.name.example and the redirect secures it... until one day it doesn't. You'd notice. I'd notice. 99% of users would not notice, especially before browsers all added affirmative warnings in the last few years.
Let me turn around your question: Now that Let's Encrypt and ZeroSSL give (almost) anyone certs, why should we bother implementing all new system with less features and less accountability?
One non-TLS-based protocol I can think of is SSH, and I agree that SSHFP does sound useful. But given the limited use case of this, SSH's native certificate support, and how easy it is to pre-fill the known_hosts file, I don't think this feature is worth implementing DNSSEC.
With Let's Encrypt and the CA system, you have to trust Let's Encrypt, the DNS servers[2] Let's Encrypt uses, every router between Let's Encrypt and the DNS servers[2], and in most setups every other CA Mozilla/Google/your OS vendor ships too.
With DANE, you need to trust the people with the keys for the DNS servers[2] still, but you don't have the MITM risk, assuming local validation which is the only thing that makes sense with modern computers.
What features are possible with the CA system but not DANE?
[1]: This would require making a TLS connection to the server since only the hash is in the TLSA record which isn't ideal, but it would be possible.
[2]: I'm talking about the DNS servers needed for recursive resolution, so the root servers, the domain's TLD's namesevers, and the authoritative nameserver for the domain.
And there is a major organizational incompatibility with DANE and CT. The CA's don't do CT because they want to (in fact, many of them actively hate it, for reasons 'tialaramex discusses downthread). They do it because Google and Mozilla forced them to, and because Google and Mozilla will nuke them from the skies if they try to stop. The same is emphatically not the case with the operators of the DNS hierarchy, who are absolutely unaccountable to Google, which cannot revoke or even productively leave .COM.
But, of course, the simplest bit of evidence for an argument about why CT doesn't work with DANE is that CT doesn't work with DANE. The system you're discussing in generalities does not exist. CT works today for the WebPKI.
I agree that the CA system is better right now, but I think DANE is conceptually a better solution and with some effort from browser vendors it could easily become a viable alternative. Also, browser vendors don't need to pressure TLDs, they're mostly already set up well enough for DANE to work.
I misunderstood CT (I didn't realize CAs had to submit certificates to logs) but it still should work if:
1) The DNSSEC chain is embedded in the certificate. The problem is there's no standard way of doing so. RFC 9102 defines a serialization format, but not a way to include the chain in a certificate. Chrome had an implementation a while ago, but it was removed and never documented as far as I can tell.
2) SPKI mode is used for the TLSA record. (Using the certificate hash would be impossible.)
3) Someone runs a CT log that accepts certificates verified with DANE and not just ones signed by a (semi-)trusted CA.
Once the DNSSEC-chain-in-certificate problem is solved, Let's Encrypt (or some other CA) could single-handedly solve the rest of the issues by making a new challenge type (dns02?) that is more or less equivalent to dns01 but uses a TLSA record instead of a TXT record. This would allow DANE/CA hybrid certificates that would be in CT logs and be accepted by browsers (and other clients) already, as a stopgap measure. Browsers could then also implement DANE (Potentially using the embedded DNSSEC chain to avoid the DNS lookup, allowing for faster client-side validation and bypassing misbehaving resolvers), removing the need for CAs, and it should all just work.
[1]: https://dnsthought.nlnetlabs.nl/#ecdsa256
[2]: https://dnsthought.nlnetlabs.nl/#ecdsa384
[3]: https://dnsthought.nlnetlabs.nl/#rsasha256
[4]: https://dnsthought.nlnetlabs.nl/#ed25519
https://news.ycombinator.com/item?id=10019029
It's sad that advocating for Internet security requires advocating against a major DNS security protocol, but that's the way the cookie bounces.
If you want me to engage with some argument of yours, you're going to have to be specific about which one it is. I'm not going to spend a bunch of time point-by-pointing it. The only reason any of us are commenting on this story is that DNSSEC spectacularly blew up for Slack, and their writeup of what went down linked my article, which yours is an attempted rebuttal to.
1. https://news.ycombinator.com/item?id=29217434
It's not strictly required, but it makes everyone a lot happier, since most consumer oriented operating systems don't include a recursive resolver (or they're not enabled out of the box). I can't find a changelog for the root hints, but I don't think they change that often. I can see L changed IPs in 2007 (and IPv6 in 2015), D in 2012, H in 2015; B in 2017 (and also 2004); I'm not sure if there were changes before then too, but I'm pretty sure even if you had a really old list from 1991, at least a few of the roots are still there, and you could bootstrap from there.
There's value in a shared, somewhat local cache though. And also value in your ISP doing the recursion without the delay imposed by the last mile physical protocol.
dig +dnssec nsa.gov
But even for off-path attacks, non-DNSSEC cache poisoning countermeasures have everything hanging by a thread and occasionally those fail, eg like this: https://www.bleepingcomputer.com/news/security/dns-cache-poi... - this is not often the easiest way to break into something, but it's not exactly good and robust either.
> Imagine if a DNS cache your computer (the client) had been relying on to lookup bleepingcomputer.com's IP, returned to you an incorrect IP address instead of ours?
A "certificate not valid" error would let me know, or since they don't enable HSTS, in the HTTP downgrade case, my browser would at least show "not secure". Yeah there may be some UI issues but "vital to the security of the internet" this is not.
No it wouldn't. If you can force the registry to change name servers records then they can change DS records as well and your new bogus name servers are nicely signed and legit.
I think DNSSEC has potential but its a chicken and egg. So few places use it that its more of a risk than a benefit.
The number one issue I see at the registries I manage happen when someone moves their shiny domain to a new provider who know nothing about DNSSEC, but the previous registrar had it signed. Instant foot gun which of course seems to be working for most places but not all because not that many recursive nameservers are set up to check for dnssec. Its really hard to diagnose if you've never used DNSSEC before.
Some of the arguments brought up ("but Libya could pown bit.ly") are complete nonsense because as the TLD owners, they already control EVERYTHING, including who the rightful owner is. With DV certificates like Let's Encrypt the whole idea of CA's somehow stopping the regime from a takeover becomes completely silly. If you want control not to fall in the hands of a foreign military regime, don't host your domain with said military regime.
All this talk reminds me about the strong resistance against HTTPS in browsers. Certificate validation was broken in many browsers just like validation of DNSSEC responses is broken today.
The outages due to DNSSEC Slack reported were all because of buggy software, with buggy software written by Amazon in their last failed rollout. Route 53 was incredibly late to the party, only introducing DNSSEC less than a year ago, so it makes sense that their implementation still contains bugs. I fail to see why this would be DNSSEC's fault.
European TLDs (.no, .cz, .nl, .se) seem to be ahead of the curve on DNSSEC with adoption rates already above 50% and most American TLDs have basically no DNSSEC adoption at all. It'll take a while for DNS to be verifiable with no interest from the major TLDs and no suggested alternatives.
I'd have a problem with DNSSEC even without the wretched design it has now (it would remain a government-controlled PKI), but the 1990s design is most of what animates me about it.
I don't really see what the "1990s design" argument is all about. If we'd design such a system today, we'd get the same system with maybe some more JSON or a blockchain of sorts, centralised around a few profit-oriented companies. Look at DoH (the version with and without the intermediate proxy server) to see what I mean.
You're right that the idea of assumptions about CPU power for DNS servers are outdated, but with modern software that's hardly a problem. DNS servers already solve this problem in every existing DNSSEC server I know.
The real jankiness is hidden away in the bespoke implementations on the backend that are designed to have their own complex DNS logic. Those systems don't need to abide by the weird offline-signing DNSSEC standards at all, because there's no reason for them to be compatible with other servers unless you're glueing your own code to an existing server. The offline signing quirk also actually helps you if you use a master/slave DNS setup because you don't need to set up a complicated multi-keyed DNS system to have many resolvers serve your records; one place signs it, and the other servers just forward the responses.
The client does nothing more complex than validating the chain of trust like we're already doing for every other part of our modern connections, and all the server needs to do is respond with the right records (be it signed responses or signed errors).
It has been said about fundamental science that progress happens one funeral at a time... Something like that is applicable to core infrastructure, it is rarely upgraded, more typically replaced. So the lifecycles are somewhat longer.
In fact ECDSHAP256SHA256(13) will shortly be the most prevalent DNSSEC algorithm, and already has been a few times but for recent algorithm rollovers from the deprecated RSASHA1(7) (90% down from peak and falling) to RSASHA256(8) that temporarily put RSA(8) back in front.
The supremacy of RSA(8) over EC(13) is not for long: <https://stats.dnssec-tools.org/images/ksk-algs.png>. A month ago there was a 1.2M zone gap, it is now down to ~150k, and will soon be gone.
The TLDs have been a bit slower to adopt P256, just 45 so far, but these include e.g. .cz, .br, .ch and .fr. There will be more TLDs switching to ECDSA in 2022.
<https://dnssec-stats.ant.isi.edu/~viktor/algs-ds.png>