domain-name-system – 具有名称服务器粘合记录的TLD何时保存DNS查找？

概述我的理解是,如果我将example1.com和example2.us的名称服务器设置为ns1.example2.us和ns2.example2.us,查找www.example1.com将： >查找example1.com以查找其名称服务器,不会产生粘合记录(.com注册表不会为.us域提供粘合剂) >查找ns1.example2.us和ns2.example2.us(必须两者？),每个都将： > 我的理解是,如果我将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时应该发生什么的理解,如果exam​​ple.com的名称服务器是ns1.host.us和ns2.host.us：

第三个查找步骤似乎几乎普遍发生,但对我来说并不完全有意义.第三步应该真的存在吗？

如果exam​​ple.com的名称服务器是ns1.host.com和ns2.host.com,那么我在查看www.example.com时应该会发生什么：

我对这个案子的理解是否正确？

以下是我认为可能会发生的事情,大约1/3的www.example.com查询使用名称服务器ns1.host.com和ns2.host.com(基于对各个域的名称服务器的查询的数量和时间) ：

这实际上是否可行和/或它是否代表一个行为不端的客户？

解决方法 添加到Mit的答案.最佳实践是仅使用glue Records来解决这些循环依赖关系.请参阅RFC1912： http://www.faqs.org/rfcs/rfc1912.html的2.3节

报价：

Some people get in the bad habit of
putting in a glue record whenever
they add an NS record “just to make
sure”. Having duplicate glue
records in your zone files just makes
it harder when a nameserver moves
to a new IP address,or is removed.
You’ll spend hours trying to figure
out why random people still see the
old IP address for some host,
because someone forgot to change or
remove a glue record in some other
file. Newer BIND versions will ignore
these extra glue records in local
zone files.

如果您正在使用BIND,请注意最后一位.此外,我认为大多数DNS客户端都会忽略额外的域粘合记录,这可以解释您所看到的内容.

编辑以跟进评论.

使用TLD胶水记录,您通常会将其提供给您的注册商,但是否则适用相同的规则.我在.co.uk和.com中运行域名.我在这两个TLD中都有名称服务器,这些名称服务器对我的所有域都具有权威性.

如果我运行dig ns co.uk并挖掘ns com,我可以看到对这些TLD具有权威性的大堆服务器.如果我选择其中一个列出的.com服务器并挖掘@< server> ns< mydomain> .com它将返回我的域的所有四个名称服务器,但只返回同一TLD中名称服务器的粘合记录(作为ADDITIONAL提供),这就是您所描述的.

如果我运行dig @< co.uk server> < myotherdomain> .co.uk,我将再次获得所有四个名称服务器,但这次伴随着.co.uk TLD中其中3个的胶水记录.

这应该是应有的.如果您的所有名称服务器都在.us TLD中,那么查找.com域名的客户端将被.com服务器告知您的名称服务器的域名;然后客户端将在.us服务器上执行另一个查询以查找其IP.额外的往返可能听起来效率低下,但每个客户每TTL周期只需要进行一次. (TLD记录通常为48小时.)

(如果您已经了解以上所有内容,请道歉).回答原来的问题.胶水记录不用于保存DNS查找.它们是防止无限循环所必需的.

编辑2

对不起,围绕这个问题胡言乱语.我现在明白你的意思了(顺便说一下好的图表).

我对客户应该如何表现的理解是,如果有机会获得权威的RR,那么它应该;但在这种情况下,客户端要求名称服务器提供自己的A记录,这是没有意义的,因为glue是那些A记录.

我在这里达到了我的知识极限,但我想不出为什么客户需要这样做的任何情况.我猜这里,但也许客户端实现需要检查服务器肯定是ns_.host.us的权威,即使这意味着什么看起来像一个毫无意义,额外的往返.

尝试挖掘跟踪www.example.com,看它是否做同样的事情.如果原始查询也是_.host.us名称,我很想知道它是否执行相同的查找.

总结

以上是内存溢出为你收集整理的domain-name-system – 具有名称服务器粘合记录的TLD何时保存DNS查找？全部内容，希望文章能够帮你解决domain-name-system – 具有名称服务器粘合记录的TLD何时保存DNS查找？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。