Ok, what do you want to replace it with? You can't complain about the existing system without offering an alternative. Saying the existing system sucks doesn't help move the Internet towards something better.
Yes, you can, and yes, you should. Or are you saying you shouldn't file bug reports unless you can provide a patch?
Get real.
All I know is that centralized certificate authorities act as choke-points malicious governments can use to censor information.
DNSSEC is absolutely hierarchical and has strong name constraints. Today it has a single root run by ICANN, and run in such a way that hopefully the NSA and friends do not have access to the root key. Nothing stops other countries from legislating national alternative root zones, and nothing stops individuals from maintaining their own alternate root zones. We can expect eventually to see national alternate root zones, and we'll know that then that those states that impose them are almost certainly interested in being able to MITM. The ability to perform recursive lookups locally and use a root of one's choice will make MITMing more difficult.
DNSSEC, like WebPKI, is only as strong as the authentication of communications between domain owners/admins and CAs/registrars. With Let's Encrypt the WebPKI is quickly also becoming equally reliant on the security of communications between domain owners/admins and registrars anyways. There are efforts to improve that and reason to believe they'll succeed.
So at least as to non-nation-state actors, DANE is already more secure than the WebPKI.
QName minimization, and DNS privacy extensions (I wish the IETF would standardize DJB's solution for privacy), will make it very difficult for nation states with access to DNSSEC root zone keys to mount targeted MITM attacks. Non-targeted MITM attacks will be easier to notice than targeted ones.
In short, there's no silver bullet. The introduction problem is simply a very difficult one. But DANE looks to have better properties than WebPKI.
I wish that TLS 1.3 had mandated support for this going forward. Not just for public CAs, but also, I'd love to say "here is my company's internal CA root, only trust it for *.thecompany.example domains".
And protocols are typically stacked cleanly enough that it'd not be a big problem to replace TLS if another standard comes along to replace it.
[0] https://tools.ietf.org/html/rfc6698DANE definitely does not "work" for SMTP.
The necessity for DNSSEC in SMTP is, I think, a desperate trope† that recognizes that the Web PKI has moved past considering DANE and begun investing in direct hardening for the X.509 system. SMTP is other mainstream protocol for which transport security couldn't be guaranteed, is mired in the late 1990s technologically, and doesn't inherit modern browser- and server- based protection. So: SMTP! SMTP is the reason we need DNSSEC! We must get DNSSEC deployed immediately so everyone can have secure SMTP!
Except, you know who doesn't agree with you? The people who the most important email services. Hence: MTA-STS --- a standard whose introduction spells out its raison d'être: to avoid DANE! --- and the mooting of that last fragile argument for deploying DNSSEC.
DANE is a dead letter.
† I'm choosing words carefully
No, the major providers did not get together to do MTA-STS because DANE was bad. They did it because their existing DNS geo-balancing kit for e.g. google.com and yahoo.com does not offer an easy upgrade path to DNSSEC. Note that Microsoft has a dedicated domain (outlook.com) for email hosting, and can more easily do DNSSEC there without impacting their other "web properties". Note also that Google now MX-hosts many customer domains on "googlemail.com" rather than google.com.
So things are starting to change. Furthermore, there are now over 1 million DANE-enabled DNSSEC domains. MTA-STS is far behind, is not downgrade-resistant on first contact and uses weak CA-leap-of-faith DV authentication. It will probably be enabled at the biggest providers by the end of this year, but as you yourself said elsewhere, these providers are the threat, and if so, securing email delivery to the user surveillance empires is not necessarily that important. Mind you, they can play a useful role by enabling validation and helping to keep the TLSA records of receiving systems valid, and perhaps surveillance is not their business for paying customers...
There are a million DANE-enabled DNSSEC domains because there are registrars, particularly in Europe, that enable it automatically. Who cares? First of all, DNSSEC managed by your registrar is security theater, but, more importantly, the overwhelming majority of those domains do not matter. Who cares if some landing page in the Netherlands has TLSA records?
Meanwhile, the domains that really do matter --- the ones managed by the major mail providers --- are doing MTA-STS.
SMTP is not a success case for DNSSEC.
Recall: the argument you're responding to (you drew it up from downthread) is that DANE "definitely works for SMTP". Does it, now?
Yes, only ~9 to 10 million domains are presently signed, and most of the larger ones are not (but comcast.net and cloudflare.com are not tiny, and gmx.de has over 10 million email users). Changing this takes time and effort. Users still need better software tools that make deployment easier and there needs to be less KSK deployment and rollover friction at the registrars and registries (i.e. CDS support). Some DNS hosting providers with outdated software need to upgrade their stacks, ... this does not happen overnight. Let's compare notes in 2020 or 2021. Infrastructure upgrades happen slowly...
First of all, we have Certificate Transparency. This allows people to notice CA's behaving badly.
Secondly, we need certs to be signed by many different CA's. Note that this is just my idea, and I know of no intentions to standardize this. Currently, rescinding trust in a CA is a difficult and slow process. This is because rescinding a CA breaks a lot of infrastructure. If instead, certs were signed by multiple CA's, we could just drop a CA and most infrastructure should have signatures by other CAs.
Moreover, if I decided I don't trust the Hong Kong Post-office as a CA, I could drop them from my CA store without breaking the web. Perhaps I could even mark it as 'suspicious' and get notified when a cert is only signed by suspicious CAs.
By combing the two things, when a CA is compromised, Certificate Transparency should tell us about that in about a week, after which trust in that CA can be dropped almost immediately.
Just CT isn't enough. Consider what would happen if CT shows Lets-encrypt or DigiCert is compromised. We'd be forced to slowly drop trust, to allow many sites time to migrate away. Without the ability to drop a CA "like it's hot" Certificate transparency is toothless. It defends against CAs acting selfishly because getting caught by CT is bad for a CA. However, CT does not defend against coercion or compromise of CAs by third parties. Those third parties don't care whether the CA gets damaged. Under the current system they can get at least a month of signed certs for whatever domain they want.