domain-name-system – 将不同的NS记录设置为权威DNS的权威

概述我有一个域服务器的DNS服务器设置为注册器上的一组权威DNS服务器.但是,域的DNS服务器区域文件具有不同的NS记录集.一些DNS服务器正在快速地将请求传递给区域文件中设置的NS服务器;但是,其他一些(如Google,Level 3和OpenDNS的公共DNS服务器)无法正确解析记录.它们返回正确的NS记录,但不会返回对子委派的DNS服务器的A记录的请求.我在下面提供了大量的输出;但它的要点是,请 我有一个域服务器的DNS服务器设置为注册器上的一组权威DNS服务器.但是,域的DNS服务器区域文件具有不同的NS记录集.一些DNS服务器正在快速地将请求传递给区域文件中设置的NS服务器;但是,其他一些(如Google,Level 3和OpenDNS的公共DNS服务器)无法正确解析记录.它们返回正确的NS记录,但不会返回对子委派的DNS服务器的A记录的请求.我在下面提供了大量的输出;但它的要点是,请求没有被引用到我在QUICKROUTednS.COM设置的NS记录中,该域是指向亚马逊云DNS的NS记录.而是请求在QUICKROUTednS.COM停止.那么,如何指示DNS服务器继续查询作为域的权威的亚马逊,而不更改注册商的DNS记录？

这是一个例子：

域名在注册商处的DNS记录：

name Server: NS1.QUICKROUTednS.COMname Server: NS2.QUICKROUTednS.COMname 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.orgUsing domain server:name: ns-1387.awsdns-45.org.Address: 205.251.197.107#53Aliases:www.domain.com has address 201.201.201.201

然而,当我从任何给定的名称服务器请求它时：

$host www.domain.com 8.8.8.8Using domain server:name: 8.8.8.8Address: 8.8.8.8#53Aliases: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 msnet.            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 msdomain.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 msdomain.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 ns2sub 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专家可以用这个做一些有趣的事情,但这种配置的有效用例很少.普通用户应不惜一切代价避免使用冲突的名称服务器定义.

总结

以上是内存溢出为你收集整理的domain-name-system – 将不同的NS记录设置为权威DNS的权威全部内容，希望文章能够帮你解决domain-name-system – 将不同的NS记录设置为权威DNS的权威所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。