&gt; I really don&#x27;t understand why the existence of software that doesn&#x27;t try to take advantage of DNSSEC is being used as evidence that DNSSEC is incapable of doing something.<p>It&#x27;s not that DNSSEC is fundamentally &quot;incapable&quot; of doing this, but that it&#x27;s literally not what the protocol is designed to do. As noted in the other HN thread on this announcement, the DNSSEC protocol is explicitly <i>not</i> designed for end-user verification, and end-users are discouraged from running their own valdiators. There&#x27;s a reason that browsers don&#x27;t support this out-of-the-box and (more importantly) don&#x27;t ever plan on it.<p>If you&#x27;re concerned about people snooping on your TCP packets, DNSSEC doesn&#x27;t solve that. If you&#x27;re concerned about people spoofing DNS responses, DNSSEC doesn&#x27;t solve that[0]. TLS + HSTS <i>does</i> solve that, by making it impossible to load a forged page, regardless of what DNS records were returned[1].<p>Again, TLS solves all the problems you describe (including the problem of ISPs redirecting mistyped pages to their own advertising pages). TLS is also supported by <i>every</i> browser, out-of-the-box. It&#x27;s more secure, easier to deploy, and already widely used.<p>[0] Again, as explained in the post, DNSSEC is <i>not</i> designed to protect end-users against malicious ISPs. This is literally a matter of what problems DNSSEC is even aimed at solving.<p>[1] Notice how <a href="http:&#x2F;&#x2F;google.com" rel="nofollow">http:&#x2F;&#x2F;google.com</a> (not even <a href="https:&#x2F;&#x2F;" rel="nofollow">https:&#x2F;&#x2F;</a>) will <i>never</i> redirect to a captive portal. That&#x27;s not DNSSEC. That&#x27;s TLS + HSTS. DNSSEC is redundant in this situation.