[mike_hearn]

DNSSEC is however the only way you can make TLS really work. The whole TLS ecosystem is dependent on CAs that are basically just a giant hack. They're signing a statement that they did a bunch of DNS resolutions at a point in time from different network vantage points (maybe, hopefully), and got consistent answers. DNSSEC+DANE lets you get the actual data you want (domain name->public key binding) from the root source, without needing the complicated middlemen.

[mike_d]

DNSSEC+DANE is an affirmation by the United States government that you have followed a chain to an answer about a certificate pinning. Handshake (www.handshake.org, Trigger warning: crypto) will give you what you are talking about (CA non-reliance) anchored in the owner of the website itself.

If you aren't a fan of DV certificates (as you point out verified by resolution), you can always restrict your trust store to only CA certificates that sign EV certificates (verified by business records).

[cryptonector]

The root zone doesn't change often. You can pin . or even run your own private . with pinned . content if you don't trust the root.

If you do, then you get MITM protection.

If you don't, but choose to use QName minimization, you still get a modicum of MITM protection: because the attacker would have to choose to get in the middle without having enough knowledge of whether a particular upcoming TLS connection (or whatever) will be of particular interest.

Really, DNSSEC is infinitely better than the WebPKI, even WebPKI+CT, especially when DNSSEC clients use QName minimization, and even more so when clients pin copies of . from time to time.