DNSlogging传播需要多长时间？

“DNS传播”本身并不是真正的现象。 相反，这是DNS协议中指定的高速cachingfunction的明显效果。 说DNS服务器之间的“传播”变化是一种方便的虚假，可以说非专业用户更容易解释，而不是描述DNS协议的所有细节。 不过，协议的工作方式并不是这样。

recursionDNS服务器代表客户进行查询。 recursionDNS服务器（通常由ISP或IT部门运行）由客户端计算机用于parsingInternet资源的名称。 recursionDNS服务器caching查询结果以提高效率。 查询已经被caching的信息可以被回答，而不需要做任何额外的查询。 结果caching的持续时间（以秒为单位） 应该基于一个称为生存时间（TTL）的可configuration值。 该值由授权DNS服务器为查询的logging指定。

由于DNS是分布式协议，因此没有人回答所有问题。 DNS的行为取决于给定logging的授权DNS服务器的configuration，代表客户端计算机进行查询的recursionDNS服务器的configuration以及内置于客户端计算机操作系统的DNScachingfunction。

指定一个足够短的TTL值以适应DNSlogging的日常必要变化是一个很好的做法，但要足够长才能在caching中创build一个“胜利”（即不能太快以至于不能快速将caching退出提供任何效率改进）。 使用TTL值的平衡策略会为每个人带来“胜利”。 它降低了给定域，根服务器和TLD服务器的授权DNS服务器的负载和带宽利用率。 它减less了recursionDNS服务器运营商的上行带宽利用率。 这会导致客户端计算机的查询响应更快。

由于DNSlogging的TTL设置较低，因此权威DNS服务器上的带宽利用率将会增加，因为recursionDNS服务器将无法长时间caching结果。 由于logging的TTL较高，对logging的更改不会很快“生效”，因为客户端计算机将继续接收存储在recursionDNS服务器上的caching结果。 设置最佳的TTL可以在利用率和快速更改logging的能力之间取得平衡，并可以看到客户反映的这些变化。

值得注意的是，有些互联网服务供应商滥用权限，忽略权威DNS服务器指定的TTL值（取代自己的pipe理覆盖，这是违反RFC的）。 从技术的angular度来看，没有什么可以做的。 如果滥用DNS服务器的运营商可能向其系统pipe理员投诉，则可能导致他们实施最佳实践（可以说，对于任何熟悉DNS的networking工程师而言，这是常识）。 这种特殊types的滥用不是技术问题。

如果每个人“按规则播放”，DNSlogging的更改可以很快“生效”。 例如，在更改分配给“A”logging的IP地址的情况下，将执行TTL值的指数回退，直到进行改变的时间。 例如，TTL可以在1天开始，在24小时内减less到12小时，然后在12小时内减less到6小时，在6小时内减less到3小时，等等，直到适当的小的间隔。 一旦TTL被撤销，logging可以改变，TTL恢复到日常操作所需的值。 （没有必要使用指数退避，但是这种策略会使logging的TTL时间最短，并减less权威DNS服务器上的负载。）

在DNSlogging更改日志之后，应监视由于旧的DNSlogging而导致的访问尝试。 在更改“A”logging以引用新的IP地址的示例中，服务器应该保留在旧IP地址上，以处理仍然使用旧“A”logging的客户端计算机所导致的访问尝试。 一旦基于旧logging的访问尝试达到了可接受的低水平，则可以废弃旧的IP地址。 如果与旧logging相关的请求没有迅速缓解，则recursionDNS服务器可能（如上所述）忽略权威TTL。 然而，知道访问尝试的源IP地址并不提供关于负责提供旧logging的recursionDNS服务器的直接信息。 如果错误访问尝试的IP地址全部与单个ISP相关，则有可能find违规的DNS服务器并联系其运营商。

就我个人而言，几天之后，我发现立即发生的变化“生效”，在几个小时之内，有些情况下，特定的脑损伤ISP。 做一个TTL回退，注意这个过程是如何工作的，会增加你的成功变化，但是你永远无法确定一些善意的傻瓜可能在recursion的DNS服务器上做些什么。