主持人 > 博客 > 管理 > 停止对 DNS 使用低得离谱的 TTL

停止对 DNS 使用低得离谱的 TTL

低 DNS 延迟是快速互联网浏览的关键。 为了最大限度地减少这种情况，仔细选择 DNS 服务器和 匿名中继。 但第一步是摆脱无用的查询。

这就是 DNS 最初被设计为高度可缓存协议的原因。 区域管理员为各个条目设置生存时间 (TTL)，解析器在将条目存储在内存中时使用此信息以避免不必要的流量。

缓存有效吗？ 几年前，我的小研究表明它并不完美。 我们来看看目前的情况。

收集我修补的信息 加密的 DNS 服务器 保存响应的 TTL 值。 它被定义为每个传入请求的记录的最小 TTL。 这很好地概述了真实流量的 TTL 分布，并且还考虑了各个请求的受欢迎程度。 服务器的修补版本运行了几个小时。

生成的数据集包含 1 条记录（名称、qtype、TTL、时间戳）。 以下是总体 TTL 分布（X 轴是以秒为单位的 TTL）：

停止对 DNS 使用低得离谱的 TTL

除了 86 的小幅波动（主要针对 SOA 记录）之外，很明显 TTL 处于较低范围内。 让我们仔细看看：

停止对 DNS 使用低得离谱的 TTL

好的，大于 1 小时的 TTL 没有统计意义。 然后我们关注 0−3600 的范围：

停止对 DNS 使用低得离谱的 TTL

大多数 TTL 为 0 到 15 分钟：

停止对 DNS 使用低得离谱的 TTL

绝大多数是 0 到 5 分钟：

停止对 DNS 使用低得离谱的 TTL

这不太好。

累积分布使问题更加明显：

停止对 DNS 使用低得离谱的 TTL

一半的 DNS 响应的 TTL 为 1 分钟或更短，四分之三的 TTL 为 5 分钟或更短。

但等等，实际上情况更糟。 毕竟，这是来自权威服务器的 TTL。 然而，客户端解析器（例如路由器、本地缓存）从上游解析器接收 TTL，并且每秒都会减少。

因此，在发送新请求之前，客户端实际上可以平均使用每个条目的原始 TTL 的一半。

也许这些非常低的 TTL 只适用于不寻常的请求，而不适用于流行的网站和 API？ 我们来看一下：

停止对 DNS 使用低得离谱的 TTL

X轴是TTL，Y轴是查询流行度。

不幸的是，最流行的查询也是最难缓存的。

让我们放大一下：

停止对 DNS 使用低得离谱的 TTL

结论：这真的很糟糕。 以前已经很糟糕了，但现在更糟糕了。 DNS 缓存实际上已经变得毫无用处。 随着使用 ISP 的 DNS 解析器的人越来越少（有充分的理由），延迟的增加变得更加明显。

DNS 缓存仅对无人访问的内容有用。

另请注意，该软件可能 以不同的方式 解释低 TTL。

这是为什么？

为什么 DNS 记录设置为如此低的 TTL？

  • 旧版负载均衡器保留默认设置。
  • 有传言称 DNS 负载平衡取决于 TTL（事实并非如此 - 自 Netscape Navigator 时代以来，客户端从一组 RR 中选择一个随机 IP 地址，如果无法连接，则透明地尝试另一个 IP 地址）
  • 管理员希望立即应用更改，以便更轻松地进行规划。
  • DNS 服务器或负载平衡器的管理员将其任务视为有效部署用户请求的配置，而不是加快站点和服务的速度。
  • 低 TTL 让您高枕无忧。
  • 人们最初为测试设置了较低的 TTL，然后忘记更改它们。

我没有将“故障转移”包含在列表中，因为它变得越来越不相关。 如果您需要将用户重定向到另一个网络只是为了在其他所有内容都损坏时显示错误页面，那么超过 1 分钟的延迟可能是可以接受的。

此外，一分钟的 TTL 意味着如果权威 DNS 服务器被阻止超过 1 分钟，则其他人将无法访问相关服务。 如果原因是配置错误或黑客攻击，冗余也无济于事。 另一方面，如果 TTL 合理，许多客户端将继续使用以前的配置，而不会注意到任何事情。

CDN 服务和负载均衡器在很大程度上要归咎于低 TTL，尤其是当它们将具有低 TTL 的 CNAME 和具有同样低（但独立）TTL 的记录结合起来时：

$ drill raw.githubusercontent.com
raw.githubusercontent.com.	9	IN	CNAME	github.map.fastly.net.
github.map.fastly.net.	20	IN	A	151.101.128.133
github.map.fastly.net.	20	IN	A	151.101.192.133
github.map.fastly.net.	20	IN	A	151.101.0.133
github.map.fastly.net.	20	IN	A	151.101.64.133

每当 CNAME 或任何 A 记录过期时，都必须发送新的请求。 两者都有 30 秒 TTL，但并不相同。 实际平均 TTL 将为 15 秒。

可是等等！ 情况更糟。 在这种情况下，一些解析器的行为非常糟糕，有两个相关的低 TTL：

$ 钻 raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com。 1 在 CNAME github.map.fastly.net 中。 github.map.fastly.net。 1 合 151.101.16.133

Level3 解析器可能在 BIND 上运行。 如果继续发送该请求，则始终会返回 TTL 1。本质上， raw.githubusercontent.com 永远不会被缓存。

这是一个非常受欢迎的域的这种情况的另一个例子：

$ drill detectportal.firefox.com @1.1.1.1
detectportal.firefox.com.	25	IN	CNAME	detectportal.prod.mozaws.net.
detectportal.prod.mozaws.net.	26	IN	CNAME	detectportal.firefox.com-v2.edgesuite.net.
detectportal.firefox.com-v2.edgesuite.net.	10668	IN	CNAME	a1089.dscd.akamai.net.
a1089.dscd.akamai.net.	10	IN	A	104.123.50.106
a1089.dscd.akamai.net.	10	IN	A	104.123.50.88

至少三个 CNAME 记录。 哎呀。 一个有不错的 TTL，但完全没用。 其他 CNAME 的初始 TTL 为 60 秒，但对于域 akamai.net 最大 TTL 为 20 秒，并且它们都不同相。

不断轮询 Apple 设备的域怎么样？

$ drill 1-courier.push.apple.com @4.2.2.2
1-courier.push.apple.com.	1253	IN	CNAME	1.courier-push-apple.com.akadns.net.
1.courier-push-apple.com.akadns.net.	1	IN	CNAME	gb-courier-4.push-apple.com.akadns.net.
gb-courier-4.push-apple.com.akadns.net.	1	IN	A	17.57.146.84
gb-courier-4.push-apple.com.akadns.net.	1	IN	A	17.57.146.85

与 Firefox 相同的问题，使用 Level1 解析器时，TTL 大部分时间会卡在 3 秒。

保管箱？

$ 钻 client.dropbox.com @8.8.8.8 client.dropbox.com。 7 在 CNAME client.dropbox-dns.com 中。 client.dropbox-dns.com。 59 在 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

录音时 safebrowsing.googleapis.com TTL 值为 60 秒，如 Facebook 域。 而且，从客户的角度来看，这些值又减半了。

设置最小 TTL 怎么样？

使用名称、请求类型、TTL 和最初存储的时间戳，我编写了一个脚本来模拟通过缓存解析器的 1,5 万个请求，以估计由于缓存条目过期而发送的不必要请求的数量。

47,4% 的请求是在现有记录过期后提出的。 这是不合理的高。

如果设置最小TTL会对缓存产生什么影响？

停止对 DNS 使用低得离谱的 TTL

X 轴是最小 TTL 值。 源 TTL 高于此值的记录不受影响。

Y 轴是来自已拥有缓存条目但已过期并正在发出新请求的客户端的请求的百分比。

只需将最小 TTL 设置为 47 分钟，“额外”请求的比例就从 36% 减少到 5%。 通过将最小 TTL 设置为 15 分钟，这些请求的数量会下降到 29%。 最小 TTL 为 1 小时会将其减少至 17%。 显着差异！

如何不更改服务器端的任何内容，而是在客户端 DNS 缓存（路由器、本地解析器）中设置最小 TTL？

停止对 DNS 使用低得离谱的 TTL

所需请求数从 47% 下降到 TTL 至少为 34 分钟的 5%、至少 25 分钟的请求数量下降到 15%、至少 13 小时的请求数量下降到 1%。 也许 40 分钟是最佳时间。

这个小小的变化的影响是巨大的。

有什么后果？

当然，服务可以转移到新的云提供商、新的服务器、新的网络，要求客户端使用最新的DNS记录。 相当小的 TTL 有助于平稳且不易察觉地进行这种转换。 但随着向新基础设施的过渡，没有人期望客户端能够在 1 分钟、5 分钟或 15 分钟内迁移到新的 DNS 记录。 将最小 TTL 设置为 40 分钟而不是 5 分钟不会阻止用户访问该服务。

然而，这将通过避免不必要的请求来显着减少延迟并提高隐私性和可靠性。

当然，RFC 规定必须严格遵守 TTL。 但现实是DNS系统已经变得太低效了。

如果您使用权威 DNS 服务器，请检查您的 TTL。 你真的需要这么低的值吗？

当然，为 DNS 记录设置较小的 TTL 有充分的理由。 但 75% 的 DNS 流量几乎保持不变，情况并非如此。

如果由于某种原因您确实需要对 DNS 使用低 TTL，请同时确保您的站点未启用缓存。 出于同样的原因。

如果您正在运行本地 DNS 缓存，例如 dnscrypt 代理它允许您设置最小 TTL，请使用此功能。 这可以。 不会有什么不好的事情发生。 将最小 TTL 设置为大约 40 分钟（2400 秒）1 小时。 相当合理的范围。

来源： habr.com