I can field this one. DNSSEC was conceived with support for a traditional zone transfer process. When you edit the zone, you sign it once (potentially offline) and send it via zone transfer to all your authoritative servers. In that context, the authoritative servers can't do things like serve the best A or whatever record given the recursive resolver contacting them and global state. Instead, you generally end up with your keys online on all the authoritative servers. Which means if your DNS account is hacked, chances are, the hackers are in a position to change your records. If your registrar account is hacked, the hackers are certainly able to remove or replace the DS records at the registry, so DNSSEC doesn't help there either (good auth at the registry and registrar and maybe registry lock help there).

DNSSEC might help with MITM, if you only communicate with recursive resolvers you trust to properly implement it and not sneak in any garbage, but it doesn't help against account compromise.

> serve the best A

Well, you have to serve them all and let the client decide what to use, like with MX or SRV. Too bad HTTP is stuck in time and can't get any proper functionality.

And yes, I mean it is literally too bad. Why can HTTP hold 3 current standards at the same time, but still fail to work with basic internet infrastructure?

Are we at the point of desperation in the death gasps of DNSSEC where its advocates are now blaming other protocols for not rearchitecting the way they use the DNS to make it DNSSEC more viable? Because: nobody was ever going to do that.

I sometimes wonder that too. There are tons of simple things HTTP and web browsers could implement to make everyone's life better and easier. Make redundancy built-in, for example, or a primitive peer-to-peer content delivery for stuff like videos. But then I remember that megacorps always want to keep competition out, make everyone invest a lot into crappy traditional infrastructure to compete. They can't allow a competing alternative to work on many orders of magnitude cheaper infrastructure, they are only interested in increasing that cost for everyone and at such pace that nobody can keep up.

I think it means 'if you have a hacked DNS server that has all kinds of custom code to talk to databases, or other resources, then you will find that off the self DNS servers with DNSSEC will not support your hacks'.

Note that DNSSEC implementations started out with offline signing, both for performance and security.

I guess you can do geo-routing with offline signing as well. But some people find it easier to complain about new technology then to spend some effort making it work.

There are now also DNS servers that do online DNSSEC signing.

Essentially all non-toy real-world deployments of DNSSEC (perhaps outside of the DNSSEC root and TLD infrastructure itself) requires online signers, not just for basic operational reasons but because online signing is how defense against zone dumping (NSEC+"whitelies") works. So, yes, there are definitely servers that do online signing.

But then you're left wondering: why would we deploy a protocol that took profound tradeoffs to facilitate offline signing, when it turns out most of the real-world use cases were going to be online? If the protocol had been designed for online signers in the first place, it would be cleaner and more powerful in a bunch of different ways.

Instead, DNSSEC advocates propose that --- despite the fact that the industry has essentially not meaningfully deployed the protocol yet, after 25 years of standardization effort --- we just say "fuck it" and deploy this 90s protocol anyways. Something must be done! This is something!