您的问题非常广泛，与编程无关。
就像 Calle 说的那样，您已经基本正确，所以让我指出一些要修复的部分。
首先，要记住的重要部分是所有这些都是基于非对称加密：每个密钥都是公共和私有部分。公共部分在DNSKEYRR 中发布，并且在记录中也有一些散列DS，而私有部分用于计算RRSIG记录。任何使用公钥的人都可以验证RRSIG记录中的签名确实是由某个特定的私钥签名的，而永远无法访问它。
现在谈谈你的一些观点：
在区域级别，该过程使用一对或多对密钥进行工作。首先，区域服务器拥有 ZSK（区域签名密钥）并使用私有 ZSK 对查询的数据进行签名。之后，它将公共 ZSK、数据 (RRSET) 和签名数据 (RRSIG) 发送到 DNS 解析器。
在给定区域的自动名称服务器上，您从区域的内容开始，未签名。在没有 DNSSEC 的过去，这正是发布的内容。现在你至少有这三个选项：
- 一个外部进程获取该区域并对其进行签名；这完全取决于您的密钥的管理方式：如果它们在 HSM 中，那么您需要将记录发送到那里进行签名，因为按照设计，私钥（需要对记录进行签名）永远不会离开硬件模块。例如，请参阅OpenDNSSEC 软件。
- 解析器本身，在加载时或通过单独的工具可以对区域本身进行签名，甚至管理密钥（因为它们会定期更改）；请参阅Bind中的此示例。
RRSIG或者，没有事先签名，解析器将在查询到达时生成（并缓存一段时间）记录。看看一家大供应商是如何做到的。
当然，每种解决方案都有其优点和缺点。他们都存在于球场上。
但现在你必须信任公共 ZSK。解决方案？要拥有另一个密钥，KSK（密钥签名密钥）。
KSK/ZSK 拆分并不是真正的信任，只是关键材料管理。
让我们回过头来一点。理论上，DNSSEC 的整个设置可以以完全相同的方式工作，每个区域中只有一个密钥。
但实际上它通常是更多的键。
首先，密钥需要定期更换。它们没有特定的原因或寿命终止，只是假设如果我们想防御离线密钥破解，我们只需要定期更改它们。密钥的发布没有关于其持续时间的详细信息（与RRSIGs 中的签名相反），但每个 DNSSEC 签名区域都应该有一个DPS（DNSSEC 实践声明），除其他外，该 DPS 深入研究每个密钥的有效期（参见其他答案我了解有关 DPS 的更多详细信息）。当然，要为密钥翻转做准备，您需要提前在 DNS 中发布一个新密钥，以便缓存了解它，然后再开始使用它进行签名（或至少在停止使用旧密钥签名之前）。
所以你已经可以同时处理多个键了。
现在您处于两个相反的限制之中：您希望尽可能长时间地继续使用一个键以减少处理（如果该键是在外部处理的，则使用它的次数越少越好），因为它也通过记录存在于父区域DS，同时您知道为了更好的安全设置，您需要在尽可能短的时间内使用它并经常更新它。
您可以通过进行 KSK/ZSK 拆分来解决这个难题。
为什么？因为您可以为每个密钥附加不同的生命周期。KSK 也将通过DS记录存在于父区域中，因此通常是您不想经常更改的东西。通常，KSK 将是最安全的密钥（最受保护的密钥），并将“持续”1 或 2 年（这必须在 DPS 中详细说明）。然后，用于真正签署 zone 中记录的 ZSK 可以是更频繁地生成的密钥，比如 1 或 2 个月，因为它们的更改只需要反映在 zone 本身中，不需要在 parent 更改任何内容区。
例如，参见IANA 根区密钥仪式：只有一个根密钥（绝对信任），将来可能会发生变化（去年10月就已经计划好了，但后来被推迟了）；无论如何，每年两次在某些数据中心举行特定的密钥仪式，这里到底会发生什么？DNS 根区域运营商 VeriSign 带有特定数量的密钥（实际上是未来的 ZSK），它们值得一段时间（基本上直到下一次仪式，有一些余量，基于相关 DPS 中详述的典型 ZSK 生命周期） )，然后正确使用根 KSK，并在多个级别有许多见证人来签署这些 ZSK。然后可以将 KSK 放回存储中并且不再使用（直到下一次仪式），然后 DNS 运营商可以开始发布 ZSK，并带有相关签名。
同样，这是惯例，但肯定不是强制性的。一些区域（例如.CO.UK，看看它如何只有一条DNSKEY记录）决定只使用一个密钥，这称为 CSK for Common Signing Key，这意味着它同时是一个区域签名密钥和一个密钥签名密钥（因为它自己签名，它也是用于父 DS 的那个）。
它是通过使子服务器散列其公共 KSK 并将其发送给其父服务器来完成的，父服务器将其存储为 DS（委托签名）。做的比较早，不知道怎么做。
每个区域都必须向其父级发送一个（或多个）KSK（当然是公共部分），并让父级计算相关内容DS以在其区域中发布，或者直接发送DS记录。DNS 树中的每个节点都是同样的问题，当然除了根节点。并且孩子需要在使用相关密钥签署任何内容之前做这件事，因为他通常无法控制父母在开始发布密钥之前需要多长时间。
DNS 树中的每个节点都是相同的，理论上是因为在实践中，这种信息传输必须在 DNS 的带外完成（除了CDS/ CDNSKEY，见下文），并且每个节点可能不同。它通常至少涉及一些纯粹的人类交互，这解释了为什么 ZSK/KSK 拆分是令人愉悦的，因为它降低了您需要做任何事情来替换 KSK 的频率。
例如，对于 TLD，他们需要在 IANA 网站上输入一个流程，提供新的 DS 记录，然后等待一段时间让 IANA 处理和验证，然后再将其发布到根区。
对于 2LD（二级域名），他们通常去他们的注册商并通过一些网站或 API 提供注册商将发送给注册局的信息，以便它可以发布它。如今，注册商与注册机构之间的对话是使用称为EPP（可扩展配置协议）的协议进行的，并且它具有 DNSSEC 的特定扩展名为secDNS。此扩展允许注册商代表其客户发送（基于注册策略）：
- 记录（作为 4 个单独的
DS参数）
DNSKEY记录（作为 4 个单独的参数），注册中心将根据该记录自行计算要发布的适当DS记录DS带有封闭（相关）记录的DNSKEY记录，以便注册管理机构可以仔细检查 DS 是否正确计算，并且它确实与DNSKEY域已发布的某些记录相匹配
（它或多或少按现场案件发生频率的降序排列）。
这解决了配置问题。至于树下的节点，您拥有的标准机制越来越少。
还有另一条路径，这次使用 DNS 本身而不是带外配置，使用RFC 7344和RFC 8078中描述的CDS/记录。前导 C 代表 Child，然后你又得到了，或者因为核心思想是让节点在自己的区域中发布这样的记录，然后让父区域进行 DNS 查询以获取它，然后为父区域提供它。CDNSKEYDSDNSKEY
当然，这确实会产生一些问题，至少对于引导而言。而这些机制目前并没有被过多地使用。特别是对于 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 证书颁发机构在其私钥的安全性以及它如何使用它来签署其他密钥（在这种情况下实际上是证书）方面将面临几乎相同的问题。