DNSSEC 区域签名密钥 (ZSK)

Question 1

如果您的意思是针对给定区域的所有权威名称服务器，那么他们需要共享密钥，因为它们被发布为 DNSKEY 记录，递归验证客户端将使用这些记录来检查签名。

现在，名称服务器 A 可以发布 ZSK A 的 DNSKEY + 使用 ZSK A 完成的所有 RRSIG，而名称服务器 B 可以拥有 ZSK B + 使用 ZSK B 完成的所有 RRSIG。并且每个服务器都拥有 KSK 的 DNSKEY 和使用相关 ZSK 的 KSK 的 RRSIG。

DNSSEC 验证名称服务器需要找到至少一个正确的密钥和签名路径。因此，理论上，递归名称服务器只访问 nameserverA 并从那里检索所有记录，就可以从那里获得验证记录所需的一切。如果访问 nameserverA，情况也是如此仅有的名称服务器B。

然而问题在于仅有的部分以及缓存的事实，递归名称服务器不会将自己“锁定”到一个权威名称服务器，而是会根据各种算法进行切换。解析名称服务器的缓存中可能混合有数据，例如 DNSKEY A 和来自 B 的 RRSIG。然后，验证将失败。

所以，简而言之，如果它可靠地运行，我会感到非常惊讶。

本文档对此进行了详细讨论：https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/?include_text=1 它试图了解一个域名如何同时使用多个 DNS 提供商进行解析，但仍然具有适当的 DNSSEC 管理，并且根据谁进行签名有不同的场景。

您可以测试一下，但正如 Håkan 所说，在遇到这个问题之前您似乎还有另一个问题。

Answer

如果您的意思是针对给定区域的所有权威名称服务器，那么他们需要共享密钥，因为它们被发布为 DNSKEY 记录，递归验证客户端将使用这些记录来检查签名。

现在，名称服务器 A 可以发布 ZSK A 的 DNSKEY + 使用 ZSK A 完成的所有 RRSIG，而名称服务器 B 可以拥有 ZSK B + 使用 ZSK B 完成的所有 RRSIG。并且每个服务器都拥有 KSK 的 DNSKEY 和使用相关 ZSK 的 KSK 的 RRSIG。

DNSSEC 验证名称服务器需要找到至少一个正确的密钥和签名路径。因此，理论上，递归名称服务器只访问 nameserverA 并从那里检索所有记录，就可以从那里获得验证记录所需的一切。如果访问 nameserverA，情况也是如此仅有的名称服务器B。

然而问题在于仅有的部分以及缓存的事实，递归名称服务器不会将自己“锁定”到一个权威名称服务器，而是会根据各种算法进行切换。解析名称服务器的缓存中可能混合有数据，例如 DNSKEY A 和来自 B 的 RRSIG。然后，验证将失败。

所以，简而言之，如果它可靠地运行，我会感到非常惊讶。

本文档对此进行了详细讨论：https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-provider-dnssec/?include_text=1 它试图了解一个域名如何同时使用多个 DNS 提供商进行解析，但仍然具有适当的 DNSSEC 管理，并且根据谁进行签名有不同的场景。

您可以测试一下，但正如 Håkan 所说，在遇到这个问题之前您似乎还有另一个问题。

Question 2

DNSSEC 区域签名密钥 (ZSK) 是否需要在所有名称服务器上都相同？如果需要，为什么？

区域签名密钥 (ZSK) 和密钥签名密钥 (KSK) 不需要位于任意一个名称服务器上。

根据 DNSSEC 的设计，名称服务器可以使用预先签名的记录来回答查询，包括用于证明查询记录不存在的新记录。

ZSK 只需要由想要签署区域文件的主机拥有，其余名称服务器只需要新签署区域的副本，该副本可以通过主从名称服务器设置传递。

一个简单的设置可能是将 ZSK 放在主名称服务器上。如果从属名称服务器没有签署区域，则它们没有理由知道 ZSK。

编辑：正如 Håkan Lindqvist 所提到的，ZSK 和 KSK 从技术上讲存在于所有名称服务器上，但只有密钥的公共部分以 DNSKEY 记录的形式存在于预签名区域文件中。当我在上面提到 KSK 和 ZSK 时，我指的是密钥的私有部分，这些部分应该保密。