以前,我以为我能做到：
@H_403_4@dig example.com ns要查看NS记录中剩余的TTL是什么,但现在我明白这个NS记录是区域中子域的NS记录,而不是从根服务器发出的NS记录,这是最终决定的查询将被发送到哪个名称服务器.
我通过在每个提供商的区域中设置测试记录来测试这个：
@H_403_4@Provider1 test.example.com 10.0.0.1 Provider2 test.example.com 192.168.0.1对于两个提供商,NS上的TTL记录为0,而TLD注册器级别的NS记录指向Provider1的名称服务器.
当我更改Provider1区域中的NS记录时,我几乎可以立即看到这反映在NS查询中(使用’dig example.com ns’).
但是,当我发送A记录的查询时,即
@H_403_4@test.example.com它总是回来
@H_403_4@10.0.0.1无论提供者1的区域中的NS记录是什么设置的.
在此基础上,我得出结论,区域文件中的NS记录与迁移无关,并且只有TLD级别的名称服务器记录才是重要的.
但是,我无法了解改变传播的可能性有多长,无论是向前还是向后传播.
是否有可能查询TTL正在使用哪些来自TLD根服务器的记录？
解决方法
On this basis,I’ve concluded that the NS records within the zone file are irrelevant to the migration,and that only the name servers records at the TLD level are important.
这是一个不正确的假设,但很容易犯错误.您可以阅读有关顶级NS记录here的主题的更多信息.简短版本是重要的,并且正在使用的版本将根据缓存DNS服务器先前是否先查询过您的域而不同.
请记住,大多数递归DNS服务器强制执行最小TTL,因此从TTL为零的实验得出的任何结论几乎肯定是不准确的.唯一不存在这种情况的情况是,当您控制要查询的服务器使用的最小TTL策略时.
I am currently migrating a DNS zone from one DNS server provider to another. I am trying to estimate how long it will take for the change to propagate,and to understand what the delay might be if I chose to rollback mid-stream.
我将专注于这个主题,因为你在其余的问题中有一些错误的开头.首先,重要的是要记住TTL缓存在递归DNS服务器上.由于互联网上的每个人都在使用不同的递归DNS服务器,因此您可以做出的唯一假设是它需要n秒,其中n是TTL的值.
这让我们知道哪些TTL与此相关：
>缓存中单个记录的TTL.即使NS记录过期,对缓存中的单个记录的请求也不会自动过期.示例：如果test.example.com IN A从现在起十分钟后到期,但是example.com IN NS从现在起五分钟后到期,即使NS记录发生更改,test.example.com也将保留在缓存中.在记录过期并刷新之前,与新服务器上此记录的值相关的任何问题都不会变得明显.
> TLD DNS服务器提供的NS粘合记录的TTL.这些由递归服务器使用,这些服务器在首次请求时需要获取有关您的域的信息.这些TTL会影响区域文件中列出的DNS服务器用于下次刷新之前的时间. (请参阅上面链接的Q& A I以澄清此事)
>区域文件顶部列出的NS记录的TTL.一旦胶水记录TTL过期,可以使用这些TTL代替.实现因此而异.由于您正在处理整个互联网的不同实现,唯一安全的假设是某些服务器正在使用它.
您不能假设互联网上所有缓存的NS记录TTL都来自一个源或另一个源.这会强制您计划两者中的较高者,除非您真的不关心不运行的递归DNS服务器.
将所有这些放在一起,我们得出以下结论：
>任何给定DNS记录刷新新名称服务器所需的最长时间是该记录,胶水中的NS记录和区域中的NS记录之间的最高TTL.>假设新DNS服务器上的TTL与旧服务器相同,则回滚所需的最长时间是三个TTL的最高值.在您最初更改DNS服务器和还原更改之间登陆新服务器的任何查询都将依赖于从新服务器获取的值.>保持更改中涉及的所有DNS服务器的运行和同步非常重要,直到所有TTL在最终的NS记录更改后过期.您不仅需要所有可用于未获取最新更改的客户端的服务器,而且两者之间的记录数据的任何不一致都会使事情变得更加混乱.