![在权威 DNS 上将不同的 NS 记录设置为权威](https://linux22.com/image/679917/%E5%9C%A8%E6%9D%83%E5%A8%81%20DNS%20%E4%B8%8A%E5%B0%86%E4%B8%8D%E5%90%8C%E7%9A%84%20NS%20%E8%AE%B0%E5%BD%95%E8%AE%BE%E7%BD%AE%E4%B8%BA%E6%9D%83%E5%A8%81.png)
我将某个域的 DNS 服务器设置为注册商上的一组权威 DNS 服务器。但是,这些 DNS 服务器的区域文件为该域提供了一组不同的 NS 记录。一些 DNS 服务器将请求顺利地传递给区域文件中设置的 NS 服务器;但是,其他一些 DNS 服务器(例如 Google、Level 3 和 OpenDNS 的公共 DNS 服务器)无法正确解析记录。它们返回正确的 NS 记录,但子委派 DNS 服务器的 A 记录请求未返回。我在下面提供了大量输出;但要点是,请求没有被引用到我在 QUICKROUTEDNS.COM 为该域设置的 NS 记录,这些 NS 记录指向 Amazon 的云 DNS。相反,请求在 QUICKROUTEDNS.COM 处停止。那么,如何指示 DNS 服务器继续将其查询发送到 Amazon 作为该域的权威服务器,而不更改注册商处的 DNS 记录?
以下是一个例子:
域名在注册商处的 DNS 记录:
Name Server: NS1.QUICKROUTEDNS.COM
Name Server: NS2.QUICKROUTEDNS.COM
Name Server: NS3.QUICKROUTEDNS.COM
提取域的 NS 记录(权威 DNS,QUICKROUTEDNS.COM 已将这些服务器设置为 NS 记录):
$ host -t NS domain.com
domain.com name server ns-1622.awsdns-10.co.uk.
domain.com name server ns-1387.awsdns-45.org.
domain.com name server ns-774.awsdns-32.net.
domain.com name server ns-48.awsdns-06.com.
来自托管域的 Amazon DNS 服务器的 A 记录:
$ host www.domain.com ns-1387.awsdns-45.org
Using domain server:
Name: ns-1387.awsdns-45.org.
Address: 205.251.197.107#53
Aliases:
www.domain.com has address 201.201.201.201
然而,当我从任何给定的名称服务器请求它时:
$ host www.domain.com 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:
Host www.domain.com not found: 3(NXDOMAIN)
几乎每个 DNS 服务器都是一致的,尽管有少数 DNS 服务器会按预期报告 A 记录。
这是尝试提取 A 记录时的 dig +trace 输出:
$ dig @8.8.8.8 www.domain.com A +trace
; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 www.domain.com A +trace
; (1 server found)
;; global options: +cmd
. 1341 IN NS m.root-servers.net.
. 1341 IN NS j.root-servers.net.
. 1341 IN NS a.root-servers.net.
. 1341 IN NS d.root-servers.net.
. 1341 IN NS f.root-servers.net.
. 1341 IN NS c.root-servers.net.
. 1341 IN NS b.root-servers.net.
. 1341 IN NS e.root-servers.net.
. 1341 IN NS i.root-servers.net.
. 1341 IN NS h.root-servers.net.
. 1341 IN NS g.root-servers.net.
. 1341 IN NS l.root-servers.net.
. 1341 IN NS k.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 58 ms
net. 172800 IN NS a.gtld-servers.net.
net. 172800 IN NS e.gtld-servers.net.
net. 172800 IN NS c.gtld-servers.net.
net. 172800 IN NS b.gtld-servers.net.
net. 172800 IN NS g.gtld-servers.net.
net. 172800 IN NS i.gtld-servers.net.
net. 172800 IN NS j.gtld-servers.net.
net. 172800 IN NS k.gtld-servers.net.
net. 172800 IN NS h.gtld-servers.net.
net. 172800 IN NS f.gtld-servers.net.
net. 172800 IN NS d.gtld-servers.net.
net. 172800 IN NS m.gtld-servers.net.
net. 172800 IN NS l.gtld-servers.net.
;; Received 503 bytes from 192.36.148.17#53(192.36.148.17) in 586 ms
domain.com. 172800 IN NS ns1.quickroutedns.com.
domain.com. 172800 IN NS ns2.quickroutedns.com.
domain.com. 172800 IN NS ns3.quickroutedns.com.
;; Received 153 bytes from 192.55.83.30#53(192.55.83.30) in 790 ms
domain.com. 3600 IN SOA cns1.atlantic.net. noc.atlantic.net. 2016033004 28800 7200 604800 3600
;; Received 88 bytes from 69.16.156.227#53(69.16.156.227) in 712 ms
我们可以看到,它只会到达 QUICKROUTEDNS.COM 名称服务器,而不会向 Amazon 名称服务器发出请求。那么,我该如何告诉 DNS 服务器从 Amazon 服务器获取查询,而不是在 QuickRouteDNS.COM 处停止呢?
答案1
这里实际上提出了两个问题,而且它们直接相互矛盾:
- 我如何指示 DNS 服务器继续向 Amazon 进行查询,因为 Amazon 是该域名的权威服务器,而无需更改注册商处的 DNS 记录?
- 我如何告诉 DNS 服务器从 Amazon 服务器获取查询而不是停止在 QuickRouteDNS.COM?
DNS 层次结构中的每个委派都必须比上一个委派更具体。换句话说,您可以委派子域名,但不能重新委派与已委派给您的服务器的名称完全相同。正确的解决方案是在注册商级别更改配置,这是您要避免的。
您现在遇到的是一种常见的错误配置,称为不充分委派(NS 记录不匹配),这给人一种错误的印象,认为这种设计是可以实现的。下面是对正在发生的事情的解释,但如果不很好地掌握 DNS 概念,将很难理解。如果我失去了你,请理所当然地认为更正注册商数据是解决您的问题的正确方法。
为了说明起见,这里有两个区域片段的示例:
$ORIGIN example.com
@ 2941 IN SOA ns1.example.com. someone.example.com. (
2015071001 ; serial
7200 ; refresh (2 hours)
900 ; retry (15 minutes)
7200000 ; expire (11 weeks 6 days 8 hours)
3600 ; minimum (1 hour)
)
@ IN NS ns1
@ IN NS ns2
sub IN NS ns1.contoso.com.
sub IN NS ns2.contoso.com.
在 contoso.com 名称服务器上:
$ORIGIN sub.example.com.
@ 2941 IN SOA ns1.sub.example.com. someone.contoso.com. (
2015071001 ; serial
7200 ; refresh (2 hours)
900 ; retry (15 minutes)
7200000 ; expire (11 weeks 6 days 8 hours)
3600 ; minimum (1 hour)
)
@ IN NS bagel.contoso.com.
@ IN NS bacon.contoso.com.
上述两个区域中的哪些 NS 记录对 具有权威性sub.example.com
?如果您认为是ns1
和ns2.contoso.com
,那您就错了。与普遍看法相反,执行委托的名称服务器并不被视为NS
用于定义该委托的记录的权威性。权威性定义是反而由委托接收端的区域所拥有。
我们已经建立了这一点,bacon
并且bagel
具有权威性。这里不太明显的是,域名服务器不一定会立即意识到这一点。委托是善意的,最初会假定接收委托的服务器是权威的。只有当这些NS
记录被刷新时,才会发生脑损伤。刷新可以由许多因素触发,从委托NS
记录的 TTL 到期到对这些记录值的明确请求NS
。一旦NS
记录被覆盖,就会使用新的服务器。
综上所述,在初始阶段,您将使用注册商定义的名称服务器,随后将使用第二组名称服务器。在第一个阶段,仅存在于第二组服务器上的任何记录都将失效。在第二个阶段,仅存在于第一组服务器上的任何记录都将失效。
听起来问题最终会自行解决(只需等待所有内容刷新),但这永远不会发生。人们会重新启动他们的名称服务器、刷新缓存或建立新的名称服务器。您的域名将处于不一致的不断变化状态,直到记录NS
变得一致。DNS 专家可以利用这一点做一些有趣的事情,但这种配置的有效用例很少。普通用户应不惜一切代价避免冲突的名称服务器定义。
答案2
说“我将某个域的 DNS 服务器设置为注册商上的一组权威 DNS 服务器。但是,这些 DNS 服务器的区域文件为该域设置了不同的 NS 记录。”意味着您创建了一个不完善的委派。您可以就此打住,因为这种设置无法正常工作,所以不要这样做!
有助于排除故障的工具:http://dnsviz.net/和https://www.zonemaster.net/
另外两件事:
- 不用于
host
故障排除,仅dig
(但@something 和+trace 是矛盾的) - 正如@Ward 所说,如果你想得到良好的帮助,请提供你询问的真实域名