DNSSEC - 它如何防止 MITM 攻击？

Question

我已经阅读了几个小时，DNSSEC但仍然无法理解它如何防止MITM攻击。我还阅读了这里有关服务器故障的每个问题DNSSEC。

请查看此DNSSEC数据包捕获：https://www.cloudshark.org/captures/79e23786259b

是什么阻止拦截每个查询，并为每个,和记录MITM回复它自己的密钥对？DNSKEYSRRSIGDS

例如，MITM将为 www.ietf.org 生成 RRSIG，然后DNSKEYS为 生成ietf.orgRRSIG，然后DS为 记录ietf.org。然后是另一组“org”的DNSKEYS和DS记录，然后再次是“.”的记录<Root>。

在 TLS 中，我们可以信任 CA 的信任链，因为根 CA 已预先安装在每个系统上，因此我们可以根据它检查回复。在 中DNSSEC，我不相信 rootDNSKEY会像 Root CA 那样安装在系统上。那么是什么让我们可以信任我们收到的这个根密钥呢？

Answer 1

这个问题是通过信任链解决的：该链中的每个链接都在前一个区域中签署了DS记录，正如您的问题中已经提到的。这强调了根名称服务器上的锚点的重要性。如果这是欺骗的话，整个信任链就会受到损害。因此，解析器必须预先配置信任锚。RFC 6781解释：

\n

\n

4.2.3. 解析器中锚定密钥的泄露

\n

还可以在解析器中将密钥预先配置为信任锚。\n如果信任锚密钥遭到泄露，则应将此事实通知\n使用这些密钥的解析器的管理员。区域管理员\n可以考虑设置一个邮件列表来传达\nSEP 密钥即将滚动的事实。当然，这种通信需要通过某种方式进行身份验证，例如使用数字签名。

\n

面临更新锚定密钥任务的最终用户应始终验证新密钥。新密钥应在带外进行身份验证，例如，通过使用使用传输层安全性 (TLS) [RFC5246]保护的公告网站。

\n

\n

您可以直接从互联网系统联盟下载当前根信任锚 ( bind.keys) 。该网站使用 TLS 进行保护，并且该文件也使用其签名密钥进行签名。

\n

\n

如果\xe2\x80\x99 中没有任何内容named.conf并且没有bind.keys\n文件，named 将使用已编译的键。

\n

\n

\n

注意：这些是托管密钥，因此这仅在您第一次执行命名时适用。假设密钥尚未过期（在这种情况下，named 将记录密钥已过期且验证将不起作用），named 将使用 RFC 5011 检测新密钥并自动滚动和维护密钥。一旦命名正在管理密钥，\n如果您使用视图，当前密钥将位于managed-keys.bind或中。*.mkeys

\n

\n

另一个问题是与解析器的通信，即“最后一英里”。解析器可能会验证签名并使用 DNS验证数据(AD) 位进行应答，但由于 DNS 以纯文本形式工作，因此结果可能会被中间人 (MITM) 攻击者修改。对此有多种可能的解决方案：

\n

\n

• 您可以有一个自己的本地解析器，其中包含锚键文件，但这对于大众来说并不是一个实用的解决方案。如果没有配置转发器，它还会导致更多流量流向根名称服务器。这是一种无人信任的解决方案，您可以自行验证签名。

  \n
\n

• DNS-over-TLS和DNS-over-HTTPS。例如 Cloudflare 及其1.1.1.1 支持：

  \n

  \n

  我们需要的是转向新的现代协议。有一对

  \n

  \n
\n

\n

\n

不同的方法。一种是 DNS-over-TLS。这采用了现有的\nDNS 协议并添加了传输层加密。另一个是\nDNS-over-HTTPS。它不仅包括安全性，还包括所有现代增强功能，例如支持其他传输层（例如 QUIC）和服务器 HTTP/2 服务器推送等新技术。DNS-over-TLS 和\nDNS-over-HTTPS 都是开放标准。

\n

我们认为 DNS-over-HTTPS 特别有前途\xe2\x80\x94 快速、更容易\n解析和加密。\xe2\x80\x93 \xe2\x80\x93 我们希望\n有了独立的 DNS-over-HTTPS 服务，\n我们将看到\n来自浏览器、操作系统、路由器和应用程序的更多实验\ n支持该协议。

\n

\n

\n
• DNSCrypt使用加密签名对 DNS 客户端和 DNS 解析器之间的通信进行身份验证。这从未向 IETF 提出过（没有 RFC）。
\n

\n