Mar*_*tin 1 domain-name-system
假设我有以下example.com区域：
$TTL 120
@ IN SOA ns1 hostmaster (2018041509
300
150
600
60)
IN NS ns1
IN NS ns2
ns1 IN A 192.168.0.159
ns2 IN A 192.168.0.160
blah IN A 192.168.0.141
如上所示，ns1.example.com并且ns2.example.com是该区域的两个权威名称服务器。其他名称服务器何时查询它们？正如我测试的那样，查询这两条记录的唯一时间是当我使用 DNS 查找实用程序请求NS记录时192.168.0.159，即dig @192.168.0.159 -t NS example.com.
对于普通用户来说，这真的不重要。如果您追求的是域的一致交付和正常运行时间，则规则非常简单：
NS您的名称服务器上的记录应该只指向A和AAAA记录。（不是CNAME记录等）A记录），否则运行单堆栈 IPv4 的 DNS 服务器将无法获取有关您的域的信息。就是这样。实施的方式和原因并不那么重要。如果您偏离此建议，结果将是大量不一致和不可预测的行为。诸如“未定义行为”和“实现特定行为”之类的可怕短语都适用于此。
话虽如此，OP提出的问题是完全公平的。排除客户端的明确请求并排除其他答案的授权部分中的间接引用NS，递归名称服务器何时明确请求这些记录？
您无意中进入了递归 DNS 服务器如何运行的一个比较模糊的领域。据我所知，我们仍然没有对管理互联网标准的修订，阐明这是如何“应该”工作的。
递归 DNS 服务器如何了解您的域的高级概述如下：
www.example.com. IN A.www.example.com. IN A. （或直到错误阻止它进一步遵循路径）在“冷缓存”的情况（想象一个刚重新启动DNS服务器），那就得从从头开始不具体和上走，到最具体的。对于我们的 示例www.example.com. IN A，它将遵循以下一组引用：
.：又名“根”名称服务器。com.：从域名服务器com.学习的顶级域名.服务器。example.com.：example.com.在com.注册表中列出的名称服务器，从com.名称服务器中学习。www.example.com：仅当example.com名称服务器提供了对www. 对于此示例，我们假设情况并非如此。我们对A记录的回答将直接来自example.com.沿着这条路径的每一步，递归服务器都会询问这些服务器是否负责www.example.com并接收到一组更具体的 DNS 服务器的引用。在此过程中，我们无需询问 NS 记录。我们通过推荐了解了更具体的服务器，直到一组服务器最终回复了权威答案www.example.com.（在这种情况下，example.com.名称服务器有我们的答案）
NS我们此时记忆中的记录是通过推荐获得的。就名称服务器而言，这“足够好”，但我们现在有两个问题：
当与引用中的 NS 记录关联的 TTL 到期时会发生什么？
当有人问我们这些 NS 记录的价值时会发生什么？
我们将探讨其中的每一个。
这是名称服务器行为差异很大的地方。虽然它有一些年龄（2011 年 3 月），但我强烈建议阅读Ólafur Guðmundsson涵盖该主题的演示文稿。幻灯片 11 - 13 向我们介绍了几种名称服务器行为模式。我将从 Ólafur 的演讲中借用相同的术语：
Child Centric non sticky:
PPPCCCPPPCCCPPPCCCPP
Child Centric sticky
PPPCCCCCCCCCCCCCCCCC
Parent Centric
PPPPPPPPPPPPPPPPPPPP
在这种情况下，“父”指的是我们通过推荐了解到的 NS 记录。“child”指的是当我们查询第一组 NS 记录以获取 的值时，我们通过收到的权威答案了解到的 NS 记录example.com. IN NS。（即当我们要求这些域名服务器返回他们自己的NS记录时......理论上）
所有这些模式的共同点是内存中的 NS 数据首先从父级学习。这是给定的，因为它是流程运作方式的基础。实现的不同之处在于它们之后的操作：
以儿童为中心的非粘性最初会更喜欢父级，然后切换到子级。一旦子域名过期，NS 记录就会被“遗忘”并从头开始重新学习，以便为合并父域名服务器上的更改提供机会。没有这一点，与过期域相关的名称服务器的更改将不会被捕获 - 其过期和续订。缺点是有时这些 NS 记录定义不一致，导致递归服务器返回针对特定 DNS 记录（即www.example.com. IN A）的不同响应，具体取决于它当前访问的服务器。
以子为中心的粘性是一个非常有问题的实现，其中名称服务器“卡在”定义的子端，并且在清除缓存或重新启动服务器之前不会重新评估父端。由于与之相关的非常明显的问题，它通常被认为是这些实现中最糟糕的。（一个例子是这个问答，有人在观察行为）
以父为中心是一个有趣的实现，它完全避开了子/权威 NS 记录的价值。它背后的一般想法是，父母和孩子的价值观之间的交替会造成比其价值更多的麻烦和混乱。通过完全忽略 NS 记录的“权威”版本并始终更喜欢推荐（没有它，无论如何都无法了解权威记录），您可以完全避免以儿童为中心的非粘性的“触发器”问题。主要缺点是一些边缘情况下，从子侧的NS记录可以有助于加快迁移掉旧的域名服务器前在注册表中进行的更改。当您与某些也提供 DNS 服务的愚蠢注册商打交道时，这可能是有益的，但是当您将域的服务器更改为指向其他地方时，会立即删除所有 DNS 数据。
如您所见，这是一个复杂的主题，如果不进行大量测试，就很难记录下来。它以这种方式工作，因为直到今天，这个领域的标准仍然很宽松，至少就我所知。
再次，这取决于。
RFC 2181强烈反对名称服务器返回从答案部分中的引用中获悉的缓存名称服务器数据，但并未完全禁止它：（“不应该”）
Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as
answers to a received query. They may be returned as additional
information where appropriate. Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased
without cause or excuse.
[...] Note that throughout this document, "authoritative" means a
reply with the AA bit set.
尽管有这个警告，我们可以返回从我们的答案中的推荐中观察到的 NS 记录，因为它没有被明确禁止。我怀疑以父为中心的实现更有可能发生这种情况，但目前我面前没有任何好的数据。当我找到时间并更新这个答案时，我会自己做一些测试。
如果服务器从转诊缓存域名服务器会发生什么，以及做荣誉RFC 2181？在 ISC BIND 的情况下（至少在我最有经验的 9.10 和 9.11 实现中），NS来自客户端的对记录的显式请求会触发对子名称服务器的立即刷新。当客户端名称服务器指向 BIND 认为已损坏的内容时，最容易观察到，例如指向 CNAME 记录的 NS 记录。BIND 最初将能够使用它从初始引用（包括胶水）接收到的信息来回答域，但是域将在NS收到记录请求并且名称服务器尝试重新学习它的名称服务器信息时立即停止工作需要沟通。
结束免责声明：这是递归服务器操作的一个非常模糊和令人困惑的领域。自从我上次深入探讨这个话题以来，有些事情可能已经发生了变化。我很乐意修改此处提供的任何信息，但请尽可能提供具体的数据引用。
| 归档时间： |
|
| 查看次数： |
382 次 |
| 最近记录： |