☰

NS 记录冲突集

tag-icon • tag-icon domain-name-system ns-record
NS 记录冲突集

检查域的 NS 记录时，根据我查询的名称服务器，我会得到一组名称服务器、另一组名称服务器或两者。

例如，使用 Google DNS 检查，它将随机返回 Rackspace...

;; ANSWER SECTION:
example.com.        21599   IN  NS  ns2.rackspace.com.
example.com.        21599   IN  NS  ns.rackspace.com.

...或 Linode。

;; ANSWER SECTION:
example.com.        21599   IN  NS  ns5.linode.com.
example.com.        21599   IN  NS  ns1.linode.com.
example.com.        21599   IN  NS  ns3.linode.com.
example.com.        21599   IN  NS  ns4.linode.com.
example.com.        21599   IN  NS  ns2.linode.com.

事情变得更加奇怪了。如果我询问根名称服务器（例如 h.gtld-servers.net），或者如果我使用 MX Toolbox 等在线域名检查器，我会得到两个都名称服务器集。

;; AUTHORITY SECTION:
example.com.        172800  IN  NS  ns2.rackspace.com.
example.com.        172800  IN  NS  ns.rackspace.com.
example.com.        172800  IN  NS  ns1.linode.com.
example.com.        172800  IN  NS  ns2.linode.com.
example.com.        172800  IN  NS  ns3.linode.com.
example.com.        172800  IN  NS  ns4.linode.com.
example.com.        172800  IN  NS  ns5.linode.com.

我无法直接控制该域名。但是，那些对托管在 Network Solutions 的域名有直接控制权的人说，他们只能在他们的终端上看到 Linode NS 记录，而且距离他们上次更改 DNS 设置已经过去了 48 小时以上。

这很奇怪，我从未见过这样的事情。我该如何开始诊断这里可能出了什么问题？如果 Network Solutions 仅包含 Linode 服务器，那么根名称服务器如何获取 Rackspace 名称服务器？

答案1

Jenny D 已经告诉你了需要解决的核心问题（事实上你应该使用在线故障排除工具比如 Zonemaster 或 DNSViz 来帮助你排除 DNS 故障），但简而言之，你正处于所谓的“蹩脚委派”的情况之一。

当父级和子级的 NS 集不一致时，就会发生这种情况，如果您不想出现操作名称解析问题，它们应该始终匹配。

简而言之，对于任何给定的名称，父区域都会列出此名称的 NS 记录，当您查询这些名称服务器中的任何一个时，它们应该再次返回相同的 NS 记录列表，否则委托是“无用的”。在大多数情况下，递归名称服务器将相信名称服务器的子集而不是父集。

让我们dig（！）进一步了解您的具体情况，visitnc.com（您应该将其放在问题中，而不是作为评论）

1）在你父母的权威域名服务器上，即.COM，这是回复：

$ dig @a.gtld-servers.net visitnc.com NS +noall +authority

; <<>> DiG 9.12.0 <<>> @a.gtld-servers.net visitnc.com NS +noall +authority
; (1 server found)
;; global options: +cmd
visitnc.com.        172800 IN NS ns2.rackspace.com.
visitnc.com.        172800 IN NS ns.rackspace.com.
visitnc.com.        172800 IN NS ns1.linode.com.
visitnc.com.        172800 IN NS ns2.linode.com.
visitnc.com.        172800 IN NS ns3.linode.com.
visitnc.com.        172800 IN NS ns4.linode.com.
visitnc.com.        172800 IN NS ns5.linode.com.

因此，母公司向全世界宣布您的域名由 7 个权威域名服务器提供服务。这本身并没有什么错……如果所有 7 个都同意此列表的话。

2）现在让我们查询每一个，看看它们是否都具有相同的信息。

例如：

$ for ns in ns.rackspace.com.  ns2.rackspace.com. ns1.linode.com. ns2.linode.com. ns3.linode.com. ns4.linode.com. ns5.linode.com. ; do dig @$ns visitnc.com NS +noall +answer ; done

为了简洁起见，我们编辑了结果，基本上

ns.rackspace.com.并且ns2.rackspace.com. 相信（由于配置如此，所以返回答案）您域名的权威名称服务器是：

visitnc.com.        86400 IN NS ns.rackspace.com.
visitnc.com.        86400 IN NS ns2.rackspace.com.

那就是他们自己。

但与此同时，5 个 Linode 中的每一个都在说：

visitnc.com.        86400 IN NS ns4.linode.com.
visitnc.com.        86400 IN NS ns3.linode.com.
visitnc.com.        86400 IN NS ns1.linode.com.
visitnc.com.        86400 IN NS ns2.linode.com.
visitnc.com.        86400 IN NS ns5.linode.com.

那就是他们自己。

但正如您所看到的，它们都没有像父级那样回复相同的内容，因此您遇到了“不充分的委派”情况，这很糟糕，您需要通过一劳永逸地确定哪家公司是您的 DNS 设置的处理者，然后更改父区域以仅列出其名称服务器来解决这个问题。您需要通过您的注册商（whois visitnc.com | grep Registrar:显示它是网络解决方案有限责任公司) 来请求此更改。这是您应该做的第一件事，然后稍等片刻，然后再尝试任何其他类型的故障排除。

请注意上述故障排除的这一要点：我们总是明确地说我们查询哪个名称服务器，然后我们绝不在此步骤中查询递归名称服务器。在解决 DNS 问题时，您首先需要确保所有权威名称服务器都正确响应，然后才能开始搜索递归名称服务器中发生的情况。以不同的方式执行只会导致您花费更多时间遵循错误的提示。

顺便提一下，您会发现SOA记录非常不同，包括序列号。Rackspace 服务器回复：

visitnc.com.        300 IN SOA ns.rackspace.com. hostmaster.rackspace.com. (
                1527624042 ; serial
                3600       ; refresh (1 hour)
                300        ; retry (5 minutes)
                1814400    ; expire (3 weeks)
                300        ; minimum (5 minutes)
                )

Linode 提供的内容：

visitnc.com.        86400 IN SOA ns1.linode.com. mklauss.outpostdesign.com. (
                2018052959 ; serial
                14400      ; refresh (4 hours)
                14400      ; retry (4 hours)
                1209600    ; expire (2 weeks)
                86400      ; minimum (1 day)
                )

由于最新的设置，特别86400是 TTL 和负 TTL，在更改任何内容后，您需要至少等待这么多秒（即 1 天）和看到父权威名称服务器显示更新的信息。请注意，NS 记录上的父 TTL 是这个数量的两倍，因此悲观的方法是等待任何更改后至少 48 小时，然后重新开始检查并排除需要修复的问题。

答案2

whois visitnc.com返回域的以下内容：

Name Server: NS1.LINODE.COM
Name Server: NS2.LINODE.COM
Name Server: NS3.LINODE.COM
Name Server: NS4.LINODE.COM
Name Server: NS5.LINODE.COM
Name Server: NS2.RACKSPACE.COM
Name Server: NS.RACKSPACE.COM

检查注册商的名称服务器设置。如果 Rackspace 记录存在，请将其删除。如果不存在，您需要询问域名注册商为什么它们会出现在 whois 中。

答案3

有一项名为 Zonemaster 的服务可以检查 DNS 错误并根据可用标准和最佳实践为您提供报告。针对该服务运行您的区域会显示委派和一致性错误，而这正是问题的根源。

当您查找以 .com 结尾的主机名时，您的计算机会询问 .com 名称服务器在哪里可以找到您的域名的信息。在这种情况下，.com 名称服务器列出了 Rackspace 和 Linode 名称服务器。但 Rackspace 服务器和 Linode 服务器彼此不同步。

域负责人应该查看https://zonemaster.net/test/9e6531748fa412d3显示所有错误，并努力将其域从 Rackspace 中删除。

相关内容