security - 简而言之，DNSSEC是什么？

Question

有人可以向我解释DNSSEC的工作原理吗？

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

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

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

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

但是DNS需要整个递归过程呢？我们如何确保它也安全？通过使子级服务器对其公共KSK进行哈希处理并将其发送给其父级（将其存储为DS（代理签名））来完成。它很早就完成了，我不知道怎么做。这样，如果您信任父亲，并且父亲拥有孩子DS，则如果对孩子公共KSK进行哈希处理并且结果等于父亲DS，则可以信任孩子。这将创建整个信任链。该链的安全入口点在根中。您假设您可以信任根的公共密钥。

我认为这是我对DNSSEC的理解，如果有人可以更好地解释，修复我写的内容，或者提供更多信息，您认为了解DNSSEC是必不可少的，我将不胜感激。

同样，如果有人可以向我解释DNSSEC体系结构和密钥管理，我也将很高兴。

非常感谢你！！！！！

Answer 1

您的问题非常广泛，与编程无关。

就像Calle所说的那样，您已经很正确了，所以让我确定要修复的部分。

首先，要记住的重要部分是所有这些都是基于非对称密码学的：每个密钥都是公共和私有部分。公开部分在DNSKEY RR中发布，并且在DS记录中也带有一些哈希，而私有部分用于计算RRSIG记录。使用公钥的任何人都将能够验证RRSIG记录中的签名确实是由某些特定的私钥签名的，而从未访问过它。

现在就您的一些观点：


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


在给定区域的自动名称服务器上，从无符号区域的内容开始。在没有DNSSEC的过去，这正是发布的内容。
现在至少有这三个选项：


外部进程获取区域并对其进行签名；这完全取决于密钥的管理方式：如果密钥在HSM中，则您需要发送要签名的记录，因为根据设计，私钥（需要对记录进行签名）永远不会离开硬件模块。例如，请参见OpenDNSSEC software。
解析程序本身在加载时或通过单独的工具可以对区域本身进行签名，甚至可以管理密钥（因为它们需要定期更改）；参见此example in Bind。
或者，没有事先签名，并且解析器将在查询到达时生成（并缓存一段时间）RRSIG记录。
请参见how one big provider does it。


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


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


KSK / ZSK的分离实际上与信任无关，而只是关键的材料管理。

让我们回去一点。从理论上讲，整个DNSSEC的设置可以完全相同地工作，而每个区域中只有一个密钥。

但实际上，它通常是更多的键。

首先，需要定期更改密钥。它们没有特定的原因或寿命终止，只是假设，如果我们要防御离线密钥破解，我们只需要定期更改它们即可。密钥发布时没有详细说明其持续时间（与RRSIG中的签名相反），但是每个DNSSEC签名区域均应具有一个DPS（DNSSEC实践声明），其中应详细研究每个密钥的有效期限（参见other answer of me for more details on DPS）。
当然，为了准备密钥过渡，您需要提前在DNS中发布新密钥，以便缓存了解它，并在开始对其进行签名之前（或者至少在停止与较旧的密钥签名之前）。

因此，您已经必须同时处理多个键。

现在您处于两个相反的约束之中：您希望在尽可能长的时间内继续使用一个键，以减少处理（并且如果从外部处理该键，则必须使用的键越少越好），因为通过DS记录，它也存在于父区域中，并且同时您知道，为了获得更好的安全性设置，您需要在尽可能短的时间内使用它并经常对其进行更新。

您可以通过进行KSK / ZSK拆分来解决此概要。

为什么？因为您可以为每个键附加不同的生存期。 KSK也将通过DS记录存在于父区域中，因此通常您不想更改太多。通常，KSK将是最安全的密钥（最受保护的密钥），并将“使用” 1或2年（必须在DPS中进行详细说明）。然后，用于对区域中的记录进行真正签名的ZSK可以是更频繁地生成的密钥，例如1或2个月，因为它们的更改仅需要反映在区域本身中，因此无需在父级上进行任何更改。区。

例如，参见IANA Root Zone Key ceremony：只有一个根密钥（绝对信任），并且它可能在将来发生变化（已计划于去年10月，但后来被推迟了）；无论如何，每年两次在某个数据中心进行特定的关键仪式，这到底会发生什么？ DNS根区域运营商VeriSign附带了一定数量的密钥（实际上是将来的ZSK），这些密钥会花费一些时间（基本上直到下一次仪式，并有一定的余地），具体取决于相关DPS中详细说明的ZSK生存期。 ），然后在许多见证人在各个级别上均正确使用根KSK签名这些ZSK。然后，可以将KSK放回存储区，并且不再使用（直到下一个仪式），然后DNS运营商可以开始发布具有相关签名的ZSK。

同样，这是自定义的，但肯定不是强制性的。某些区域（例如.CO.UK，请参阅它如何只有一个DNSKEY记录）决定仅使用一个密钥，这称为“公共签名密钥CSK”，这意味着它同时是一个区域签名密钥和一个密钥签名密钥（因为它本身进行了签名，并且它也是用于父级DS的密钥）。


通过使子级服务器对其公共KSK进行哈希处理并将其发送给其父级（将其存储为DS（代理签名））来完成。它很早就完成了，我不知道怎么做。


每个区域都必须向其父级发送一个（或多个）KSK（当然是公共部分），并让父级计算要在其区域中发布的相关DS，或者直接发送DS记录。除了根目录外，DNS树中的每个节点都存在相同的问题。而且孩子需要在使用相关密钥进行任何签名之前提前做很多事情，因为他通常无法控制父母在开始发布密钥之前要花费多少时间。

从理论上讲，这与DNS树中的每个节点相同，因为在实践中，这种信息传输必须从DNS带外完成（CDS / CDNSKEY除外，请参见下文），并且这可以每个节点都不同。它通常至少涉及到一些纯粹的人机交互，这说明了ZSK / KSK拆分之所以令人赏心悦目，是因为它降低了您进行任何替换KSK的频率。

例如，对于TLD，他们需要在IANA网站上输入流程，以提供其新的DS记录，然后等待一段时间，以便IANA处理并验证该记录，然后再将其发布在根区域中。

对于2LD（二级域名），他们通常会转到其注册服务商，并通过某些网站或API提供注册服务商将发送到注册表的信息，以便其发布。
如今，使用称为EPP（可扩展配置协议）的协议进行了注册服务商-注册机构对话，并且它具有DNSSEC的特定扩展名为secDNS。
此扩展名允许注册服务商代表其客户发送（基于注册策略）：


DS记录（作为4个单独的参数）
DNSKEY记录（作为4个单独的参数），注册表将根据该记录自行计算要发布的适当的DS记录
DS记录和一个封闭的（相关）DNSKEY记录，以便注册表可以再次检查DS是否已正确计算，并且确实与域已经发布的某些DNSKEY记录匹配


（或多或少按现场案件的频率降序排列）。

这解决了供应问题。至于降低树的节点，则标准机制越来越少。

还有另一条路径，这一次使用DNS本身而不是带外设置内容，如RFC 7344和RFC 8078中所述，使用CDS / CDNSKEY记录。前导C代表Child，然后您再次得到DS或DNSKEY，因为核心思想是让节点在自己的区域中发布此类记录，然后让父区域进行DNS查询以将其拾取并删除。然后为其提供父区域。

当然，这确实会至少在引导过程中造成一些问题。
而且这些机制现在还没有使用太多。特别是对于DNS托管人本身不是注册服务商的情况，正在进行各种工作和构想，以便外部团体可以对此进行影响并在父级区域进行更改，而无需在EPP级别上进行从注册服务商到注册管理机构的干预。如果您对这些主题感兴趣，请查看例如https://www.dk-hostmaster.dk/en/news/cloudflare-integrates-dk-hostmasters-dnssec-setup或https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/

至于：


同样，如果有人可以向我解释DNSSEC体系结构和密钥管理，我也将很高兴。


这真的太广泛了。
我不知道您所说的DNSSEC架构是什么意思：没有一种适合所有方法的大小，您至少需要考虑区域的数量（要签名的记录数），您辞职的频率（如果没有）实时操作，然后进行相关的键旋转以及键的存储方式和位置。

密钥管理不再是DNSSEC特有的一点。 X.509 PKI证书颁发机构在其私钥的安全性以及如何使用它对其他密钥进行签名（在这种情况下实际上是证书）方面将具有几乎相同的问题。