Having cryptographically signed DNS records that can’t be forged and can be validated is good thing, which is what DNSSEC provides.
Right now, DANE is the only way to mitigate downgrade attacks with SMTP and TLS connections. Apparently use of DANE for email is growing [1].
DANE hasn’t taken off with browser vendors because of their concern about additional DNS lookups when making TLS connections.
[1]: “Number of DANE-enabled mail domains growing exponentially”—https://www.sidn.nl/en/news-and-blogs/number-of-dane-enabled...
If that were the case, browser vendors would have helped push the DNSSEC chain-extensions forward, which were designed exactly to avoid doing DNS lookups to carry DANE records. Instead, the browser vendors laughed at the chain-extensions effort, and it died in committee.
Just pointing out that MTA-STS doesn’t mitigate downgrade attacks and that DNSSEC/DANE does: https://www.rfc-editor.org/rfc/rfc7672.html#section-1.3.1
And right from the MTA-STS RFC: https://www.rfc-editor.org/rfc/rfc8461.html#section-2
the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades.
So there’s that.
This is only true if you personally fully own the domain and have control of the DNS and other services, which is not the case for the utter majority (at least 99.9%, maybe a few more 9s) of the population. Of course, in that case, you are pretty much the email provider, so not trusting the email provider is a pretty questionable scenario at that point.
> MTA-STS: compromise for the DNSSEC-challenged
Yeah... DNSSEC is a classic example of a solution looking for a problem. Most of your criticism would apply equally well to not using DANE for TLS, and every browser vendor has looked at it and decided against it because it adds no security.