Chromium 安全团队说：

与替代方案相比，DNSSEC 和 DANE（类型 2/3）并未显着提高安全标准，并且可能对安全性不利。DNSSEC+DANE（类型 0/1）可以通过 HTTP 公钥固定来实现相同的效果，并且具有更可靠和一致的交付机制。

（见https://bugs.chromium.org/p/chromium/issues/detail?id=50874#c22）

他们在 HPKP 支持上花费了很多时间和精力，Firefox 一直在使用他们制作的许多工具（例如内置的固定列表）。因此，当他们有一种他们认为更好的方法时，他们可能认为支持另一种方法没有多大意义。微软也一直在调查它，但没有做出任何特别的表态（尽管他们似乎没有调查过 DNSSEC）。这是当前浏览器市场的主要参与者倾向于替代方案。

然而，HPKP 是建立在 HTTP 之上的——它纯粹是为 Web 设计的。DNSSEC 没有这个限制，因此可以用于其他应用程序。它可以验证 DNS 记录确实来自域所有者，这对于邮件服务器或小型 DNS 解析器很有用，确保能够修改流量的恶意行为者无法以无法检测的方式篡改记录。正因为如此，部署仍然被认为很重要——DNS 不仅仅用于网页！

从这里：

DNSSEC 的缺点

• DNSSEC 会显着增加 DNS 服务器的负载——增加成本并降低当前 DNS 系统的效率。这需要 TLD 注册运营商、域名注册商、ISP 和托管服务提供商投入大量资源。
• “引导问题”——在任何用户获得大于其成本的收益之前，都需要最低级别的部署。
• DNSSEC 部署在服务器端和客户端都需要软件——您如何才能获得最终用户的支持以使用支持 DNSSEC 的操作系统和浏览器插件，尤其是当 DNSSEC 的复杂性增加可能会导致频繁的查找错误或性能下降时，对最终用户的整体互联网体验产生负面影响？
• DNSSEC 是不必要的复杂，即使是经验丰富的 DNS 管理员也难以实施 - DNSSEC 增加了本质上简单的系统的复杂性。与某些非 DNSSEC 系统可能缺乏向后兼容性，这也引起了人们的关注。
• 很少有顶级域支持 DNSSEC，一些政府甚至可能试图禁止由 DNSSEC 支持的加密密钥分发——各国担心美国对互联网的控制，并可能拒绝任何集中式密钥。在没有签名根的情况下部署 DNSSEC 会降低对 DNS 缓存中毒和类似攻击的保护。

因此，浏览器似乎可以默认支持 DNSSEC，但会牺牲浏览器性能。

在撰写本文时，似乎采用 DNSSEC 使其不值得。任何不存在的 DNSSEC 查找都必须回退到正常的 DNS，从而增加延迟。

这里还有一个用户体验问题 - 浏览器如何传达通过 DNSSEC 查找域的事实？许多用户不会理解这个额外的标志如何与挂锁结合使用。我猜它可能会阻止未正确签名的 DNSSEC 响应并拒绝在那里导航，但是证书已经用于验证您是否已到达正确的服务器。并且使用HPKP，您可以检查没有任何流氓证书颁发机构颁发的证书。

编辑：现在 HPKP 已经死了，我们现在期待像证书透明度一样来实现这一点。