* We've tried having ISPs run recursive resolvers - and many ISPs demonstrated that they either ran slow servers, servers that sent back faked responses, or both.
* DNSSEC lets you validate a response, thus getting rid of faked responses. However, even if the OS making running a local DNSSEC validating resolver easy, I don't see how that can be made fast. In order to validate any response, it has to be validated up through the root, which requires more requests. Caching helps, but, it still won't be as fast as a well implemented shared cache.
* It seems like it would be possible a central cache to return all of the signatures up through the root in response to a request to allow for local verification. That would solve the extra requests issue while ensuring that all responses are genuine. So, even if an ISP wanted to send back bad responses, they couldn't. However, it's my understanding that there are real advantages to keeping DNS requests and responses to below ~1,280 bytes to fit inside of single transport frames - having to send all of that extra data seems like it would make it hard to do that. Since DNSSEC uses RSA keys, which are huge, that would probably be impossible, but even with EC keys, it might be tricky. Also, it doesn't really address the very real issue that some ISPs have done a poor job by running slow DNS servers.
* Any solution that doesn't involve some sort of centralized cache, is going to have a hard time keeping up with 8.8.8.8 or 1.1.1.1 performance wise.
So, while I value decentralized solutions, it just feels like it's a very difficult proposition for a decentralized solution to win when it's at a performance disadvantage.
2) DNSSEC isn't a panacea and there are absolutely problems with depending on it. And of course it doesn't directly address the confidentiality issue, either. My point is simply that too many technically-oriented people are willing to throw up their hands; they'll give centralized DoH/DoT to Google and Cloudflare a pass as a fait accompli but endlessly bikeshed the downsides to DNSSEC.
In truth DNS confidentiality is a fundamentally difficult problem because DNS is fundamentally centralized, as would be any system reliant on recognizable identifiers for its namespacing. And while we can maybe trust Cloudflare and Google today that can easily change, and there's no going back once we centralize even further--as described by another poster who described how 8.8.8.8 is ubiquitous enough at this point that it has set expectations for actual resolution behavior. It's not DoH or DoT that is the problem, per se, it's the fact that it will be enabled by default and be performed by the browser directly to Google and Cloudflare.
Authentication is solvable, however, and while more difficult to orchestrate DNSSEC usage, the result would be preferable long-term compared to making Google and Cloudflare yet another point of centralization. Even if you think DNSSEC sucks it represents at this very moment a stark choice between a whole universe of sucky options in the future versus vs the preservation of our ability to pursue better options down the road, independent of its specific merits. Would you prefer DNSCurve over DNSSEC? Once they broker most DNS traffic both Google and Cloudflare will have an even stronger incentive to promote the most baroque alternatives because additional complexity favors the large incumbents, just as large corporations, once regulation becomes inevitable, will lobby for particularly complex regulations requiring particularly costly compliance as a barrier to competition.
And, again, it doesn't require you to necessarily do anything. You don't need to be a mechanic to understand the value in preserving the viability of being a mechanic.