&gt; If you live in a world where unencrypted HTTP still exists then it&#x27;s nice to have some defense against ISPs who like to lie in DNS responses.<p>As tptacek and others have pointed out numerous times elsewhere on HN (and in the article linked above):<p>1. DNSSEC doesn&#x27;t protect against ISPs hijacking DNS responses<p>2. TLS is easier to deploy than DNSSEC<p>3. TLS provides more security for the end user than DNSSEC does<p>3a. If TLS us used, DNSSEC provides essentially no additional security benefits to the end user.<p>So really, it makes sense to be advocating the use of TLS,  which is what projects like Let&#x27;s Encrypt are all about. DNSSEC is at best a waste of resources that could be better spent on actually securing the Internet through TLS, and at worst actively harmful (because the strongest criticism of TLS is that it centralizes trust in CAs, and DNSSEC centralizes trust even further - in a <i>single entity</i>!)<p>&gt;  I&#x27;d prefer not to send any packets at all to the wrong IP rather than wait until it presents the wrong certificate.<p>I&#x27;m not sure what difference it makes to be sending packets to the wrong IP. The whole point of TLS is that it doesn&#x27;t really matter, because they can&#x27;t read what you&#x27;re sending anyway.<p>Also, the way the Internet works, you&#x27;re <i>always</i> sending packets through the &quot;wrong&quot; IP addresses, so you should make the assumption that your raw traffic is visible to to any eavesdropper (and therefore encrypt your traffic so that this is not an issue).