如果出现粘合记录不一致的情况,会发生什么情况?在子区域的父区域中列为NS
服务器的每个单个服务器始终权威地回答有关子区域的记录,但不一定NS
在子区域本身内列为服务器?
例如,如果b.dns.ripn.net.
父区域的su.
表示我的由 IP 地址为corporate.su.
的服务器控制,但是当连接到 时,会发生以下某些情况:d.ns.corporate.su.
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 +nssearch
和dig +trace
,但它似乎dig
受到各种污染和无声修复问题的影响,并且并没有使幕后实际发生的事情变得那么明显。
答案1
现在的问题是您的域名仍然没有被委托。
从我查看的域名whois信息来看,您今天注册了该域名。您的域名已注册但尚未授权;
whois corporate.su | grep state
state: REGISTERED, NOT DELEGATED
这nic.ru 常见问题解答实际上,委托实际生效需要 6 小时到几天的时间。
话虽如此,当我查询你的一个即将被授权和权威名称服务器。
您总共有 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
您应该注意这里的三件事。
1- 该答案是权威的(AA 标志) 2- 它没有在权威部分提供 NS 记录 3- 您的区域仍然没有 SOA
这意味着,1- 您的域名目前没有任何类型的 Glue 记录。2- corporate.su 的权威名称服务器都不属于委派路径的一部分。
看了您的问题,这里有一些更正;
例如,如果父区域 su 的 b.dns.ripn.net. 表示我的 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
但是如果胶水正确,而区域错误...那么您将遇到解决问题的问题。如果您的胶水错误,但区域正确,情况就不会那么糟糕...一点也不干净...但也没有那么糟糕。
如果我的域服务器的父区域中有多条这样的 NS 记录,它们都可以权威地回答有关我的区域的查询,但其中全部或部分记录在实际子区域内的记录名称存在某种不匹配,与父区域相矛盾,该怎么办?
有了 DNS,您的 SOA 就无所不能。Glue 记录应该与 SOA 解析您的委托名称服务器相匹配,而不是相反。