这是关于DNS传播的规范问题
各种类型的记录传播需要多长时间?
有些传播比其他传播快吗?
为什么DNS记录传播需要花费时间,它如何工作?
这是关于DNS传播的规范问题
各种类型的记录传播需要多长时间?
有些传播比其他传播快吗?
为什么DNS记录传播需要花费时间,它如何工作?
Answers:
本质上,“ DNS传播”不是一个真正的现象。相反,它是DNS协议中指定的缓存功能的明显效果。说在DNS服务器之间更改“传播”是一个方便的错误,可以说,与描述DNS协议的所有详细信息相比,向非技术用户更容易解释。不过,协议的工作原理并非如此。
递归DNS服务器代表客户端进行查询。客户端计算机通常使用ISP或IT部门运行的递归DNS服务器来解析Internet资源的名称。递归DNS服务器缓存其查询结果,以提高效率。无需进行任何其他查询就可以回答对已缓存信息的查询。缓存结果的持续时间(以秒为单位)应基于称为生存时间(TTL)的可配置值。此值由权威DNS服务器为查询的记录指定。
由于DNS是一种分布式协议,因此没有一个问题可以回答所有问题。DNS的行为取决于给定记录的权威DNS服务器的配置,代表客户端计算机进行查询的递归DNS服务器的配置以及客户端计算机操作系统中内置的DNS缓存功能。
优良作法是指定一个TTL值足够短,以适应DNS记录的日常必要更改,但又要足够长,以在缓存中创造一个“胜利”(即不要太短,以至于缓存过期太快而无法提供任何效率改善)。采用具有TTL值的平衡策略会为每个人带来“胜利”。它可以减少给定域的权威DNS服务器,根服务器和TLD服务器的负载和带宽利用率。它为递归DNS服务器的运营商降低了上行带宽利用率。这样可以更快地查询客户端计算机。
由于设置了DNS记录的TTL,较低的负载和权威DNS服务器上的带宽利用率将增加,因为递归DNS服务器将无法长时间缓存结果。由于记录的TTL较高,因此对记录的更改似乎不会很快“生效”,因为客户端计算机将继续接收存储在其递归DNS服务器上的缓存结果。设置最佳TTL归结为利用率与快速更改记录并查看反映在客户端上的更改之间的平衡。
值得注意的是,某些ISP滥用并且忽略了由权威DNS服务器指定的TTL值(替换为它们自己的管理替代,这违反了RFC)。从技术的角度来看,这没有什么可做的。如果可以定位滥用DNS服务器的运营商,则他们的系统管理员可能会抱怨他们会实施最佳实践(对于熟悉DNS的网络工程师来说,这可能是常识)。这种特殊类型的滥用不是技术问题。
如果每个人都“按规则行事”,对DNS记录的更改很快就会 “生效”。例如,在更改分配给“ A”记录的IP地址的情况下,将执行TTL值的指数补偿,从而导致进行更改的时间。例如,TTL可能从1天开始,然后在24小时内减少到12小时,然后在12小时内减少6小时,在6小时内减少3小时,等等,直到某个适当的小间隔。一旦取消了TTL,就可以更改记录,并且可以将TTL恢复到日常操作所需的值。(不必使用指数退避,但是此策略可最大程度地减少记录的TTL较低的时间,并减少权威DNS服务器上的负载。)
进行DNS记录更改后,应监视日志以查找由于旧DNS记录而导致的访问尝试。在将“ A”记录更改为引用新IP地址的示例中,服务器应保留在旧IP地址处,以处理由于客户端计算机仍在使用旧“ A”记录而导致的访问尝试。一旦基于旧记录的访问尝试达到了可以接受的低水平,则可以废弃旧IP地址。如果与旧记录相关的请求没有迅速减少,则递归DNS服务器可能会忽略权威TTL(如上所述)。但是,知道访问尝试的源IP地址不会提供有关负责提供旧记录的递归DNS服务器的直接信息。
就个人而言,几天后,我看到变化立即“生效”,并且在某些情况下使用特定的大脑受损ISP。减少TTL并注意该过程如何工作将增加成功的更改,但是您永远无法确定某些好意的白痴可能会对它们的递归DNS服务器做什么。
1.1.1.1
or 8.8.8.8
或9.9.9.9
or )组成的庞大团队(Anycast云)80.80.80.80
。重要的是要了解它们是任意广播的:答复可能会根据源IP进行更改,因为它可能会命中一个完全不同的物理实例,并且它们拥有的缓存可能对所有实例都是全局的。