My Logs, for the last 30 days, domains validated with DNSSEC was 5.34%.
In general, it feels that ISPs like to be slow adopting standards, e.g. IPv6 it is still rolling.
And (I'm ninja-editing this in, so sorry if I caught you while replying), as you noted, much of the growth in .COM signings is attributable to Cloudflare auto-signing --- which is the same thing that is happening in places like .NL. But registrars auto-signing domains is security theater. Ironically: attacks against registrars are far more common than attacks on the DNS protocol itself; the recent spate of "DNS attacks" from the end of last year turned out to have been phishing attacks.
Your same argument seems to imply that since we have good TLS on many protocols, we shouldn't be too heartbroken about people stealing traffic with BGP, either.
And every new deployment of 1990s-grade DNSSEC makes that problem harder.
If we started from scratch, the very first thing that would change would be the notion that cryptography is too expensive to support online signing, which is one of the two original sins of DNSSEC. The entire protocol would be drastically cleaner, easier to deploy, and, of course, much more secure.
This is not the core argument I have against DNSSEC (for that, just Google [against DNSSEC]). But it's a good one. What they say about PHP holds true for DNSSEC: it's a fractal of bad design.
I don't know what BGP has to do with any of this except to say that DNSSEC obviously doesn't do anything to prevent BGP hijacking attacks; attackers who control BGP control IP addresses, the things DNS maps in the first place.
I'm doing my best to keep these responses varied and interesting, because an HN search will show this is an argument I've made here a lot. Hopefully I'm doing an OK job of that.
Root zone has been signed with 2048 bit keys since 2016. Large numbers of domains are signed with 2048 bit keys, too.
> If we started from scratch, the very first thing that would change would be the notion that cryptography is too expensive to support online signing, which is one of the two original sins of DNSSEC.
Online signing still looks really expensive. Asking an authoritative server to do a 2048 bit signature per answer is costly, given the other conversation you've followed me into and argued basically the other side of. Especially since work you do to make DNS authoritative servers verify things is easily used for DOS, unlike work done for prefix verification in BGP).
> don't know what BGP has to do with any of this
Because we're in a thread talking about preventing BGP hijacking of prefixes with crypto, and the tangential discussion of preventing DNS hijacking of names with crypto (DNSSEC) came up. Some arguments you presented against caring about DNS security work equally well wrt: caring about BGP security--- who cares if someone intercepts our traffic, we're probably using TLS!
That the root zone was signed with 1024-bit RSA in 2016 is its own dunk, and I think you for making it for me, but of course the root zone isn't the only zone; the 1024-bit root just meant every TLD was capped at that level of security. Now they're not, but the rest of the DNS is still littered with them. See: every DNSSEC survey.
And, of course, you've addressed only a small part of that previous argument --- just the key sizes.
I don't know what point you're trying to make about BGP. I think you think I'm opposed to RPKI. I'm not.
I agree DNSSEC isn't wonderful, but perfect is the enemy of good. I'd take 768 bit RSA over "doing nothing"-- it raises the difficulty level of a successful DNS attack enormously.
Some of us don't care about enumeration. If we do, there's whitelies, as you say, and eventually NSEC5 will be around.
> I don't know what point you're trying to make about BGP. I think you think I'm opposed to RPKI. I'm not.
You argued earlier that worrying so much about redirection isn't justified: "Say we protect DNS (we could, with a better protocol design). But other redirection protocols aren't protected. Do we similarly authenticate OSPF? IP options? ARP?"
In which case, maybe we should just ignore RPKI, too. :P And unfix source routing, not bother with SEND, etc.
Further evidence on this is easily obtained both from survey papers that collect DNSSEC misconfiguration statistics (they're hilarious) and from the IANIX collection; many of the organizations IANIX notes are extraordinarily clueful operators.
I'm right about this. It's feasible to get DNSSEC deployed globally (it would be a catastrophe, but we indeed have the tools to make that catastrophe happen). But it would be very, very expensive.
This has been a fun thread, but we are way into the right margin now and are probably the only two people reading it, so I suggest we tie it off at whatever your next response is.