有人可以向我解释DNSSEC的工作原理吗？
我已经可以理解（但我不知道它是否完全正确）是：
DNS是早期互联网中创建的旧协议，因此它存在缺陷（例如，没有身份验证）。它允许攻击为Man-In-The-Middle和Cache中毒。
解决方案？创建DNSSEC。一种使用公钥加密技术并为DNS查询提供身份验证和完整性的协议。它使用从根DNS服务器开始的信任链 - 这里的“信任”意味着您信任根服务器的公钥。
在区域级别，该过程使用一对或多对键。首先，区域服务器具有ZSK（区域签名密钥），并使用私有ZSK对查询的数据进行签名。之后，它将公共ZSK，数据（RRSET）和签名数据（RRSIG）发送到DNS解析器。但现在你必须相信公众ZSK。解决方案？要有另一个密钥，KSK（密钥签名密钥）。区域签署包含公共KSK和公共ZKS的新集合。在它发送新集，签名集和公共KSK之后。它保证了区域内的安全。
但DNS需要的整个递归过程怎么样？我们如何确保它也是安全的？这是通过使子服务器散列其公共KSK并将其发送给其父进程来完成的，该父进程将其存储为DS（委托签名）。这是早做的，我不知道如何。这样，如果您信任父亲和父亲拥有子DS，如果您将子公共KSK哈希并且结果等于父DS，则可以信任该孩子。这创造了整个信任链。此链的安全入口点位于根目录中。您假设您可以信任根的公钥。
这就是我认为我对DNSSEC的理解，如果有人能够更好地解释，修复我写的内容，你会提供更多信息，你认为理解DNSSEC至关重要我会非常感激。
如果有人能向我解释DNSSEC架构和密钥管理，我也会很高兴。
非常感谢!!!!!
答案 0 :(得分：1)
您的问题非常广泛，与编程无关。
就像Calle说的那样你已经大部分都是正确的，所以让我指出一些要修复的部分。
首先，要记住的重要部分是所有这些都是基于不对称加密：每个密钥都是公共和私有部分。公共部分在DNSKEY RR中发布，在DS条记录中也有一些散列，而私有部分用于计算RRSIG条记录。使用公钥的任何人都可以验证RRSIG记录中的签名是否确实是由某个特定私钥签名的，而从来没有访问过它。
现在谈谈你的一些观点：
在区域级别，该过程使用一对或多对键。首先，区域服务器具有ZSK（区域签名密钥），并使用私有ZSK对查询的数据进行签名。之后，它将公共ZSK，数据（RRSET）和签名数据（RRSIG）发送到DNS解析器。
在给定区域的自动定位名称服务器上，您将从区域内容开始，无符号。在过去没有DNSSEC的情况下，这正是发布的内容。 现在你至少有这三个选项：
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将是最安全的密钥（受保护程度最高的密钥），并且最后将是＃34; 1年或2年（这必须在DPS中详细说明）。然后，用于真正签署区域中记录的ZSK可以更频繁地生成密钥，例如1或2个月，因为它们中的更改只需要反映在区域本身中，不需要在父项处更改任何内容区。
例如参见IANA Root Zone Key ceremony：只有一个根密钥（绝对信任），它可能在将来发生变化（它已经计划在去年十月，但后来被推迟）;无论如何，每年两次在某个数据中心举行特定的关键仪式，这将会发生什么？ DNS根区域运营商VeriSign带有一定数量的密钥（实际上是未来的ZSK）值得花一些时间（基本上直到下一个仪式，有一些余量，基于典型的ZSK寿命，详见相关DPS ），然后正确使用根KSK，许多级别的许多证人，签署这些ZSK。然后可以将KSK放回存储中并且再也不用（直到下一个仪式），然后DNS运营商可以逐个开始发布ZSK及其相关签名。
同样，这是自定义的，但肯定不是强制性的。一些区域（如.CO.UK，看它只有一条DNSKEY记录）决定只使用一个密钥，这被称为CSK for Common Signing Key，这意味着它同时是一个区域 - 签名密钥和密钥签名密钥（因为它自己签名，它也是用于父DS的密钥）。
通过使子服务器哈希为公共KSK并将其发送给其父进程来完成，该父进程将其存储为DS（委托签名）。这是早做的，我不知道如何。
每个区域必须向其父级发送一个（或多个）KSK（当然是公共部分）并让父级计算相关的DS以在其区域中发布，或者只发送{{1直接记录。 DNS树中的每个节点都存在同样的问题，当然除了根。孩子需要在使用相关密钥签署任何内容之前做到这一点，因为他通常无法控制父母在开始发布密钥之前需要多长时间。
DNS树中的每个节点都是相同的，理论上是因为实际上这种信息传输必须在DNS外进行（DS / CDS除外，见下文），这可能在每个节点都不同。它通常涉及至少一些纯粹的人工交互，这解释了为什么ZSK / KSK拆分令人满意，因为它降低了你需要做任何事情来取代KSK的频率。
例如，对于TLD，他们需要在IANA网站上输入流程，提供新的DS记录，然后等待一段时间让IANA在根区域发布之前对其进行处理和验证。
对于2LD（二级域名），他们通常会访问其注册商，并通过某些网站或API提供注册商发送给注册管理机构的信息，以便其发布。 如今，注册商 - 注册管理机构对话是使用名为EPP（可扩展供应协议）的协议进行的，它具有称为secDNS的DNSSEC的特定扩展。 此扩展允许注册商代表其客户发送（基于注册机构政策）：
CDNSKEY记录（作为4个单独的参数）DS记录（作为4个单独的参数），注册表将从中自行计算要发布的相应DNSKEY记录DS记录的DS记录，以便注册表可以仔细检查DS是否已正确计算，并且它确实会匹配某些DNSKEY记录域名已经发布（或多或少按照场上案件频率的降序排列。）
这解决了配置问题。至于树下面的节点，你的标准机制越来越少。
还有另一条路径，这次使用DNS本身来配置事物而不是带外事件，并使用RFC 7344中描述的DNSKEY / CDS记录RFC 8078。领先的C代表Child，然后你再次获得CDNSKEY或DS，因为核心思想是让一个节点在自己的区域中发布这样的记录，然后让父区域进行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证书颁发机构在其私钥的安全性以及如何使用它来签署其他密钥（在这种情况下实际上是证书）方面会遇到几乎相同的问题。