低DNS延迟是快速Internet浏览的关键因素。 为了使其最小化，重要的是仔细选择DNS服务器和
匿名中继 。 但是首先要做的是摆脱无用的查询。
这就是DNS最初被创建为高度缓存的协议的原因。 区域管理员为单个记录设置生存期（TTL），解析器在将记录存储在内存中时会使用此信息，以避免不必要的流量。
缓存有效吗？ 几年前，我的小研究表明它并不完美。 看一下当前的状况。
为了收集信息，我修补了
加密的DNS服务器以存储响应的TTL值。 它定义为每个传入请求的条目的最小TTL。 这很好地概述了TTL实际流量的分布，并且还考虑了单个请求的受欢迎程度。 服务器的修补版本工作了几个小时。
结果数据集包含1,583,579个记录（名称，qtype，TTL，时间戳）。 这是TTL的一般分布（X轴为TTL，以秒为单位）：
除了86,400的小土堆（主要用于SOA记录）外，很明显TTL处于低范围。 让我们仔细看看：
嗯，超过1小时的TTL在统计上并不显着。 然后关注0-3600范围：
0至15分钟内的大多数TTL：
0至5分钟的绝大多数时间：
这不是很好。
累积分布使问题更加明显：
在一半的DNS响应中，TTL为1分钟或更短，四分之三为5分钟或更短。
但是，等等，这实际上更糟。 毕竟，这是来自权威服务器的TTL。 但是，客户端解析器（例如，路由器，本地缓存）从更高解析器接收TTL，并且每秒减少一次。
因此，客户端实际上可以平均使用每个记录的原始TTL的一半，之后它将发送新的请求。
也许这些非常低的TTL仅涉及不寻常的请求，而不涉及流行的网站和API？ 让我们看看：
X轴为TTL，Y轴为查询受欢迎度。
不幸的是，最流行的查询也被最糟糕的缓存。
放大：
结论：一切真的很糟糕。 以前很糟，但是变得更糟。 DNS缓存实际上已变得毫无用处。 由于使用ISP的DNS解析器的人越来越少（有充分的理由），延迟的增加变得越来越明显。
DNS缓存仅对没有人访问的内容有用。
另请注意，软件对低TTL的解释可能
有所不同 。
为什么会这样？
为什么为DNS记录设置了这么小的TTL？
- 过时的负载均衡器保留默认设置。
- 有神话说DNS负载平衡取决于TTL（事实并非如此-自从Netscape Navigator时代以来，客户端从RR集中选择一个随机IP地址，如果无法连接则透明地尝试另一个IP地址）
- 管理员希望立即应用更改，因为它更容易计划。
- DNS服务器或负载平衡器的管理员认为他的任务是有效地部署用户请求的配置，而不是加快站点和服务的速度。
- 低TTL使您高枕无忧。
- 人们最初将低TTL设置为进行测试，然后忘记更改它们。
我没有在列表中包括“故障转移”，因为这都不太重要。 如果您只需要将用户重定向到另一个网络以显示错误页面，则当其他所有问题都已经中断时，可以接受超过1分钟的延迟。
此外，分钟TTL表示如果权威DNS服务器被阻止超过1分钟，则其他任何人都无法访问从属服务。 如果原因是配置错误或黑客攻击，冗余将无济于事。 另一方面，有了合理的TTL，许多客户端将继续使用以前的配置，并且永远不会注意到任何东西。
对于低TTL，主要应归咎于CDN服务和负载平衡器，尤其是当它们将CNAME与小TTL结合在一起并使用同样小（但独立）的TTL记录时：
$钻raw.githubusercontent.com
raw.githubusercontent.com。 9在CNAME github.map.fastly.net中。
github.map.fastly.net。 20英寸151.101.128.133
github.map.fastly.net。 20英寸151.101.192.133
github.map.fastly.net。 20英寸151.101.0.133
github.map.fastly.net。 20英寸151.101.64.133
每当CNAME或任何A记录过期时，您都必须发送新请求。 两者都有30秒的TTL，但不匹配。 实际平均TTL为15秒。
但是等等！ 更糟。 在某些情况下，某些解析器的行为很差，并带有两个相关的低TTL：
$钻raw.githubusercontent.com @ 4.2.2.2
raw.githubusercontent.com。 1 IN CNAME github.map.fastly.net。
github.map.fastly.net。 1英寸151.101.16.133
Level3解析器可能适用于BIND。 如果您继续发送此请求，将始终返回TTL为1，
raw.githubusercontent.com本质上讲，永远不会缓存
raw.githubusercontent.com 。
这是一个非常流行的域的情况的另一个示例：
$钻探detectportal.firefox.com @ 1.1.1.1
detectportal.firefox.com。 25 IN CNAME detectportal.prod.mozaws.net。
detectportal.prod.mozaws.net。 26在CNAME中detectportal.firefox.com-v2.edgesuite.net。
detectportal.firefox.com-v2.edgesuite.net。 CNAME中的10668 a1089.dscd.akamai.net。
a1089.dscd.akamai.net。 10英寸104.123.50.106
a1089.dscd.akamai.net。 10英寸104.123.50.88
至少三个CNAME记录。 w 一个人拥有不错的TTL，但完全没用。 在其他CNAME中，初始TTL是60秒，但是对于
akamai.net域
akamai.net最大TTL是20秒，并且它们都没有同相。
不断轮询Apple设备的域又如何呢？
$ rill 1-courier.push.apple.com @ 4.2.2.2
1-courier.push.apple.com。 CNAME中的1253 1.courier-push-apple.com.akadns.net。
1.courier-push-apple.com.akadns.net。 1在CNAME中gb-courier-4.push-apple.com.akadns.net。
gb-courier-4.push-apple.com.akadns.net。 1英吋17.57.146.84
gb-courier-4.push-apple.com.akadns.net。 1英吋17.57.146.85
使用Level3解析器时，Firefox遇到的相同问题和TTL在大多数情况下会卡住1秒。
投寄箱？
$钻取client.dropbox.com @ 8.8.8.8
client.dropbox.com。 7在CNAME client.dropbox-dns.com中。
client.dropbox-dns.com。 59英寸A 162.125.67.3
$钻取client.dropbox.com @ 4.2.2.2
client.dropbox.com。 1在CNAME client.dropbox-dns.com中。
client.dropbox-dns.com。 1英寸162.125.64.3
与Facebook域一样，
safebrowsing.googleapis.com的TTL为60秒。 同样，从客户的角度来看，这些价值减半了。
如何设置最小TTL？
使用名称，请求类型，TTL和最初保存的时间戳，我编写了一个脚本来模拟150万个通过缓存解析器的请求，以便估算由于缓存条目过期而发送的额外请求的数量。
在现有记录到期后，提出了47.4％的请求。 这太高了。
如果设置了最小TTL，对缓存会有什么影响？
X轴是最小TTL值。 源TTL大于此值的记录不受影响。
Y轴-已具有缓存记录但已过期并发出新请求的客户端请求的百分比。
只需在5分钟内设置最小TTL，“额外”请求的百分比就会从47％降低到36％。 在15分钟内设置最小TTL时，这些请求的数量将减少到29％。 至少1小时的TTL将其降低到17％。 很大的不同！
如何不更改服务器端的任何内容，而是在客户端DNS缓存（路由器，本地解析器）中设置最小TTL，该如何做？
设置5分钟内的最小TTL时，要求的请求数量从47％减少到34％，最少15分钟的时间减少到25％，最少1小时的速度增加到13％。 最佳值为40分钟。
这种最小变化的影响是巨大的。
这意味着什么？
当然，可以将服务转移到新的云提供商，新服务器，新网络，要求客户使用最新的DNS记录。 足够小的TTL有助于平稳无缝地进行这种过渡。 但是，随着向新基础架构的过渡，没人希望客户在1分钟，5分钟或15分钟内切换到新的DNS记录。 将最低寿命设置为40分钟而不是5分钟不会阻止用户访问该服务。
但是，这将显着减少等待时间并提高机密性和可靠性，避免不必要的请求。
当然，RFC表示您需要严格执行TTL。 但是现实是DNS系统效率太低。
如果您使用权威DNS服务器，请检查您的TTL。 您真的需要这么低的值吗？
当然，有充分的理由为DNS记录设置较小的TTL。 但是，对于75％的DNS流量而言，这不是一个基本不变。
并且，如果由于某些原因您确实需要为DNS使用低TTL，请同时确保未在您的站点上启用缓存。 出于同样的原因。
如果您具有本地DNS缓存（例如
dnscrypt-proxy） ，该缓存允许您设置最小TTL，请使用此功能。 这很正常。 不会有坏事发生。 在大约40分钟（2400秒）到1小时之间设置最小TTL。 相当合理的范围。