您的问题非常广泛，与编程无关。
就像 Calle 所说的那样，您已经基本正确，所以让我指出一些需要修复的部分。
首先，要记住的重要部分是所有这些都基于非对称加密：每个密钥都是公共和私有部分。公共部分发布在DNSKEY RRs 中，并且在DS 记录中也有一些散列，而私有部分用于计算RRSIG 记录。任何使用公钥的人都可以验证RRSIG 记录中的签名确实由某个特定的私钥签名，但永远无法访问它。
现在谈谈你的一些观点：
在区域级别，该过程使用一对或多对密钥进行工作。首先，区域服务器拥有 ZSK（区域签名密钥）并使用私有 ZSK 对查询的数据进行签名。之后，它将公共 ZSK、数据 (RRSET) 和签名数据 (RRSIG) 发送到 DNS 解析器。
在给定区域的自动名称服务器上，您从区域的内容开始，未签名。在没有 DNSSEC 的过去，这正是发布的内容。
现在你至少有这三个选项：
当然，每种解决方案都有其优点和缺点。他们都在场上。
但现在您必须信任公共 ZSK。解决方案？要拥有另一个密钥，KSK（密钥签名密钥）。
KSK/ZSK 拆分并不是真正的信任，只是关键材料管理。
让我们回过头来。理论上，DNSSEC 的整个设置可以以完全相同的方式工作，每个区域中只有一个密钥。
但实际上它通常是更多的键。
首先，密钥需要定期更换。它们没有特定的原因或寿命终止，只是假设如果我们想防御离线密钥破解，我们只需要定期更改它们。密钥在发布时没有详细说明其持续时间（与RRSIGs 中的签名相反），但每个 DNSSEC 签名区域都应该有一个DPS（DNSSEC 实践声明），其中包括每个密钥的有效期（看到这个other answer of me for more details on DPS）。
当然，要为密钥更新做准备，您需要提前在 DNS 中发布一个新密钥，以便缓存了解它，然后再开始使用它进行签名（或至少在停止使用旧密钥签名之前）。
所以你已经可以同时处理多个键了。
现在您处于两个相反的限制之中：您希望尽可能长时间地使用一个键以减少处理（如果键是在外部处理的，则使用它的次数越少越好) 因为它也通过DS 记录存在于父区域中，同时您知道为了更好的安全设置，您需要尽可能短地使用它并经常更新它。
您可以通过拆分 KSK/ZSK 来解决这个难题。
为什么？因为您可以为每个密钥附加不同的生命周期。 KSK 也将通过DS 记录存在于父区域中，因此通常是您不想经常更改的内容。通常，KSK 将是最安全的密钥（最受保护的密钥），并将“持续”1 或 2 年（这必须在 DPS 中详细说明）。然后，用于真正签署 zone 中记录的 ZSK 可以是更频繁地生成的密钥，比如 1 或 2 个月，因为它们的更改只需要反映在 zone 本身中，不需要在 parent 更改任何内容区域。
例如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（可扩展的供应协议）的协议进行的，并且它具有名为secDNS 的DNSSEC 特定扩展。
此扩展允许注册商代表其客户发送（基于注册策略）：
-
DS 记录（作为 4 个单独的参数）
-
DNSKEY 记录（作为 4 个单独的参数），注册表将根据该记录自行计算要发布的适当 DS 记录
-
DS 记录带有一个封闭的（相关的）DNSKEY 记录，以便注册表可以仔细检查 DS 是否正确计算，并且它确实匹配某些域已经发布的 DNSKEY 记录李>
（或多或少按现场案件发生频率的降序排列）。
这解决了配置问题。至于树下的节点，您拥有的标准机制越来越少。
还有另一条路径，这次是使用 DNS 本身而不是带外配置，使用 CDS/CDNSKEY 记录，如 RFC 7344 和 RFC 8078 中所述。前面的 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 证书颁发机构在其私钥的安全性以及它如何使用它来签署其他密钥（在这种情况下实际上是证书）方面会遇到几乎相同的问题。