我的理解是，如果我将 example1.com 和 example2.us 的名称服务器都设置为 ns1.example2.us 和 ns2.example2.us，则查找 www.example1.com 将：
- 查找 example1.com 以找到其名称服务器，没有产生任何粘合记录（.com 注册机构不会为 .us 域名提供粘合）
- 查找 ns1.example2.us 和 ns2.example2.us (一定两者兼而有之吗？)，其中每一项均将：
- 查询 example2.us，得到 ns1.example2.us 和 ns2.example2.us 的粘合记录
- 显然查询 ns1.example2.us 和/或 ns2.example2.us 以获取 ns1.example2.us 和/或 ns2.example2.us 的地址（它是否正确？这似乎是我的经验）
- 查询 ns1.example2.us 和/或 ns2.example2.us 以获取 www.example1.com 的地址
相反，如果我们将 example1.com 和 example2.com 的名称服务器都设置为 ns1.example2.com 和 ns2.example2.com，则查找 www.example1.com 将：
- 查找 example1.com 以找到其名称服务器，并生成 ns1.example2.com 和 ns2.example2.com 的粘合记录
- 查询 ns1.example2.com 和/或 ns2.example2.com 以获取 www.example1.com 的地址
我是否正确，在这种情况下，查找只有这两个步骤？ 具体来说，我似乎在 example2.com 中遇到了大量查找，这表明对 example1.com 的查找并不总是使用粘合记录，从而导致需要额外的步骤，即通过查询 ns1.example2.com 和/或 ns2.example2.com 来查找 ns1.example2.com 和/或 ns2.example2.com。
（編輯突出我在第一个例子中隐藏的小问题，并尝试在最后澄清我的主要问题。）
也许一些图表会有所帮助，因为我觉得我解释得不好。以下是我对在查找 www.example.com 时应该发生的情况的理解，如果 example.com 的名称服务器是 ns1.host.us 和 ns2.host.us：
第三个查找步骤似乎几乎普遍发生，但对我来说并不完全有意义。 真的应该有第三步吗？
以下是我对查找 www.example.com 时应该发生的情况的理解，如果 example.com 的名称服务器是 ns1.host.com 和 ns2.host.com：
我对这个案例的理解正确吗？
我觉得使用名称服务器 ns1.host.com 和 ns2.host.com 对 www.example.com 进行查询时，大约有 1/3 的查询可能会发生以下情况（基于对各个域的名称服务器的查询数量和时间）：
这实际上可能吗？或者这是否代表客户行为不端？
答案1
补充一下 Mit 的回答。最佳做法是仅有的使用 Glue Records 来解决这些循环依赖。请参阅 RFC1912 的第 2.3 节：http://www.faqs.org/rfcs/rfc1912.html
去引用：
有些人养成了一个坏习惯，即在添加 NS 记录时添加胶水记录以
“确保万无一失”。
区域文件中存在重复的胶水记录只会使名称服务器移动到新 IP 地址或被删除时变得更加困难。您将花费数小时试图弄清楚为什么随机的人仍然看到某些主机的旧 IP 地址，因为有人忘记更改或删除其他文件中的胶水记录。较新的 BIND 版本将忽略本地区域文件中的这些额外胶水记录。
如果您使用 BIND，请注意最后一点。另外，我认为大多数 DNS客户将忽略域外粘合记录，这可以解释您所看到的内容。
编辑跟进评论。
对于 TLD 粘合记录，您通常会将其提供给您的注册商，但其他方面适用相同的规则。我在.co.uk和中运营域名.com。我在这两个 TLD 中都有名称服务器，它们对我的所有域名都具有权威性。
如果我运行dig ns co.uk和dig ns com，我可以看到一大堆对这些 TLD 具有权威性的服务器。如果我选择其中一个列出的.com服务器，dig @<server> ns <mydomain>.com它将返回我的域的所有四个名称服务器，但只返回同一 TLD 中名称服务器的胶合记录（作为 ADDITIONAL 提供），这就是您所描述的。
如果我运行dig @<co.uk server> <myotherdomain>.co.uk，我将再次获得所有四个名称服务器，但这次会附带 TLD 中三个名称服务器的粘合记录.co.uk。
这一切都是理所应当的。如果您的所有名称服务器都在 TLD 中.us，那么寻找您的.com域名的客户端将由服务器告知您的名称服务器的域名.com；然后客户端将在.us服务器上执行另一个查询以查找其 IP。这种额外的往返可能听起来效率不高，但每个客户端每个 TTL 周期只需发生一次。（对于 TLD 记录，通常为 48 小时。）
（如果您已经知道以上所有内容，请原谅。）回答原始问题。胶水记录并非用于保存 DNS 查找。它们是防止无限循环所必需的。
编辑2
抱歉，我绕了一大圈。现在我明白你的意思了（顺便说一下，图表很不错）。
我对客户端行为的理解是，如果有机会获得权威 RR，那么它就应该这样做；但在这种情况下，客户端正在向名称服务器请求其自己的记录，这是没有意义的，因为 Glue是那些 A 记录。
我的知识已经到了极限，但我想不出客户端需要这样做的任何情况。我在这里猜测，但也许客户端实现需要检查服务器是否对 ns_.host.us 具有权威性，即使这意味着看似毫无意义的额外往返。
尝试一下，dig +trace www.example.com看看它是否做了同样的事情。我很好奇，如果原来的查询也是针对 _.host.us 名称。
答案2
委托中的域名服务器通过名称而不是 IP 地址来标识。这意味着解析域名服务器必须发出另一个 DNS 请求来查找它被指派到的服务器的 IP 地址。如果委托中给出的名称是提供委托的域的子域，则存在循环依赖关系。在这种情况下，提供委托的域名服务器还必须为委托中提到的权威域名服务器提供一个或多个 IP 地址。此信息称为粘合。委托域名服务器以 DNS 响应附加部分中的记录形式提供此粘合，并在响应的应答部分提供委托。
例如，如果 example.org 的权威名称服务器是 ns1.example.org，则尝试解析 www.example.org 的计算机首先解析 ns1.example.org。由于 ns1 包含在 example.org 中，因此需要先解析 example.org，这会产生循环依赖关系。为了打破这种依赖关系，org 顶级域的名称服务器除了 example.org 的委托外，还包含 glue。glue 记录是提供 ns1.example.org IP 地址的地址记录。解析器使用其中一个或多个 IP 地址来查询域的权威服务器之一，从而完成 DNS 查询。这可能会解决问题。
答案3
胶水旨在引导那些原本无法解析的查询。想象一下没有胶水的情况：
- 查询 www.example1.com 的根，获取对 com 名称服务器的推荐。
- 查询 www.example1.com 的 com 名称服务器，获取对 ns1.example.com（example1.com 的名称服务器）的引用。
- 哎呀，我们没有 ns1.example1.com 的 IP。查询 ns1.example.com 的 com 名称服务器。
- 转到 3。
com 名称服务器需要返回 ns1.example.com 的 A 记录，否则您永远无法到达那里。
您仍然可能会遇到管辖范围外的委派问题，因为权威名称服务器通常不会返回这些委派的粘合记录。例如：
- 查询 com 名称服务器中的 ns1.example1.com，得到答案 ns1.example1.us
- 向美国名称服务器查询 ns1.example1.us，得到答案 ns1.example.com
- 转到 1
哎呀——com 名称服务器和 us 名称服务器都不会返回超出管辖范围的引用的 glue。DJB 有一些更详细的例子。
无论如何，glue 并非一种捷径，而是一种避免循环的机制。缓存提供了保存查找的机制。