Security 简而言之，DNSSEC是什么？

有人能简单地向我解释一下DNSSEC是如何工作的吗

我已经能理解的（但我不知道它是否完全正确）是：

DNS是早期Internet中创建的旧协议，因此它有缺陷（例如，没有身份验证）。它允许中间人和缓存中毒等攻击

解决方案是什么？DNSSEC的创建。一种使用公钥加密的协议，它为DNS查询提供身份验证和完整性。它使用从根DNS服务器开始的信任链工作-这里的“信任”表示您信任根服务器的公钥

在区域级别，该过程使用一对或多对密钥工作。首先，区域服务器具有ZSK（区域签名密钥），并使用专用ZSK对查询的数据进行签名。之后，它将公共ZSK、数据（RRSET）和签名数据（RRSIG）发送到DNS解析程序。但现在你必须信任公众ZSK。解决方案是什么？要拥有另一个密钥，请使用KSK（密钥签名密钥）。区域对包含公共KSK和公共ZK的新集合进行标记。在它发送新的集、签名集和公共KSK之后。它保证了该区域的安全

但是DNS需要的整个递归过程又如何呢？我们如何确保它也是安全的？这是通过使子服务器散列其公共KSK并将其发送给其父服务器来完成的，父服务器将其存储为DS（委托签名）。这件事做得很早，我不知道怎么做。这样，如果您信任父亲并且父亲有子DS，如果您散列子公共KSK并且结果等于父亲DS，那么您可以信任孩子。这创造了整个信任链。此链的安全入口点位于根目录中。您假定可以信任根目录的公钥

这就是我认为我对DNSSEC的理解，如果有人能更好地解释，修正我写的内容，你能提供更多你认为理解DNSSEC至关重要的信息，我将不胜感激

另外，如果有人能向我解释DNSSEC体系结构和密钥管理，我也会很高兴

---

非常感谢

您的问题非常广泛，与编程关系不大

就像Calle说的，你基本上已经是正确的了，所以让我来指出一些需要修复的部分

首先，需要记住的重要部分是，所有这些都是基于不对称加密的：每个密钥都是公共和私有部分。公共部分在

DNSKEY

RRs中发布，并且在

DS

记录中使用一些散列，而私有部分用于计算

RRSIG

记录。任何使用公钥的人都可以验证

RRSIG

记录中的签名确实是由某个特定的私钥签名的，但永远无法访问它

现在谈谈你的一些观点：

在区域级别，该过程使用一对或多对密钥工作。首先，区域服务器具有ZSK（区域签名密钥），并使用专用ZSK对查询的数据进行签名。之后，它将公共ZSK、数据（RRSET）和签名数据（RRSIG）发送到DNS解析程序

在给定区域的自动初始化名称服务器上，从区域的内容unsigned开始。在没有DNSSEC的旧时代，这正是出版的内容。 现在您至少有以下三个选项：

• 一个外部进程获取该区域并对其进行签名；这完全取决于密钥的管理方式：如果它们在HSM中，那么您需要将记录发送到那里进行签名，因为根据设计，私钥（签署记录所需的）永远不会离开硬件模块。请参见示例
• 解析程序本身，在加载时或通过单独的工具可以对区域本身进行签名，甚至可以管理密钥（因为密钥会定期更改）；看这个
• 或者，事先没有签名，解析器将在查询到达时生成

  RRSIG

  记录（并缓存一段时间）。 看

当然，每种解决方案都有其优缺点。它们都存在于球场上

但现在你必须信任公众ZSK。解决方案是什么？要拥有另一个密钥，请使用KSK（密钥签名密钥）

KSK/ZSK的拆分并非真正的信任，而是关键材料管理

让我们往回走一点。DNSSEC的整个设置在理论上可以完全相同的方式工作，每个区域只有一个键

但在实践中，这往往是更多的关键

首先，钥匙需要定期更换。对于他们来说，没有具体的原因或生命的终结，这只是假设，如果我们想要防止离线密钥破解，我们只需要定期更改它们。密钥发布时没有关于其持续时间的详细信息（与

RRSIG

s中的签名相反），但是每个DNSSEC签名区域都应该有一个（DNSSEC实践声明），其中包括每个密钥的有效期（见此）。 当然，为了准备密钥滚动，您需要提前在DNS中发布一个新密钥，以便缓存了解它，然后再开始使用它进行签名（或者至少在停止使用旧密钥进行签名之前）

因此，您已经可以同时处理多个键

现在你正处于两个相反的约束中：你希望尽可能长地使用一个键来处理更少的（如果外部处理的密钥越少，你就越需要使用它），因为它也存在于父区，通过<代码> DS 记录，同时，您知道，为了更好地进行安全设置，您需要尽可能短的时间使用它，并经常更新

您可以通过执行KSK/ZSK拆分来解决这个难题

为什么?？因为您可以为每个密钥附加不同的生存期。KSK也将通过

DS

记录存在于父区域中，因此通常是您不想更改的内容