实际上不清楚 DNSSEC 是否是“我们想要的”。

目前，Web 站点的认证，即 Web 浏览器如何确保它与正确的站点通信（当使用 HTTPS 时）是通过大约一百个根证书颁发机构发出的数字证书来完成的。根CA是决定进入证书颁发业务的实体，而百家的特别之处在于他们与微软/苹果/Mozilla/谷歌达成了交易，将他们的公钥包含在“受信任的" 每个浏览器（或操作系统）的存储。这笔交易包括许多合法的小玩意和保险。

尽管经常因其不透明性、单个证书的公共成本以及一些广为人知的错误（查找“Comodo”和“DigiNotar”）而受到批评，但 PKI 系统在经济意义上倾向于工作：商业网站使用它们，而CA 很少受到攻击（大多数攻击是诱使容易上当的用户忽略浏览器在发现证书有问题时发出的可怕警告，而不是麻烦地破坏现有的 CA）。然后，改变事物的动力相对较小（也就是说，有很多人出于各种原因更喜欢另一个系统，但最终，这些事情是由支付它的人决定的）。

DNSSEC旨在将这些根 CA 排除在循环之外，而是将认证权力授予维护 DNS（从服务器名称到 IP 地址的映射）的人员，从而将两种结构绑定在一起：域名称继承（具有“子域”的概念）将与 PKI 继承（具有“中间 CA”的概念）合并。

目前尚不清楚新租户是否会比以前更胜任 CA 业务；正如我所说，实际系统已经运行良好，认证与将名称映射到地址不同。也不清楚这种权力集中是否真的是一件好事。对于大玩家来说，这不会改变任何事情：Verisign-the-CA 和 Verisign-the-registrar 都是 Verisign。

在技​​术方面，DNSSEC 提供了通过 DNS 系统轻松分发证书（也称为“身份到公钥的签名绑定”），但这不是需要解决的问题：现在，任何 SSL/TLS 服务器都可以愉快地使用作为初始握手的一部分发送他的证书链，它运行良好。

因此，鉴于 DNSSEC 的优点存在不确定性，并且现有 PKI 没有明显问题，难怪大公司认为部署并不紧迫。让我们先让 IPv6 工作。

正如下面的评论所示，DNSSEC本身对于验证 DNS 信息具有一定的价值，可以阻止 DNS 中毒。DNS 中毒是进行中间人攻击的简单方法，但认为这可以解决 MiTM 问题是错误的；它只是让攻击者的事情变得更加困难（例如，攻击者必须使用WiFi 菠萝，而不是简单地滥用现有 WiFi 热点中的一个洞）。如果您无法知道给定数据包是否真的来自写入其标头中的 IP 地址，那么获得有关名称到给定 IP 地址的映射的保证不会让您走得太远。

无论哪种方式，它都没有为大型服务器提供太多附加值，这足以解释他们的不情愿。

（不过，DNSSEC 具有军事价值：通过防止 DNS 中毒，它有助于防御可能成为某些全球电子战一部分的大型拒绝服务攻击。我希望 DNSSEC 得到政府的支持，而不是大公司的支持——但时代或 ARPANET 早已一去不复返，如今互联网已成为私人企业的领地。）

8年后：

我必须得出结论，他们知道 DNSSEC 的一些不好的地方，这些坏处超过了它所提供的好处。

不必要。就像任何其他技术一样，问题是对相关利益相关者有什么激励措施？. 如果您查看ICANN 的 DNSSEC 报告，您会发现目前几乎所有 TLD 都支持 DNSSEC。

那么为什么消费者不使用它呢？嗯，这也不容易回答。一般来说，如果您不想经历运行自己的名称服务器的麻烦，您需要依赖注册商来处理一些功能，例如 DNSSEC。Chung 等人的一项研究。在 2017 年 [1] 显示，“前 20 名注册商中只有 3 个在作为 DNS 运营商时支持 DNSSEC”。即使您的名称服务器已正确配置为使用 DNSSEC，也无法保证用户使用（递归）解析器，这些解析器可识别 DNS​​SEC 并正确验证 DNSSEC 记录 [2]。

最终用户较差的安全可用性可能是对潜在采用者的另一个负面激励。与 TLS 相比，如果证书无效，您会直接在浏览器中收到警告和错误，DNSSEC 没有视觉提示（您可以检查网站是否已签名，或者您的解析器是否在https://internet上验证 DNSSEC .nl/ )。

为了给整个故事另一个转折点，某些方面有时需要缺少 DNSSEC。例如，DNS 中毒为域模拟打开了大门，它还可以授予您域验证 (DV) 证书 [3]，这实际上使您即使使用有效证书（地址栏中的绿色挂锁）也可以欺骗合法实体。另一个例子是tr不支持 DNSSEC 的 TLD；现在结合土耳其政府曾经如何滥用 DNS 进行审查，您可以得出自己的结论。

[...] 并且您可以遍历 DNSSEC 记录并找出您域中的所有记录。

NSEC3 不再是这种情况。

更新：

我忘了提到RFC 3833，它不仅列举了 DNS 安全威胁，还列举了 DNSSEC 的弱点：

• DNSSEC 实施起来很复杂。
• DNSSEC 显着增加了 DNS 响应数据包的大小。
• DNSSEC 答案验证增加了解析器的工作量。
• 与 DNS 本身一样，DNSSEC 的信任模型几乎是完全分层的。
• 根目录的密钥翻转真的很难。
• DNSSEC 提出了松散时间同步的要求。
• 区域中可能存在的通配符 RR 使认证拒绝机制相当复杂。

[1] Chung, T., Levin, D., Van Rijswijk-Deij, R., Maggs, BM, Wilson, C., Choffnes, D., & Mislove, A. (2017)。了解注册商在 DNSSEC 部署中的作用。ACM SIGCOMM 互联网测量会议论文集，IMC，F1319 部分（七月），369–383。https://doi.org/10.1145/3131365.3131373

[2] Chung, T., Van Rijswijk-Deij, R., Chandrasekaran, B., Choffnes, D., Levin, D., Maggs, BM, Mislove, A., & Wilson, C. (2017)。DNSSEC 生态系统的纵向、端到端视图。第 26 届 USENIX 安全研讨会论文集，1307-1322。

[3] Schwittmann, L.、Wander, M. 和 Weis, T. (2019)。域模拟是可行的：CA 域验证漏洞的研究。会议记录 - 第 4 届 IEEE 欧洲安全和隐私研讨会，EURO S 和 P 2019，544–559。https://doi.org/10.1109/EuroSP.2019.00046

DNSSEC 唯一的问题是它是新的，DNS（显然）很重要，人们不愿意弄乱他们的 DNS 设置。如果您的 DNSSEC 部署出错，您可能会失去整个互联网的存在。

至于为什么要对 DNS 查找进行身份验证，请阅读这篇关于防火墙如何泄露给中国以外用户的论文：

http://www.sigcomm.org/sites/default/files/ccr/papers/2012/July/2317307-2317311.pdf

不只是中国在搞 DNS，任何可以访问客户端、客户端解析器或解析器与您的 dns 服务器之间流量的人也可以更改响应。

网站证书只是这里拼图的一小部分。