Dns 为什么NSEC3记录的盐应该公开？

我想知道为什么NSEC3记录应该包括盐？我无法想象解析程序为什么以及如何使用盐？

NSEC3案例中使用的盐会随着时间的推移而变化。甚至建议对其进行更改。因此，在任何给定的时间点，可以使用不同的salt计算2条NSEC3记录

看

区域必须至少有一套完整的NSEC3 RRs
使用相同的盐值

盐应定期更换，以防止预计算 用一种盐。建议将盐更换为
每次重新签名

以下内容更为详细：

请注意，这可能会导致解析器看到具有不同名称的RRs 同一区域的盐值。这是无害的，因为每个RR 独立（也就是说，它拒绝其 使用NSEC3RR中的salt的散列位于两个散列之间 在NSEC3 RR中，只有服务器需要一个完整的集合 使用相同盐的NSEC3 RRs，以便能够回答每个问题 可能的查询

不禁止使用含不同盐的NSEC3 RRs 在同一区域内。但是，为了使权威服务器 能够始终找到涵盖NSEC3 RRs的权威 服务器必须选择一组参数（算法、salt和
迭代）在选择NSEC3 RRs时使用

salt不用于计算NSEC3记录，而是使用salt，并将其名称证明为不存在，以进行散列，有关完整算法，请参阅

阅读第5.5节可能会有所帮助。解析程序需要对名称本身进行散列（因此需要知道散列算法、salt值和迭代次数，这些都在NSEC3记录中），以查看应用了哪些NSEC3记录

以上参考中的所有详细信息，对于查询

x.2.example.org TXT

的回复为：

15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. (
    NSEC3 1 0 2 DEAD 1AVVQN74SG75UKFVF25DGCETHGQ638EK NS SOA RRSIG
           DNSKEY NSEC3PARAM )

   1avvqn74sg75ukfvf25dgcethgq638ek.example.org. (
       NSEC3 1 0 2 DEAD 75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ )

   75b9id679qqov6ldfhd8ocshsssb6jvq.example.org. (
    NSEC3 1 0 2 DEAD 8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ TXT RRSIG )

以下是分解器内部发生的情况：

“x.2.example.org”的散列是“ndtu6dste50pr4a1f2qvr1v31g00i2i1”。
在第一个NSEC3上检查此散列会得到它不在“15bg9l6359f5ch23e34ddua6n1rihl9h”到“1avvqn74sg75ukfvf25dgcethgq638ek”之间的间隔。对于第二个NSEC3，答案也是否定的：哈希排序超出了“1avvqn74sg75ukfvf25dgcethgq638ek”和“75B9ID679QQQOV6LDHD8OCSHSSSB6JVQ”所描述的间隔。 第三个NSEC3，间隔为“75b9id679qqov6ldfhd8ocshsssb6jvq”到
“8555T7QEGU7PJTKSNBCHG4TD2M0JNPJ”也没有任何帮助

然后，冲突解决程序将通过执行以下操作来发现最近的遭遇：

冲突解决程序不断对源文件中越来越短的名称进行哈希运算 查询名称，直到NSEC3的所有者名称匹配为止。这个主人 name是最近的封闭器

因此，简言之，验证解析器需要哈希来完成所有这一切