注：本文为 “TTL” 相关文章合辑。
未整理去重。
如有内容异常，请看原文。
TTL 值的意义
2007-10-18 11:33:17
TTL 是 IP 协议包中的一个值，用于标识网络路由器是否应丢弃在网络中停留时间过长的数据包。数据包可能因多种原因在一定时间内无法到达目的地，例如，不正确的路由表可能导致数据包进入无限循环。一种解决方案是在数据包经过一段时间后将其丢弃，并向发送方发送一个报文，由发送方决定是否重发。TTL 的初始值通常为系统默认值，是数据包头部的一个 8 位字段。TTL 最初的设计意图是确定一个时间范围，超过该时间则丢弃数据包。由于每个路由器至少会将 TTL 字段减 1，因此 TTL 通常表示数据包在被丢弃前最多能经过的路由器数量。当计数到 0 时，路由器将丢弃该数据包，并向初始发送方发送一个 ICMP 报文。
在 Windows 95/98 系统中，TTL 的默认值为 32。有建议称，当到达目标节点较为困难时，可将该值设置为 128。ping 和 traceroute 均利用 TTL 值尝试到达指定主机或追踪到该主机的路由。traceroute 通过将数据包的 TTL 值设置得较小，使其在到达目的地的过程中被各个路由器依次丢弃。通过测量发送数据包到接收返回的 ICMP 报文之间的时间，可以计算出从一个路由器到另一个路由器的时间。
在使用多路复用的 IP 协议中，TTL 值表示数据包的转发范围，具体对应关系如下：
| TTL 值 | 数据包的转发范围 |
|---|---|
| 0 | 限制在同一主机 |
| 1 | 限制在同一子网 |
| 32 | 限制在同一节点 |
| 64 | 限制在同一区域（region） |
| 128 | 限制在同一大陆（continent） |
| 255 | 无限制 |
在网络通信中，不同操作系统通常具有不同的默认 TTL 值。基于此，有一种观点认为能够依据返回的 TTL 值来推断目标系统的类型。该观点在一定程度上是成立的，然而，这并非 TTL 的主要功能，仅仅是 TTL 的一种应用场景。需要注意的是，TTL 值可被修改。在一些特殊系统，如 NIDS network intrusion detection systems，入侵检测系统）中，会定义特殊的 TTL 值，以此拒绝非法访问数据的进入。
在执行 PING 命令时，可使用 -i 参数来指定 TTL 值。若将 TTL 设置为 0，数据包将被立即丢弃。在执行 PING 命令后，有时提示信息中会显示另一个地址，并附带类似于 “ TTL 无效 ” 的英文提示。这表明该数据包在抵达目标之前，即在到达返回 IP 位置时，其 TTL 值已降为 0 或小于下一网段允许通过的 TTL 值，因此该数据包被路由丢弃。
关于 ping 以及 TTL 的分析
KinderRiven 于 2015-06-23 18:53:28 发布
首先介绍 ping 这一工具。
ping [目标]
该命令用于向目标发送若干数据包，若目标接收到数据包，目标主机将向发送 ping 请求的主机返回一个数据包。
例如在上图中，对百度服务器进行 ping 操作（Windows 系统默认 ping 4 次）。
其中，“字节”表示数据包的大小，“时间”表示返回时间，而 TTL 的含义如下：
TTL 表示数据包的生存时间，此处显示的是剩余生存时间。TTL 用于计算数据包在路由器中的消耗时间。由于当前大多数路由器的消耗时间小于 1 秒，且小于 1 秒的时间按 1 秒计算，因此数据包每经过一个路由器节点，TTL 值减 1。
TTL 的初始值因操作系统而异：
- Linux 系统的 TTL 值默认为 64 或 255；
- Windows NT/2000/XP 系统的 TTL 值默认为 128；
- Windows 98 系统的 TTL 值默认为 32；
- UNIX 主机的 TTL 值默认为 255。
以百度服务器返回的数据包为例，其 TTL 值应为 64（通常取 2 n 2^n 2n 且最接近返回值的数值）。若返回的 TTL 值为 47，则数据包在传输过程中经过了 64 − 47 = 17 64 - 47 = 17 64−47=17 个路由器。
再例如，对本地 IP 地址进行 ping 操作：
由于本地 IP 地址的通信无需经过路由器，因此 TTL 值保持为 64，即数据包的初始生存时间默认为 64。
提到 ping，就不得不提及 Windows 系统下的另一个工具：tracert。
tracert [目标]
该命令用于获取主机到目标主机所经过的路由器 IP 地址。
如图所示：
tracert 的原理与 ICMP 协议相关，通过数据包的生存时间来获取路径信息。
从图中可以看出，到达目标主机共经过了 15 个路由器（不包括终点）。
需要注意的是，部分路由器可能禁止 ping 操作，因此不会返回任何信息，此时会显示“请求超时”。
此外，由于网络状况复杂多变，对不同地址进行 ping 操作时，路径可能会有所不同。例如，再次对百度进行 tracert 操作：
结果显示路径有所不同，这与不同时间的网络状况以及多种因素有关。
不同操作系统的默认 TTL（生存时间）值
allway2 于 2020-10-17 18:37:07 发布
TTL（生存时间）是网络发送的数据包中包含的一个计时器值，用于指示接收者在丢弃或过期数据（数据包）之前可以保留或使用该数据包的时间。不同操作系统的默认 TTL 值是不同的，因此可以通过 TTL 值来推断操作系统类型。通过 ping 命令可以获取 TTL 值。例如，通过 ping subinsb.com 得到的输出如下：
PING subinsb.com (108.162.199.61) 56 (84) bytes of data.
64 bytes from 108.162.199.61: icmp_seq=1 ttl=57 time=503 ms
64 bytes from 108.162.199.61: icmp_seq=2 ttl=57 time=416 ms
从输出中可以看到，TTL 值为 57。由于该网站托管在 Red Hat 系统上，返回的 TTL 值接近 64（Linux 系统的默认 TTL 值），因此可以推断出远程系统的操作系统。
以下是不同设备 / 操作系统的默认 TTL 值：
| 设备 / 操作系统 | 版本 | 协议 | TTL |
|---|---|---|---|
| AIX | TCP | 60 | |
| AIX | UDP | 30 | |
| AIX | 3.2, 4.1 | ICMP | 255 |
| BSDI | BSD/OS 3.1 and 4.0 | ICMP | 255 |
| Compa | Tru64 v5.0 | ICMP | 64 |
| Cisco | ICMP | 254 | |
| DEC Pathworks | V5 | TCP and UDP | 30 |
| Foundry | ICMP | 64 | |
| FreeBSD | 2.1R | TCP and UDP | 64 |
| FreeBSD | 3.4, 4.0 | ICMP | 255 |
| FreeBSD | 5 | ICMP | 64 |
| HP-UX | 9.0x | TCP and UDP | 30 |
| HP-UX | 10.01 | TCP and UDP | 64 |
| HP-UX | 10.2 | ICMP | 255 |
| HP-UX | 11 | ICMP | 255 |
| HP-UX | 11 | TCP | 64 |
| Irix | 5.3 | TCP and UDP | 60 |
| Irix | 6.x | TCP and UDP | 60 |
| Irix | 6.5.3, 6.5.8 | ICMP | 255 |
| juniper | ICMP | 64 | |
| MPE/IX (HP) | ICMP | 200 | |
| Linux | 2.0.x kernel | ICMP | 64 |
| Linux | 2.2.14 kernel | ICMP | 255 |
| Linux | 2.4 kernel | ICMP | 255 |
| Linux | Red Hat 9 | ICMP and TCP | 64 |
| MacOS/MacTCP | 2.0.x | TCP and UDP | 60 |
| MacOS/MacTCP | X (10.5.6) | ICMP/TCP/UDP | 64 |
| NetBSD | ICMP | 255 | |
| Netgear FVG318 | ICMP and UDP | 64 | |
| OpenBSD | 2.6 & 2.7 | ICMP | 255 |
| OpenVMS | 07.01.2002 | ICMP | 255 |
| OS/2 | TCP/IP 3.0 | 64 | |
| OSF/1 | V3.2A | TCP | 60 |
| OSF/1 | V3.2A | UDP | 30 |
| Solaris | 2.5.1, 2.6, 2.7, 2.8 | ICMP | 255 |
| Solaris | 2.8 | TCP | 64 |
| Stratus | TCP_OS | ICMP | 255 |
| Stratus | TCP_OS (14.2-) | TCP and UDP | 30 |
| Stratus | TCP_OS (14.3+) | TCP and UDP | 64 |
| Stratus | STCP | ICMP/TCP/UDP | 60 |
| SunOS | 4.1.3/4.1.4 | TCP and UDP | 60 |
| SunOS | 5.7 | ICMP and TCP | 255 |
| Ultrix | V4.1/V4.2A | TCP | 60 |
| Ultrix | V4.1/V4.2A | UDP | 30 |
| Ultrix | V4.2 – 4.5 | ICMP | 255 |
| VMS/Multinet | TCP and UDP | 64 | |
| VMS/TCPware | TCP | 60 | |
| VMS/TCPware | UDP | 64 | |
| VMS/Wollongong | 1.1.1.1 | TCP | 128 |
| VMS/Wollongong | 1.1.1.1 | UDP | 30 |
| VMS/UCX | TCP and UDP | 128 | |
| Windows | for Workgroups | TCP and UDP | 32 |
| Windows | 95 | TCP and UDP | 32 |
| Windows | 98 | ICMP | 32 |
| Windows | 98, 98 SE | ICMP | 128 |
| Windows | 98 | TCP | 128 |
| Windows | NT 3.51 | TCP and UDP | 32 |
| Windows | NT 4.0 | TCP and UDP | 128 |
| Windows | NT 4.0 SP5- | 32 | |
| Windows | NT 4.0 SP6+ | 128 | |
| Windows | NT 4 WRKS SP 3, SP 6a | ICMP | 128 |
| Windows | NT 4 Server SP4 | ICMP | 128 |
| Windows | ME | ICMP | 128 |
| Windows | 2000 pro | ICMP/TCP/UDP | 128 |
| Windows | 2000 family | ICMP | 128 |
| Windows | Server 2003 | 128 | |
| Windows | XP | ICMP/TCP/UDP | 128 |
| Windows | Vista | ICMP/TCP/UDP | 128 |
| Windows | 7 | ICMP/TCP/UDP | 128 |
| Windows | Server 2008 | ICMP/TCP/UDP | 128 |
| Windows | 10 | ICMP/TCP/UDP | 128 |
以下是默认 TTL 值的简短版本：
| 设备 / 操作系统 | TTL |
|---|---|
| *nix（Linux / Unix） | 64 |
| Windows | 128 |
| Solaris / AIX | 254 |
可以通过 ping 本地主机来获取 TTL 值：
ping -4 localhost
以下是通过 ping 本地主机得到的输出示例：
正在 Ping x [127.0.0.1] 具有 32 字节的数据：
来自 127.0.0.1 的回复：字节 = 32 时间 < 1ms TTL=128
来自 127.0.0.1 的回复：字节 = 32 时间 < 1ms TTL=128
来自 127.0.0.1 的回复：字节 = 32 时间 < 1ms TTL=128
来自 127.0.0.1 的回复：字节 = 32 时间 < 1ms TTL=128127.0.0.1 的 Ping 统计信息：数据包：已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间 (以毫秒为单位)：最短 = 0ms，最长 = 0ms，平均 = 0ms
查看数据包的 TTL 值并分析传输故障
网络中的网络设备由操作系统进行处理（有些硬件设备将系统预装在硬件芯片中）。在网络遇到传输故障时，可以使用网络检测软件，结合上表的信息对网络中流通的数据包进行检测，查看数据包的 TTL 值，以确定故障是否由错误的路由等原因引起。例如，可以使用科来网络分析系统 5.0 查看一个数据包的 TTL 值。
使用抓包工具查看 TTL 值
Linux 抓包命令如下：
tcpdump -i eth0 -c 5000 -w eth0.cap
假设捕获到的数据包的 TTL 值为 247，结合上表可以确定该数据包从源端（如 61.139.2.69）到目的端（如 192.168.10.44）共经过了 (255 - 247 = 8) 个路由器，且在传输过程中未出现故障。
注意事项
- 确定数据包在网络中经过的路由器数量，可以用数据包源端设备的 TTL 默认值减去捕获到的数据包的 TTL 值。
- 如果不知道数据包源端设备的默认 TTL 值，一般使用大于捕获数据包的 TTL 且最接近该 TTL 的默认值。
- TTL 字段长度为 1 个字节，因此 TTL 的最大值为 255。
通过查看数据包的 TTL 值，可以确定网络传输是否正常。如果捕获到的数据包的 TTL 值过小，则表示网络中可能存在传输故障，应及时检查网络中三层设备的路由表配置以及各主机上的路由表信息。
示例：使用防火墙规则限制 TTL
以下是一些基于 TTL 的防火墙规则示例：
-A INPUT -p udp -m ttl --ttl-eq 98 -j DROP % TTL 等于 98 时禁止
-A INPUT -p udp -m ttl --ttl-lt 45 -j DROP % TTL 小于 45 时禁止
分析数据包
- 使用 Wireshark 查看 cap 文件，找到“time to live: 128”，可以推断攻击的服务器系统可能是 Windows 内网 IP。
- 在没有专用防护设备的条件下，防御方在资源方面处于劣势。通过对攻击发生时的 cap 文件进行分析，找出攻击数据包与正常业务流量的区别，并针对特定数据进行封堵，可以起到一定的防护作用。
如何利用 ping 命令 TTL 来判断操作系统类型
本文已于 2024-02-29 10:24:34 修改。
网络管理人员通常会使用 ping 命令来确认与某个网络是否畅通，但可能并不清楚可以通过 ping 命令返回的 TTL 值来判断操作系统类型。
首先，我们来了解一下 TTL 是什么。TTL（Time To Live，生存时间）是 IP 协议包中的一个值。当我们使用 ping 命令进行网络连通测试或测试网速时，本地计算机会向目的主机发送数据包。然而，有些数据包可能由于某些特殊原因无法正常传送到目的主机。如果没有设置 TTL 值，数据包会在网络中一直传送，从而浪费网络资源。数据包在传送过程中至少会经过一个以上的路由器，每经过一个路由器，TTL 值就会自动减 1。如果减到 0 仍未传送到目的主机，那么该数据包就会自动丢失，此时路由器会向最初的发送者发送一个 ICMP 报文。例如，如果一个主机的 TTL 值为 64，那么当它经过 64 个路由器后仍未将数据包发送到目的主机时，该数据包就会自动丢弃。不同操作系统的默认 TTL 值是不同的，因此可以根据 TTL 值来确定操作系统。
从上述操作系统默认的 TTL 值可以看出，在使用 ping 命令时，返回的 TTL 值会有所不同。这是因为数据包每经过一个路由器，TTL 值就会减 1。因此，我们可以通过判断当前 ping 命令返回的 TTL 值向上接近哪个操作系统的默认 TTL 值，来推断该主机的操作系统类型。
DNS TTL 值理解及配置
By Jamin Zhang
2016 年 04 月 12 日
引言
在域名配置过程中，不同场景和业务需求下，需要调整 DNS TTL 值。这要求我们重新审视 DNS TTL 值的含义。
什么是域名的 TTL 值
TTL（Time-To-Live）是指一条域名解析记录在 DNS 服务器中的存留时间。当 DNS 服务器接收到解析请求时，会向域名指定的 NS 服务器发出请求以获取解析记录。获取记录后，该记录将在 DNS 服务器中保存一段时间。在此期间，若再次接到该域名的解析请求，DNS 服务器将直接返回缓存的记录，而无需再次向 NS 服务器请求。记录在 DNS 服务器上保留的时间即为 TTL 值。
TTL 值设置的应用
1. 增大 TTL 值以节约域名解析时间，提升网站访问速度
通常情况下，域名记录在较长时间内（如数月甚至数年）不会发生变化。因此，可以适当增大域名记录的 TTL 值，延长记录在各地 DNS 服务器中的缓存时间。这样，在较长一段时间内，本地 ISP 的 DNS 服务器无需向域名的 NS 服务器发出解析请求，而是直接从缓存中返回域名解析记录。
当前，国内外许多平台的 TTL 值以秒为单位，常见的默认值为 3600 秒（即 1 小时）。然而，这一默认值相对较小。实际上，域名记录的更改频率极低，因此可以根据实际需求适当增大该值。例如，若希望缓存时间为一天，则可将 TTL 值设置为 86400 秒。
Godaddy 的 TTL 设置较为直观，但仅提供 5 个可选值，即使切换到高级模式，也无法提供更多选项，显得较为僵化。LifeTyper.com 将 TTL 值设置为最大值 1 周。然而，设置过大的 TTL 值可能会带来一些问题，例如在更换服务器空间时，旧记录的过期和更新时间会相对较长。
2. 减小 TTL 值以减少更换空间或域名更改时的不可访问时间
在更换服务器空间时，99.9% 的情况下会涉及 DNS 记录的更改。由于缓存机制的存在，新的域名记录在某些地区可能已经生效，而在其他地区可能需要一两天甚至更长时间才能生效。这可能导致部分用户访问到新服务器，而另一些用户仍访问到旧服务器。如果涉及邮件发送，问题将更加严重，因为重要邮件可能会被发送到已停用的旧服务器上。
为了尽可能减少各地解析时间的差异，建议按照以下步骤操作：
- 查看当前域名的 TTL 值，假设为 1 天。
- 将 TTL 值修改为可设定的最小值，建议为 1 分钟（即 60 秒）。
- 等待 1 天，确保各地 DNS 服务器的缓存过期并更新记录。
- 修改 DNS 记录，此时各地 DNS 服务器能够以最快的速度获取新的记录。
- 在确认各地 DNS 记录更新完成后，将 TTL 值重新设置为所需的值。需要注意的是，TTL 值设置为 60 秒可能过小，不利于长期使用。
上述配置的前提是 DNS 服务器完全遵守相关标准和规范。否则，即使在 NS 服务器上设置了 TTL 值，也可能无法生效。但目前尚未发现完全不遵守规范的 DNS 服务器。
然而，现实中并不存在真正意义上的高速 NS 和 DNS 服务器。例如，Godaddy 在国外评测中得分较高，但在国内的使用体验与万网相差无几；万网在国内的性能表现优异，但在国外评测中得分可能较低。对于大多数网站来说，像 Google 和微软那样在全球范围内部署大量的 CDN 加速服务器和 NS 服务器是不现实的。国内和国外的 DNS 服务难以兼顾，但并非无法实现，只是难度较大。
此外，有人认为可以通过为域名指定两个 NS 记录（一个国内，一个国外）来提高解析速度，但这并不可行。因为只有在 DNS 服务器从第一个 NS 服务器获取记录失败时，才会向第二个 NS 服务器发送解析请求。
目前，最经济有效的提速方法是调整域名记录的 TTL 值。
参考资料
- TTL 值设置：TTL值如何设置_云解析DNS(DNS)-阿里云帮助中心
域名解析 TTL 是什么？TTL 设置多少合适？
2021 年 8 月 23 日
域名解析 TTL 是指生存时间，即 DNS 解析记录在 DNS 服务器上的存留时间。TTL 的设置因应用场景不同而有所差异。以下将详细说明 DNS 域名解析 TTL 的含义以及 TTL 设置时间的建议。
域名解析 TTL
TTL（Time To Live）是指 DNS 解析记录在 DNS 服务器上的存留时间。以下通过示例进行说明：
假设域名 www.mabiji.com 的解析 IP 地址为 7.7.7.7，且将 TTL 设置为 10 分钟。当用户访问该域名时，网络宽带 ISP 服务商的 DNS 服务器会尝试解析该域名。如果在服务商的 DNS 服务器上未找到该域名的解析记录，则会通过全球 DNS 的递归查询获取解析记录，并找到对应的 IP 地址 7.7.7.7，从而完成对该网站的访问请求。
在获取解析记录后，ISP 服务商的 DNS 服务器会将该记录缓存一段时间，这段时间即为 TTL 值。在本例中，TTL 值为 10 分钟，因此该记录将在 DNS 服务器上保存 10 分钟。在 TTL 值有效期间，若有其他用户访问该域名，DNS 服务器将直接返回缓存的 IP 地址，无需再次进行全球 DNS 递归查询，从而节省用户访问网站的时间。
域名 DNS 解析 TTL 值设置建议
TTL 值的设置需要综合考虑多种因素。如果 TTL 值设置过小，解析记录在本地 ISP 服务商的 DNS 服务器上的保存时间较短，导致服务商 DNS 需要频繁进行全球 DNS 递归查询，这将影响网站域名解析的稳定性和速度。反之，如果 TTL 值设置过大，当用户修改域名解析后，生效时间会相对较长。
因此，TTL 值的设置应根据实际应用情况确定。以下是一个参考表格：
| IP 是否经常变动 | 是否动态 IP | 宕机检测 | 服务架构 | 建议 TTL 值 |
|---|---|---|---|---|
| 否 | 否 | 否 | 热备、灾备、固定 IP | 3600 |
| 否 | 否 | 是 | 大型网站 | 60 |
| 否 | 否 | 不使用 | 单服务器 | 600 |
| 否 | 否 | 使用 | 多服务器 | 180 |
| 是 | 否 | 不使用 | 单服务器 | 300 |
| 是 | 是 | 不限 | 不限 | 120 |
对于大多数厂商（如阿里云、腾讯云等），在添加域名解析记录时，默认的 TTL 值为 10 分钟（即 600 秒）。如果没有特殊情况，建议将 TTL 值设置为 10 分钟。
阿里云域名解析的默认 TTL 值为 10 分钟，如下图所示：
腾讯云域名解析的默认 TTL 值为 600 秒，如下图所示：
DNSPod 已并入腾讯云，腾讯云域名解析会跳转到 DNSPod，且腾讯云与 DNSPod 账号互通。
DNS TTL 最佳实践
作者：曾恒
编辑于 2018-07-23 15:50
起源
根据 CDN 团队提供的数据，发现印度地区账号域名的 DNS 解析时间比淘宝慢 174ms。这一现象引发了本文的撰写。
DNS 基础
TTL 在域名设置中是一个重要但常被忽视的值。它主要告知 Resolving Name Server 对 DNS 记录的缓存时间。用户在浏览器中输入 www.mi.com 的域名解析过程如下：
- 用户向 Resolving Name Server 发起 DNS 查询请求。Resolving Name Server 收到请求后，首先检查本地是否有该记录缓存，以及是否存在 www.mi.com 的权威服务器。如果存在，则直接发送给 www.mi.com 的权威服务器；若不存在，则继续查询 mi.com 的权威服务器；若仍不存在，则查询 com 的名称服务器，直至到达根服务器，因为每个名称服务器都知晓根名称服务器的域名和地址。
- Resolving Name Server 向根服务器发起查询（所有根服务器均提供迭代解析）。根服务器返回一个负责处理 .COM 的 gTLD 服务器域名列表。
- Resolving Name Server 接收到根服务器返回的 gTLD 服务器列表后，根据最小 RTT 算法选择一个服务器，继续查找 www.mi.com。
- gTLD 服务器同样提供迭代查询，返回给 Resolving Name Server mi.com 的权威服务器。
- Resolving Name Server 从返回的列表中选择一个服务器，继续查询 www.mi.com 的 A 记录。权威服务器查询后返回 A 记录。（需要注意的是，www.mi.com 实际上是一个 CNAME 记录，此时会重复第一步的查询过程。）
- Resolving Name Server 将 IP 地址返回给浏览器，浏览器随后向指定的 IP 发送特定请求。
整个解析过程虽然看似复杂繁琐，但实际上非常迅速，主要得益于缓存机制的存在。名称服务器将获取到的数据存入缓存，以加快后续查询的速度。下次当解析器向本地名称服务器查询某个已知域名的数据时，解析过程将大幅缩短。BIND 名称服务器还实现了否定缓存（negative caching），如果某个权威名称服务器返回的结果是所查询的域名或数据类型不存在，则本地名称服务器也会将该信息暂时放入缓存中。
例如，假设名称服务器已经查询过 www.mi.com 的地址，在查询过程中，它会将 www.mi.com 以及 mi.com 名称服务器的名称和地址（包括 www.mi.com 的 IP 地址）加入缓存。此时，如果某个解析器向该名称服务器询问 test.app.mi.com 的地址，则该名称服务器将跳过根查询这一步，因为 mi.com 是它所知道的最接近 test.app.mi.com 的祖先，于是便会直接查询 mi.com 的名称服务器。
每次在浏览器中输入域名进行查询时，以下两个问题中任何一个回答为“否”，都会触发向上一层进行查询的操作：
- 我们是否有该记录的缓存？
- 如果有缓存，TTL 是否仍然有效？
TTL 的定义
名称服务器不可能永久保存缓存数据，否则当记录发生变更时，无法及时传达。因此，通过定义一个生存时间（TTL），来限定数据在缓存中的存放时间。一旦生存时间到期，名称服务器将丢弃原有的缓存数据，并从权威名称服务器获取新的数据。例如，小米印度区域的账号域名 TTL 设置为 600 秒，在此期间如果没有相应的访问，名称服务器将丢弃缓存数据，导致频繁请求上层权威，从而在一定程度上增加解析时长。
常见 TTL 设置
TTL 通常以秒为单位，以下是一些常见的 TTL 设置：
- 300 秒 = 5 分钟 = “较短”
- 3600 秒 = 1 小时 = “短”
- 86400 秒 = 24 小时 = “长”
- 604800 秒 = 7 天 = “过长”
DNS 更改后的生效时间
在实际工作中，经常有业务人员询问：“我已经修改了域名，但为什么还没有生效？”以下是可能的原因：
a. 浏览器缓存：浏览器缓存是将文件保存在客户端，在同一个会话过程中会检查缓存的副本是否足够新。在后退网页时，访问过的资源可以从浏览器缓存中直接使用。通过减少服务器处理请求的数量，用户可以获得更快的体验。需要注意的是，浏览器缓存并不遵循 DNS TTL 值，因此此处不作过多讨论。
b. 运营商 Local DNS：运营商的 Local DNS 会通过增加 TTL 来缓存域名，从而实现用户访问流量的网内消化，降低请求频率以及整体流量。部分 Local DNS 甚至会缓存部分域名解析结果所指向的内容，并替换成第三方广告联盟的广告。
c. 复杂内部网络：具有多个 DNS 服务器的复杂内部网络可能会导致 DNS 更改时间比预期更长。
大多数服务声明如下：“注意：修改 DNS 服务器需要 0-72 小时的全球生效时间。如果发现某些地方记录尚未生效，且修改 DNS 的时间未满 72 小时，请耐心等待。”
何时使用较小的 TTL
以下情况适合使用较小的 TTL：
- 知道域名记录会频繁更改。
- 对于一些重要的域名，一旦发生记录不可达，损失较大。此时建议将 TTL 设置得较小，以便及时完成变更。（需要注意的是，部分 Local DNS 会对 TTL 进行默认设置，因此在灾难恢复时，时间可能无法完全掌控。）
- 如果在增加或修改 DNS 记录时，不慎输入错误，最好的操作方法是先将 TTL 修改为较小值，然后对记录进行修改。
- 具体情境具体分析。例如，在小米内部，办公网 DNS 和 IDC DNS 分为两部分。办公网的 DNS 管理员将 IDC 相关域名解析转发到 IDC。之前，IDC 的默认 TTL 设置为 86400 秒，导致 IDC 域名变更后，办公网需要较长时间才能同步新的记录。在经过几次投诉后，将默认 TTL 调整为 600 秒。此后，当 IDC 域名发生修改时，办公网能够在大约 10 分钟内同步到新的记录。
何时使用较大的 TTL
以下情况适合使用较大的 TTL：
- 考虑成本因素。例如，在 dnspod 中，免费托管域名的最小 TTL 为 600 秒。在 dnspod 中，较小的 TTL 意味着更高的套餐价格，即客户需要承担更大的成本。
- 较大的 TTL 可以缩短查询时间。如果每次都向权威服务器发起请求，会增加解析时间。
- 对于 MX 记录、DKIM 和 SPF、TXT 记录等，可以设置较长的 TTL。
- 如果域名指向记录很少发生更改（如 CDN 域名、CNAME、A 记录等），可以将 TTL 设置为 12 小时或一天。
- 当根域或 ISP 级别的 DNS 服务器遭受 DDoS 攻击时，如果攻击发生在 TTL 内，部分用户可能不会受到影响。
需要注意的是，在对这些长 TTL 域名进行更改时，建议同时更改 TTL 值，等待缓存生效后再进行其他更改。
TOP 500 Moz 域名的 TTL 设置
关于 TTL 的设置，是否有数据可以作为参考？Moz Top 500 网站已经将所有网站信息整理到 CSV 文件中。通过 Ruby 脚本遍历列表，可以查找每个域名当前记录的 TTL。虽然这不是一个足够宽泛的样本，但它提供了当前（缓存）结果。基于这一前提，仍有一些可以借鉴的结果。
查看修改代码：
https://gist.github.com/mbuckbee/79b2e76bd9271bea38487defd8a9138b
查看 TOP 500 Moz 域名：
https://moz.com/top500
运行结果：
https://note.youdao.com/ynoteshare/index.html?id=7a095fe319bbc36a3e22f92ad5f23a7d
img
| Lowest TTL | 1 |
|---|---|
| Highest TTL | 127,184 |
| Domains Resolved | 481 |
| Average TTL | 5092.465696 |
| Median TTL | 300 |
最低 TTL 值用于负载均衡，以便更快地更改 DNS 记录；最高 TTL 值则用于那些长时间未更改记录的域名。从结果来看，可以将 300 秒的 TTL 作为一个默认的最佳值。
SOA TTL
在每个 DNS 区域的顶部，有几个 TTL 在 DNS 中发挥重要作用：
- Refresh TTL：从服务器向主服务器刷新的时间。Notify 参数可以设置主服务器在发生更改时主动向从服务器更新。如果关闭 notify，则会采用这个 refresh 时间。
- Retry TTL：refresh 失败后的重试时间。
- Expiry TTL：当 refresh 和 retry 都失败，从服务器无法与主服务器建立连接时，过了 expiry 时间后，从服务器将无法提供权威解析，并删除自己的副本。
通常不建议自行修改这些 TTL 值，除非明确知道自己在做什么。
综上所述，针对最初的问题，最佳 TTL 值可以设置为 86400 秒或更大的值。通过设置更高的 TTL 值，可以发现 DNS 解析时间显著缩短。
参考文章
-
浏览器缓存：
http://www.alloyteam.com/2016/03/discussion-on-web-caching/ -
Definitive Guide to DNS TTL Settings：
https://blog.varonis.com/definitive-guide-to-dns-ttl-settings/ -
全局精确流量调度新思路 - HttpDNS 服务详解：
https://mp.weixin.qq.com/s/u6-53Kp9Jb48dKWzaJOKig -
UNDERSTANDING TTL VALUES IN DNS RECORDS：
https://ns1.com/articles/understanding-ttl-values-in-dns-records -
《DNS 与 BIND》 [美] Cricket Liu & Paul Albitz
via：
-
TTL 值的意义 - tonywam1036-ChinaUnix 博客
http://blog.chinaunix.net/uid-20592805-id-1918638.html -
关于 ping 以及 TTL 的分析_ping 设备显示请求超时和 ttl 过期有什么区别 - CSDN 博客
https://blog.csdn.net/u013451221/article/details/46608881 -
不同操作系统的默认TTL（生存时间）值_不同系统的ttl-CSDN博客
https://blog.csdn.net/allway2/article/details/109136579 -
如何利用ping命令TTL来判断操作系统类型_ttl值判断操作系统-CSDN博客
https://blog.csdn.net/qq_42293468/article/details/136361225 -
DNS TTL 值理解及配置 - Jamin Zhang
https://jaminzhang.github.io/dns/DNS-TTL-Understanding-and-Config/ -
域名解析 TTL 是什么？TTL 设置多少合适？ | 码笔记
https://www.mabiji.com/domain/dnsttl.html -
DNS TTL 最佳实践 - 知乎
https://zhuanlan.zhihu.com/p/40372792
