我们的域名是由Enom托pipe的。 DNSlogging由Enom的印度经销商pipe理，名为Pugmarks。 我们希望将来自Enom / Reseller的DNSloggingpipe理服务切换到AWS Route53，然而，保留Enom作为域名注册商。
域名DNSlogging的TTL为300（5分钟）。 我检查了名称服务器的TTL，发现它是3600（1小时）。
当我们用Route53replaceEnom Name Server时，Enom立即停止parsing域名。 在TTL过期之后，在哪个ISP DNS服务器之后。 我们的网站stream量下降（如谷歌分析）。 这个影响被理解了。
一段时间后，在通过公共/开放域名服务器（如4.2.2.2-4.2.2.6和8.8.8.8＆8.8.4.4）查询域名的NSlogging时，我们得到更新的指向Route53的logging：ie
dig NS <domain.com> @8.8.4.4. 以上命令显示Route53名称服务器logging。 同样，所有其他logging都成功显示（A，CNAME等），表明名称服务器更改已被这些DNS服务器成功获取。 在这一点上，我们观察Google Analytics（分析）中的美国stream量缩放。
但是，印度的交通仍然是零。 我曾经向两个不同的印度ISP（几乎不向公众开放/限制ISP用户）询问一些DNS服务器。 这些不会返回任何logging。 我们等了4个小时让ISP跟上logging的变化，但徒劳无益。
奇怪的是，美国地区能够获得新的logging，而我们尝试过的印度ISP（至less有5家）没有一家可以select这个变化。 networking上的其他每个DNStesting工具都可以在这里select除ISP之外的更改。 导致交通stream量大幅下降，这是该网站的目标受众所关注的主要问题。
经过4个小时的等待观察，我们将条目切换回Enom名称服务器。 只需几秒钟，印度ISP就能够解决logging，就好像它总是查询Enom服务器的logging，即使TTL是1小时。 （路线53将继续解决，所以美国的交通保持不变）
我有两个疑问：
就我而言，第1点是主要的嫌疑犯。 这是一个链接 ，提供有关该域的详细信息。 它显示父母名称服务器为48小时TTL，而本地名称服务器为1小时TTL。 这可能是造成这个问题吗？
我想将DNSpipe理转移到Route53，并且我不能有超过6小时的停机时间。 我们已经尝试了长达4小时的徒劳。
为什么会发生这种情况，出路是什么？
也许有一种方法是将所有的DNSlogging保存到TTL（TTL大于父节点NSlogging的TTL），然后在TTL改变logging传播之后切换名称服务器。 但是，这不是万无一失的，可以尝试。
（这是一个老问题，但仍然值得回答）
显然你做的是这样的：你准备了新的域名服务器，以权威的方式为你的域名解答quesirws。 然后，您切换注册（即，更改dnsindia.com负责com的父DNS服务器的NS条目指向新的DNS服务器）; 同时旧名称服务器停止回复关于dnsindia.com查询（或者用NXDOMAIN回复）。
因此，影响 – 尤其是对于主要受众 – 的影响如下：在一个1小时之后，在印度ISP的DNSparsing器上caching的任何数据都会被caching – 但只有您input的数据，例如www.india.com Alogging。 因此，parsing器将尝试查询适当的名称服务器以获取新数据。 然而，查询服务器的信息还没有老化：这个信息来自com区域，TTL为48小时（可能还有47小时，比如平均24小时）。 因为这是指旧服务提供商现在不存在的DNS服务器，故障发生在您观察的位置。 另一方面，查询远程parsing器将会成功，因为不太可能拥有父级NSlogging的caching副本。
如何正确地做到这一点？ 以下策略是可能的（按照优先级的降序）：
a）确保旧的DNS服务器在转换后（父TTL）至less48小时内继续为您的区域提供服务，但时间不长。 其实这是我大部分时间用的方法， 旧的服务器pipe理员只需记住稍后删除区域。
b）确保旧的DNS服务器允许recursion查询（至less在你的区域和至less48小时）; 请注意，某些区域的“官方”DNS服务器的服务器通常不允许recursion查询
c）在移动区域之前，将所有logging的本地TTL改为96小时。 然后等待48小时，然后再行动。 这样，parsing器通常应该有一个caching中的DNSlogging的副本，比存储过时的NSlogging长。 这种方法并不完美，并且成为问题，特别是如果域之间存在“交叉引用”，或者存在比主要logging查询次数less的logging。
d）或者，在移动区域之前将父母的 TTL降低到1小时（或者认为可以接受的停机时间），等待48小时，然后进行移动。 但是，不可能在父区域将TTL值改变为如此低的值（他们不希望被频繁查询），即使如此，也必须考虑其区域更新时间表