DNS NSredirect

我遇到了一些我以前从未见过的有趣的东西,希望有人能够帮助解释我所看到的。

以下是这种情况:我有一个域名testdomain.com区域文件,其中包含一个名为SummitNetworks的DNS提供程序。 在我这边,我有一个名为mycustomdomain.com GoDaddy托pipe的域名。 在mycustomdomain.com我有一个mycustomdomain.com的胶水logging,指向位于summitnetwork的名称服务器。

现在我告诉了summitnetworks ,我希望他们为我托pipe的区域testdomain.com指向NS服务器ns2.mycustomdomain.com 。 这样做的原因是,以后如果我select将此区域迁移到新的DNS提供商和一大堆其他域,我只需mycustomdomain上的NS粘合logging更新为新的DNS提供商名称服务器IP 。

现在的问题是,当我对testdomain.com进行挖掘和区域查找时,NS服务器指向了summitnetworks NS服务器,但是参考path指向ns2.mycustomdomain.com 。 这怎么可能,我怎样才能看到使用挖的解决scheme的完整path? 什么是转诊path? 当我对域进行挖掘时,没有提及它。 我能够validation这一点的唯一方法是因为我使用了dnsstuff toolbox

Referall路径

如果没有真实的信息,你的问题很难回答,但是你使用虚荣服务器的理由对我来说是没有意义的,当改变NameServers你想改变你的名字服务器而不是你的粘合剂logging时,你也希望你的SOA成为一个真正的域名服务器而不是胶水logging。

以下是我认为正在发生的事情:example.com的注册商NSlogging与区域的NSlogging不同。

挖个example.com

根服务器将您发送到com服务器,com服务器将您发送到您的注册服务商(godaddy)中列出的名称服务器,但这些服务器没有您的虚荣名称服务器,它们具有真实名称服务器,(尽pipeIP相同)推荐给你真实姓名服务器的logging。

再次, ns1.example.comns2.example.com是您的register.com的名称服务器。

但是这个区域就是这样说的

 @ IN NS ns3.example.com @ IN NS ns4.example.com 

即使ns1.example.com和ns3.example.com是相同的IPlogging,dns也不知道,它看到ns3不是ns1,所以它被称为ns3的权威答案。

我们可以用真实的信息来确认。

如果你想使用虚荣名称服务器,我会build议让你的DNS与Godady。

谢谢你,雅各愿意花时间帮助我, 如果我能,我会给你+100分:)。

我能够用一些工具和DNS逻辑来追踪我的答案。 所以我遇到的第一个问题就是每当我在我的mac上运行一个dig www.example.com +trace ,绝对没有任何东西出现。 起初我以为这是一个域问题,但我尝试了其他领域,并收到相同的空白结果。 那么我说让我试试另一台电脑,瞧,我能够通过DNS解决scheme的全部踪迹,揭示了答案。

所以基本上发生了什么是这样的…当testdomain.com向DNS注册器注册时,注册域名的人指出名称服务器按照指示去到ns1 & ns2.mycustomdomain.com 。 这个过程发生在几百个域。 拥有mycustomdomain.com的人创build了虚拟服务器,粘合logging指向DNS主机提供商。

挖掘痕迹显示的是这个

  1. 第一步 – 查询DNS根服务器以查找要与哪个顶级域名交谈
  2. 第二步 – 查询顶级域名DNS服务器,找出谁是权威的testdomain.com
  3. 第一个结果 – find可以响应查询ns1 & ns2.mycustomdomain.com名称服务器
  4. 第二个结果 – 因为这些胶水logging实际上指向NS服务器@ summitnetworks.com我们得到一个额外的响应与名称服务器ns1 & ns2.summitnetworks.comns1 & ns2.summitnetworks.com ,如果我们没有那些胶水logging挖将结束在子弹3。

现在,这些域和所有未来域的迁移将转到AWS Route 53.我将从summitnetworks.com收到的区域文件当然包括他们的SOA和NS服务器。 当你将你的域名导入到Route53中时,他们会从现在拥有这个域名的angular度剥离SOA和Nameservers。 由于我正在向AWS进行大规模迁移,因此我将创build一个委派集,以便为在AWS中创build的每个域使用相同的名称服务器。 这将使我们所要做的就是更新虚拟服务器的胶水logging,以指向AWS服务器,并添加2个胶水logging,以提高可靠性。

希望这可以帮助任何碰到这个问题的人。

示例dig www.google.com +trace以便您可以按照解决scheme的path:

 ;; global options: +cmd . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. ;; Received 496 bytes from 172.16.0.2#53(172.16.0.2) in 8 ms com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. ;; Received 492 bytes from 198.41.0.4#53(198.41.0.4) in 100 ms google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. ;; Received 168 bytes from 192.26.92.30#53(192.26.92.30) in 99 ms www.google.com. 300 IN A 216.58.192.4 ;; Received 48 bytes from 216.239.38.10#53(216.239.38.10) in 13 ms 

以下是您需要刷新的任何一个好的DNS资源。 当然有一年我的DNS刷新:)

  • 了解DNS
  • 权威vs权威