This depends on your threat model. Here is mine, in order of importance: 1. Compromised local network (such as bad public wifi, tampering by ISP) 2. Compromis

This depends on your threat model. Here is mine, in order of importance: 1. Compromised local network (such as bad public wifi, tampering by ISP) 2. Compromised registrar (DNS or CA) 3. Compromised backbone internet (possibly because of state-level interference) 4. Compromised infrastructure of the website I am visiting ("4" is all the way at the end of the list because if the website is compromised, they likely can get access to DB/web server directly, and DNS/TLS things don't really matter) So even without HSTS, you are protected against 1 and 3; and, thanks to Certificate Transparency, have a good way to detect 2 (because Let's Encrypt does DNS queries from multiple regions and writes all certificates to CT Log). This is all live and works right now. And the threat of browser removal really causes CA to pay attention to browser security. Compared to this, the DNSSEC solves 1 (at least so I've heard, the original spec was vulnerable); does not solve 2 and removes all the pressure for registrars to improve; and just gives up on 3 when the state is involved. Additionally, your "upload a certificate chain" approach sounds like you want to skip using CT, which means that detection of 2 and 3 is also gone. In the past there were more reasons to use DNSSEC. But now, when Let's Encrypt exists, and the state-endorsed internet interference happens in multiple countries, it simply makes no sense.