有人能简单地向我解释一下DNSSEC是如何工作的吗？
我已经能理解的(但我不知道它是否完全正确)是：
DNS是在早期互联网中创建的一个旧协议，因此它有缺陷(例如没有身份验证)。它允许像中间人和缓存中毒这样的攻击。
解决方案？DNSSEC的创建。一种使用公钥加密并为DNS查询提供身份验证和完整性的协议。它使用从根DNS服务器开始的信任链工作——这里的"信任"意味着你信任根服务器的公钥。
在区域级别中，该过程使用一对或多对密钥。首先，区域服务器具有ZSK(区域签名密钥)，并使用专用ZSK对查询的数据进行签名。之后，它将公共ZSK、数据(RRSET)和签名数据(RRSIG)发送到DNS解析器。但现在你必须信任大众ZSK。解决方案？要获得另一个密钥，KSK(密钥签名密钥)。区域对包含公共KSK和公共ZKS的新集合进行签名。在它发送该新集合、已签名集合和公共KSK之后。它保证了该地区的安全。
但是DNS需要的整个递归过程呢？我们如何确保它也是安全的？这是通过使子服务器散列其公共KSK并将其发送给其父服务器来完成的，父服务器将其存储为DS(委托签名)。它做得很早，我不知道怎么做。这样，如果你信任父亲，并且父亲有孩子DS，如果你散列孩子的公共KSK，结果等于父亲DS，你就可以信任孩子。这就形成了整个信任链。这个链的安全入口点在根中。您假设您可以信任根的公钥。
这就是我认为我对DNSSEC的理解，如果有人能更好地解释，修复我写的内容，或者提供更多你认为理解DNSSEC至关重要的信息，我将不胜感激。
此外，如果有人能向我解释DNSSEC架构和密钥管理，我也会很高兴。
非常感谢！！！！！
您的问题非常宽泛，与编程没有太大关系。
就像Calle说的，你基本上已经是正确的了，所以让我找出一些需要修复的部分。
首先，需要记住的重要部分是，所有这些都是基于非对称密码学的：每个密钥都是公共和私有部分。公共部分在DNSKEYRR中发布，在DS记录中也进行了一些哈希，而私有部分用于计算RRSIG记录。任何使用公钥的人都可以验证RRSIG记录中的签名是否确实由某个特定的私钥签名，而永远无法访问它
现在谈谈你的一些观点：
在区域级别，进程使用一对或多对密钥进行工作。首先，区域服务器具有ZSK(区域签名密钥)，并使用专用ZSK对查询的数据进行签名。之后，它将公共ZSK、数据(RRSET)和签名数据(RRSIG)发送到DNS解析器。
在给定区域的自动命名服务器上，您从未签名的区域内容开始。在过去没有DNSSEC的日子里，这正是发表的内容。现在你至少有这三个选项：
- 一个外部进程获取该区域并对其进行签名；这完全取决于密钥的管理方式：如果它们在HSM中，那么您需要将记录发送到那里进行签名，因为根据设计，私钥(签名记录所需)永远不会离开硬件模块。例如，请参阅OpenDNSSEC软件
- 解析器本身，在加载时或通过单独的工具可以对区域本身进行签名，甚至可以管理密钥(因为密钥会定期更改)；请参阅绑定中的此示例
- 或者，事先没有任何签名，解析器将在查询到达时生成(并缓存一段时间)
RRSIG记录。看看一家大型供应商是如何做到这一点的
当然，每种解决方案都有其优点和缺点。他们都存在于球场上。
但现在你必须信任公众ZSK。解决方案？要获得另一个密钥，KSK(密钥签名密钥)。
KSK/ZSK的拆分实际上不是关于信任，只是关键材料管理。
让我们回到过去一点。DNSSEC的整个设置理论上可以完全相同的方式工作，每个区域只有一个密钥。
但在实践中，它往往是更多的钥匙。
首先，钥匙需要定期更换。它们没有具体的原因或寿命，只是假设如果我们想防止离线密钥破解，我们只需要定期更换它们。密钥的发布没有关于其有效期的详细信息(与RRSIGs中的签名相反)，但每个DNSSEC签名区域都应该有一个DPS(DNSSEC实践声明)，其中深入研究了每个密钥的有效期(有关DPS的更多详细信息，请参阅我的另一个回答)。当然，为了准备密钥回滚，您可以提前在DNS中发布一个新密钥，以便缓存了解它，然后再开始使用它进行签名(或者至少在停止使用旧密钥进行签名之前)。
因此，您可能已经不得不同时处理多个密钥。
现在，您正处于两个相反的约束之中：您希望尽可能长时间地使用一个键，以减少处理(如果从外部处理该键，则使用该键的次数越少越好)，因为它也通过DS记录存在于父区域中，同时你也知道，为了更好的安全设置，你需要尽可能短的时间使用它，并经常更新。
您可以通过KSK/ZSK拆分来解决这个难题。
为什么？因为您可以为每个密钥附加不同的生存期。KSK也将通过DS记录存在于父区域中，因此通常是您不想经常更改的内容。通常，KSK将是最安全的密钥(最受保护的密钥)，并将"持续"1或2年(这必须在DPS中详细说明)。然后，用于对区域中的记录进行真正签名的ZSK可以是更频繁生成的密钥，比如1个月或2个月，因为其中的更改只需要反映在区域本身中，不需要更改父区域中的任何内容。
例如，IANA根区密钥仪式：只有一个根密钥(绝对信任)，未来可能会发生变化(去年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证书颁发机构在私钥的安全性以及如何使用私钥对其他密钥进行签名(在这种情况下实际上是证书)方面也会遇到几乎相同的问题。