什么情况下会查询区域顶点的 NS 记录？

Question

在正常操作期间，什么时候查询区域顶点定义的 NS 记录？

据我研究，这些记录由以下人员使用：

• DNS NOTIFY，当主服务器发生更改时，主服务器会向从属服务器发出信号，让其拉取 SOA 并更新其区域文件。

• 一些工具，用于验证 DNS 区域定义的正确性

• 迭代 DNS 解析器，如果它们缓存了某个区域的权威 NS 记录，它们将使用它们来回答该区域的查询，而不是转到根/TLD/父服务器

• 服务器本身，声明自己是其区域的权威（虽然我并不确信这是事实，但我认为这是由每个 DNS 实现加上父 DNS 服务器引用 NS 记录在外部设置的，而不是在区域文件中设置，或者通过 SOA 记录设置）

我不明白的是，在什么情况下迭代 DNS 解析器会缓存区域的 NS 记录除非他收到专门针对该区域 NS 记录的查询

让我详细说明一下。据我了解，当具有空缓存的迭代解析器被赋予对资源的查询（例如IN A www.example.com.）时，它将：

1. 向根 DNS 服务器查询IN A www.example.com.

1.1. 它将收到一个空的答案部分

1.2. 权威部分，包含区域的 NS 记录.com.（这些记录不具有权威性）。

1.3. 它将缓存这些非权威的 NS 记录（如果它是以子为中心的非粘性或以父为中心的）。尽管 RFC 2181 规定您不应该这样做。

2. 向TDL .com.DNS 服务器查询IN A www.example.com.

2.1. 与上述交易相同，但非权威 NS 记录适用于example.com.

3. example.com.向NS 服务器查询IN A www.example.com.

3.1 获得权威答案www.example.com.

3.2 它会缓存收到的A记录。

3.3 它将向客户端返回答案

在上述交换过程中，迭代解析器从未发出查询IN NS example.com.或IN NS .com.任何其他查询权威性任何区域的 NS 记录。因此，据我所知，除非迭代 DNS 解析器的某些客户端/用户恰好发出了确切的查询IN NS example.com.，否则迭代解析器将绝不缓存权威的 NS 记录IN NS example.com.

以上情况属实吗？或者迭代 DNS 解析器实现是否会触发区域的 NS 查询，以便缓存其权威 NS 记录并加快对同一域的未来查询？或者，如果客户端随机查询区域的 NS 记录，它们是否只会缓存权威 NS 记录？在 DNS 解析器实现中是否存在常见或最流行的模式？

参考：

• DNS 域顶端的 NS 记录起什么作用？
• 何时查询 DNS 域顶点的 NS 记录？
• https://www.rfc-editor.org/rfc/rfc1034
• https://www.rfc-editor.org/rfc/rfc1035
• https://www.rfc-editor.org/rfc/rfc2181
• https://www.zytrax.com/books/dns/ch8/ns.html
• DNS 查找顺序是如何确定的？
• https://stackoverflow.com/questions/57828833/when-following-a-referral-for-an-a-record-in-an-dns-iterative-query-should-the

Answer 1

我认为确实有一个主要情况会偏离你所述的期望，还有一个不太常见的情况，两者都是特定于实现的：

• 的权威服务器将记录example.com添加NS到其对 的响应中www.example.com. IN A。这不是必须的，但它可以这样做。传统上，这是相当常见的行为。

  • 例如：除非minimal-responses启用该选项，否则 BIND 会执行此操作。

• 解析器服务器查找example.com. IN NS是遵循引荐的一部分。传统上这不是一种常见行为。

  • harden-referral-path示例：如果启用该选项，Unbound 将执行此操作（以及更多操作） 。

Answer 2

算法请见https://www.rfc-editor.org/rfc/rfc7816#appendix-A仅涉及 NS 记录的使用及其使用方法。

查询NS记录对于查找区域切割是必要的，这对于正确的 DNSSEC 验证以及 QNAME 最小化是必要的。

有关 QNAME 最小化的 RFC 7816 第 2 节中这样说道：

实施 QNAME 最小化且缓存中没有答案的解析器不会向上游发送完整的 QNAME 和原始 QTYPE，而是向原始 QNAME 已知最近祖先的权威名称服务器发送请求。
请求通过以下方式完成：

o QTYPE NS

o QNAME 是原始的 QNAME，被剥离为仅比服务器具有权威的区域多一个标签

以这种方式使用NS记录使得客户端（递归名称服务器）不会与其正在查询的权威名称服务器共享有关当前飞行请求的任何数据。

确实，在第 3 节中它解释了为了绕过一些损坏的名称服务器，你（递归客户端）可能需要尝试A记录而不是NS记录。然而，对于其他损坏的 DNS 服务器，这仍然是一种解决方法。

此外，在普遍的观点中，DNS 是“以子节点为中心”的，这意味着相关的 NS 集来自子节点而不是父节点，因为它是唯一可以在 DNSSEC 中签名的记录集（引用不在 ANSWER 部分中）。但如果解析器只这样做并且只在子节点处重新检查，则意味着域永远不会消失或更改名称服务器……因此解析器必须定期检查父节点的 NS。

请参阅目前正在进行的草案：https://datatracker.ietf.org/doc/draft-huque-dnsop-ns-revalidation/?include_text=1

其中有以下相关段落：

从官方角度来看，子区域的顶点 NS RRset 是权威的，因此比父区域的委托 NS RRset 具有更高的缓存可信度，后者是非权威的粘合剂（[RFC2181]，第 5.4.1 节。排名数据）。因此，当迭代缓存 DNS 解析器跨越区域边界时，“区域切割下方”的 NS RRset 应立即在缓存中替换父区域的委托 NS RRset。但是，这只有在以下情况下才会发生：(1) 解析器在来自子区域的响应的权威部分中收到权威 NS RRset（这不是强制性的），或者 (2) 解析器在其迭代解析算法中明确向子区域发出 NS RRset 查询。在没有这个的情况下，迭代缓存解析器可能永远无法了解某个区域的权威 NS RRset，除非解析器的下游客户端明确发出这样的 NS 查询，而这不是正常的最终用户应用程序所做的事情，因此不能依赖于任何规律性的发生。

然后在第 3 节中记录以下有关递归名称服务器何时以及为何应发出NS记录类型请求以正确重新验证其数据的所有详细信息。

请注意，此文档目前正在征求 IETF DNS 工作组的意见。如果采纳，它可能会稍后成为完整标准 (RFC)。