NS 中的不匹配和父区域中的粘合记录，其中每个 NS 仍然是 auth

Question

粘合记录不一致会发生什么情况，其中NS在子区域的父区域中列为服务器的每台服务器始终权威地回答有关子区域的记录，但不一定列为NS子区域本身内的服务器？

例如，如果b.dns.ripn.net.父区域的su.说 mycorporate.su.由d.ns.corporate.su.具有 IP-address的服务器控制2001:db8::d，但是当连接到 时2001:db8::d，会发生以下一些事情：

• 该corporate.su.区域本身是存在服务器上的权威性2001:db8::d，但没有任何提及NS服务器可以解析到的IP地址2001:db8::d

• d.ns.corporate.su.的NS服务器列表中缺少的记录corporate.su.，但存在另一条NS记录 ，d.ns.example.net.但仍可解析为2001:db8::d

  • 如果d.ns.corporate.su.来自父区域的 仍然在子区域解析，但解析为另一个 IP 地址，该怎么办？
  • 如果d.ns.corporate.su.在我的权威服务器上甚至没有解析，与父区域的胶水相反怎么办？

如果NS我的域服务器的父区域中有几个这样的记录，它们都权威地回答了关于我的区域的查询，但是所有或其中的一部分在实际子区域内的记录名称中存在某种不匹配的情况，这与父区域相矛盾怎么办区？

我试过使用dig +nssearchand dig +trace，但它似乎dig受到各种污染和无声愈合问题的困扰，并且并没有让幕后实际发生的事情变得那么明显。

Answer 1

现在的问题是您的域仍未被委派。

从我在域的whois信息中看到的，您今天注册了它。您的域名已注册但尚未授权；

whois corporate.su | grep state
state:         REGISTERED, NOT DELEGATED

该nic.ru常见问题实际上说，它需要6个小时，几天之间为代表团真正生效。

话虽如此，当我查询您即将被委托和授权的名称服务器之一时，您的区域文件中似乎有很多 NS 条目。

您总共有 9 个 NS 条目。

dig +noall +answer @ns4.linode.com corporate.su ns
corporate.su.       86400   IN  NS  ns5.he.net.
corporate.su.       86400   IN  NS  d.ns.corporate.su.
corporate.su.       86400   IN  NS  d.ns.cns.su.
corporate.su.       86400   IN  NS  ns5.linode.com.
corporate.su.       86400   IN  NS  ns4.linode.com.
corporate.su.       86400   IN  NS  ns4.he.net.
corporate.su.       86400   IN  NS  ns2.linode.com.
corporate.su.       86400   IN  NS  ns2.he.net.
corporate.su.       86400   IN  NS  ns3.he.net.

您需要了解所有这 9 个名称服务器都将是权威名称服务器。这意味着他们将使用 AA 标志回答，并且不会对corporate.su 进行递归查询。

您在注册商表单中包含的五个名称服务器是委派名称服务器。

whois corporate.su | grep nserver
nserver:       any.ns.cns.su.
nserver:       d.ns.corporate.su.
nserver:       lon.ns.cns.su.
nserver:       ns2.he.net.
nserver:       ns4.linode.com.

其中，只有 d.ns.corporate.su 需要父区域中的粘合记录。

原因是为了解析您的域的任何其他委派名称服务器，解析器不需要知道如何解析您的域。（即循环依赖）。

委托名称服务器实际上应该与权威名称服务器相匹配。因此，您应该检查您的区域并删除在您的注册商中找不到的 NS 条目。

或者反过来……但同样……拥有 9 个委托名称服务器和/或权威名称服务器是相当矫枉过正的。

回复评论；

当区域之间的名称不匹配时会发生什么

如果两个权威名称服务器之间不匹配，那么您就会遇到很多问题……通常，SOA 将占上风。

如果我的解析器检测到冲突，它会将查询发送到 SOA（在您的情况下为 d.ns.cns.su）。

不会对corporate.su 进行递归查询”——你这是什么意思？他们为什么要这样做？他们已经是权威的，并且拥有所有区域信息

他们不应该，这正是我的观点。如果他们中的两个发送冲突的区域信息，他们会使用 AA 标志......我应该理所当然地认为他们发送给我的是正确的信息。

至于 Glue 记录，在您的情况下，它仍然不是问题……您的域没有被委派。

dig @a.dns.ripn.net d.ns.corporate.su

; <<>> DiG 9.8.1-P1 <<>> @a.dns.ripn.net d.ns.corporate.su
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35421
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;d.ns.corporate.su.     IN  A

;; AUTHORITY SECTION:
su.         3600    IN  SOA a.dns.ripn.net. hostmaster.ripn.net. 650151100 86400 14400 2592000 3600

;; Query time: 150 msec
;; SERVER: 193.232.128.6#53(193.232.128.6)
;; WHEN: Wed Feb 13 21:30:42 2013
;; MSG SIZE  rcvd: 96

您应该在这里注意 3 件事。

1- 该答案是权威的（AA 标志） 2- 它没有在权威部分提供 NS 记录 3- 您的区域仍然没有 SOA

这意味着，1- 您的域目前没有任何类型的 Glue 记录。2-corporate.su 的权威名称服务器都不是委托路径的一部分。

看着你的问题，这里有一些更正；

例如，如果 b.dns.ripn.net。父区域 su。说我的corporate.su。由服务器 d.ns.corporate.su 控制。

嗯，真的不是。

dig @b.dns.ripn.net corporate.su soa

没有 SOA，没有提供委托。

如果来自父区域的 d.ns.corporate.su. 仍然在子区域解析，但解析到另一个 IP 地址，该怎么办？

如果 d.ns.corporate.su. 甚至不能在我的权威服务器上解析，与父区域的胶水相反？

我建议您阅读我在meta.serverfault.com上针对这种情况提供的答案

但是如果 Glue 是对的，而你的 Zone 是错的……那么你将有解决问题的办法。如果您的 Glue 是错误的，但您的区域是正确的，那么它并没有那么糟糕......根本不干净......但也没有那么糟糕。

如果我的域服务器的父区域中有几个这样的 NS 记录，它们都权威地回答了有关我的区域的查询，但是所有或其中的所有记录的名称在实际子区域内的记录名称存在某种不匹配，这与父区？

使用 DNS，您的 SOA 是万能的。胶水记录应该与 SOA 将您的委托名称服务器解析到的内容相匹配，而不是相反。