这是一个例子：
域名在注册商处的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服务器中都是一致的,尽管有一个FEW会按预期报告A记录.
尝试拉A记录时,这是一个挖掘跟踪输出：
- $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名称服务器而不是从亚马逊名称服务器请求.那么,我如何告诉DNS服务器从亚马逊服务器获取其查询而不是停在QuickRouteDNS.COM？
解决方法
>如何指示DNS服务器继续查询亚马逊作为域的权威,而不更改注册商的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记录的权威.权威定义由委托接收端的区域拥有.
我们已经确定培根和百吉饼是权威的.这里不那么明显的是,名称服务员不一定会立即意识到这一点.各代表团都是真诚地遵循的,最初将假定接收授权的服务器具有权威性.只有当那些NS记录被刷新时才会发生脑损伤.刷新可以由任意数量的事件触发,从委派的NS记录的TTL到期到对那些NS记录的值的显式请求.一旦覆盖了NS记录,就会使用新服务器.
总而言之,您的注册商定义了名称服务器的初始阶段,然后是使用第二组名称服务器的时间段.在第一个期间,任何仅存在于第二组服务器上的记录都将失败.在第二个期间,任何仅存在于第一组服务器上的记录都将失败.
听起来好像问题最终会自行解决(只是等待一切都要刷新),但这种情况永远不会发生.人们将重新启动他们的名称服务器,刷新他们的缓存,或者站起来新的名称服务器.在NS记录变得一致之前,您的域将以不一致的状态存在. DNS专家可以用这个做一些有趣的事情,但这种配置的有效用例很少.普通用户应不惜一切代价避免使用冲突的名称服务器定义.
