9 ms·

For DNSSEC (2015)

39 points by ca98am79 5y ago

IvyMike 5y ago
"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?
- tptacek 5y ago
  Zero. It is literally the case that you could publish the DNSSEC root keys to Pastebin tonight and almost nobody would even need to be paged.
  - Panino 5y ago
    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).
  - IvyMike 5y ago
    I should have added "question is for people who support the given statement". :)
- fulafel 5y ago
  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-poisoning-attacks-return-due-to-linux-weakness/ 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.
  - IvyMike 5y ago
    The article asks: > 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.
    - deleted 5y ago
      [deleted]
theamk 5y ago
Can we have [2015] in the title? 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. [0] https://en.wikipedia.org/wiki/StartCom https://en.wikipedia.org/wiki/StartCom
- Eikon 5y ago
  The CA system for TLS certificates is really dumb. Why can't we just upload a certificate chain as a TXT field in some DNS entry? 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.
  - tptacek 5y ago
    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.
tptacek 5y ago
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. https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/
- DyslexicAtheist 5y ago
  Much enjoyed your episode on CA's with Ryan Sleevie that talked quite a bit about DANE/DNSSEC. You're doing gods work here! [1] transcript (search for DNSSEC or DANE): https://securitycryptographywhatever.buzzsprout.com/1822302/9146390-how-to-be-a-certificate-authority-feat-ryan-sleevi https://securitycryptographywhatever.buzzsprout.com/1822302/...
  - tialaramex 5y ago
    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.
comprev 5y ago
Needs [2015]
deleted 5y ago
[deleted]
mistrial9 5y ago
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.
- detaro 5y ago
  what do you mean by "insist"? Do they use their DNS as a default in their routers? Do they block access to other DNS servers? ...
- toast0 5y ago
  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.
peppermint_tea 5y ago
Good arguments on both side, but personally, i'll keep on using it and I would really like my bank to do the same... :( dig +dnssec nsa.gov
kazen44 5y ago
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.
- tptacek 5y ago
  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.
elp 5y ago
"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.
jeroenhd 5y ago
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.
- tptacek 5y ago
  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.
  - jeroenhd 5y ago
    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.
ietf-dane 5y ago
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 supremacy of RSA(8) over EC(13) is not for long: <https://stats.dnssec-tools.org/images/ksk-algs.png 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.
- ietf-dane 5y ago
  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. <https://dnssec-stats.ant.isi.edu/~viktor/algs-ds.png https://dnssec-stats.ant.isi.edu/~viktor/algs-ds.png>

For DNSSEC (2015)

39 points by ca98am79 5y ago

"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?

tptacek 5y ago
Zero. It is literally the case that you could publish the DNSSEC root keys to Pastebin tonight and almost nobody would even need to be paged.
- Panino 5y ago
  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).
- IvyMike 5y ago
  I should have added "question is for people who support the given statement". :)
fulafel 5y ago
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-poisoning-attacks-return-due-to-linux-weakness/ 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.
- IvyMike 5y ago
  The article asks: > 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.
  - deleted 5y ago
    [deleted]

theamk 5y ago

Can we have [2015] in the title? 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. [0] https://en.wikipedia.org/wiki/StartCom https://en.wikipedia.org/wiki/StartCom

Eikon 5y ago
The CA system for TLS certificates is really dumb. Why can't we just upload a certificate chain as a TXT field in some DNS entry? 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.
- tptacek 5y ago
  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.

tptacek 5y ago

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. https://sockpuppet.org/blog/2015/01/15/against-dnssec/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/

DyslexicAtheist 5y ago
Much enjoyed your episode on CA's with Ryan Sleevie that talked quite a bit about DANE/DNSSEC. You're doing gods work here! [1] transcript (search for DNSSEC or DANE): https://securitycryptographywhatever.buzzsprout.com/1822302/9146390-how-to-be-a-certificate-authority-feat-ryan-sleevi https://securitycryptographywhatever.buzzsprout.com/1822302/...
- tialaramex 5y ago
  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.

comprev 5y ago

Needs [2015]

deleted 5y ago

[deleted]

mistrial9 5y ago

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.

detaro 5y ago
what do you mean by "insist"? Do they use their DNS as a default in their routers? Do they block access to other DNS servers? ...
toast0 5y ago
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.

peppermint_tea 5y ago

Good arguments on both side, but personally, i'll keep on using it and I would really like my bank to do the same... :( dig +dnssec nsa.gov

kazen44 5y ago

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.

tptacek 5y ago
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.

elp 5y ago

"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.

jeroenhd 5y ago

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.

tptacek 5y ago
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.
- jeroenhd 5y ago
  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.

ietf-dane 5y ago

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 supremacy of RSA(8) over EC(13) is not for long: <https://stats.dnssec-tools.org/images/ksk-algs.png 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.

ietf-dane 5y ago
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. <https://dnssec-stats.ant.isi.edu/~viktor/algs-ds.png https://dnssec-stats.ant.isi.edu/~viktor/algs-ds.png>