TTL值对解析生效速度有什么影响？怎么设置最合理！

　　你在DNS控制台把某个域名的A记录从旧IP改到了新IP，然后等着生效。结果过了十分钟，有些用户已经访问到了新服务器，有些用户还在访问旧的——打开的还是老版本的网站。这就是TTL值在背后起的作用。

　　TTL全称Time To Live，中文叫“生存时间”。它是DNS记录里的一个基础字段，单位是秒。它决定了这条DNS记录在被递归DNS服务器缓存之后，能存活多长时间。TTL值到期之后，递归DNS会丢弃这条缓存记录，下次有人查询的时候再去权威服务器取最新的值。

　　这个机制本身是为了减轻权威服务器的压力、提高DNS查询效率而设计的。但如果你想更改解析记录，TTL值就会直接影响生效速度。简单说：TTL越短，生效越快;TTL越长，DNS查询越快。

　　TTL的工作原理

　　要理解TTL对生效速度的影响，先得搞清楚一条DNS记录从权威服务器到用户浏览器之间经历了什么。

　　你有一个网站，托管在某个服务器上。你在权威DNS服务商那里添加了一条A记录：www.example.com 指向 192.0.2.1。

　　假设你在国内的某个用户，用的是114.114.114.114这个公共DNS。他第一次访问 www.example.com 的时候，114的递归DNS会从你的权威服务器上拉取这条A记录，然后返回给用户，同时把这条记录存在本地缓存里，TTL就是这个缓存的存活时间。

　　如果你的TTL设置成600秒，那么在接下来的10分钟内，第二个、第三个用户再来访问同一个域名，114的递归DNS不会再去你的权威服务器查询，而是直接从缓存里把 192.0.2.1 丢给用户。10分钟以后，缓存过期，下一次查询才会重新去你的权威服务器拉取最新记录。

　　生效速度影响的本质就在这里：你改了解析记录，但那些递归DNS不会立刻去拿新记录，它们会等到各自的缓存过期之后才去更新。全球有成千上万个递归DNS节点，它们缓存过期的时间点各不相同，所以在TTL过期之前，有的用户拿到新IP，有的还是旧IP，这就是“解析生效中”的过渡状态。

　　TTL的数值区间和常见场景

　　60秒-300秒(极短TTL)

　　这个区间通常用于需要频繁切换的场景。

　　优点：解析生效极快。改完记录之后，几分钟内全球大多数递归DNS缓存就会过期并拉取新记录。

　　缺点：递归DNS查询频率大幅增加，权威服务器的负载会明显上升。每次查询都要回源，DNS响应时间也会略慢。

　　适用场景：故障切换演练、灰度发布、CDN动态调度、或者你计划近期内更换服务器IP的场景。

　　600秒-3600秒(短TTL)

　　这是目前大多数网站的默认配置区间，10分钟到1小时。

　　优点：在生效速度和缓存效率之间取得了一个相对平衡的状态。改解析后，大部分用户在一小时内能完成切换。平时访问时，缓存命中率较高，不会频繁回源。

　　缺点：如果遇到紧急故障需要切换IP，一个小时还是偏长了。

　　适用场景：普通的企业官网、博客、电商站前台。这个区间的设置足以覆盖绝大多数生产环境的日常使用。

　　86400秒或更长(长TTL)

　　一天甚至一周的TTL，属于老派运维风格。

　　优点：缓存命中率极高，DNS查询几乎不回源，权威服务器负载极轻，DNS响应几乎无延迟。

　　缺点：改一次解析要等24小时甚至更久才能完全生效。如果服务器IP变了，你只能干等，没有任何办法加速。

　　适用场景：极不推荐用在网站主域名上。如果你有一些几乎不变的公共服务，比如内部的邮件服务器地址，或者某个静态资源的CDN域名，可以考虑长TTL。

　　TTL太短有什么代价?

　　很多人为了追求“改解析秒生效”，把TTL设成30秒甚至更短。表面上看很灵活，但代价是实实在在的。

　　权威服务器的查询压力会显著增加。 你设置的TTL是30秒，意味着每个递归DNS每隔30秒就要来你的权威服务器查询一次。如果全世界的用户分散在几百个递归DNS后面，你的权威服务器每秒要处理的查询请求数量就会暴涨。如果你的权威DNS是按查询量计费的(比如AWS Route 53)，那账单会看得你肉疼。

　　DNS解析时间略微变长。 缓存命中的时候，解析时间接近0毫秒(递归DNS直接返回内存里的结果)。TTL短的时候，缓存频繁失效，用户每次都要走一次完整的递归查询链路，解析耗时从几毫秒变成几十甚至上百毫秒。虽然这点延迟对单个用户来说感知不强，但如果PV很高，累计的影响还是存在的。

　　极端情况下可能被当作DDoS攻击。 有些DNS服务商对单个域名的QPS有限制，你把TTL设到极低导致权威服务器查询量暴增，有可能触发限流策略，导致部分地区的用户解析失败。

　　改解析之前，先调TTL

　　这是运维里一个非常实用的小技巧：在计划更换服务器IP之前，提前一两天把TTL调低。

　　假设你的业务网站平时TTL是3600秒(1小时)，现在服务器性能跟不上，准备迁移到一台新机器上，IP要从A换成B。

　　如果你直接改解析，那么在未来一个小时之内，有一部分用户还是旧的A，有一部分已经拿到了新的B，会造成业务不连续，甚至数据不一致的问题。

　　正确的操作是分两步走：

　　第一步：提前48小时，把TTL从3600改到300秒。这个操作本身是立竿见影的，改完之后全球递归DNS会逐渐以更短的周期来更新缓存。

　　第二步：等上至少一个原TTL的时长(即48小时之后)，确认所有递归DNS都已经按照新的300秒TTL在缓存了，这时候再正式把A记录改到新IP。由于TTL已经降到了300秒，改完之后最多5-10分钟，全球大部分用户就能拿到新IP。

　　第三步：确认业务在新IP上稳定运行24小时后，再把TTL调回3600秒，恢复正常状态。

　　这个流程的核心逻辑是：生效速度取决于当前TTL的数值，而不是你修改记录时的突发操作。 你改了TTL本身也是一个解析变更，也会有生效延迟。所以提前把TTL降下来，让全球DNS节点都“准备好”以更快的节奏去刷新缓存，到时候改IP地址就能实现快速的平滑切换。

　　不同记录类型的TTL设置建议

　　不同类型的DNS记录，对时效性的要求差异很大，一刀切并不合适。

　　A/AAAA记录(核心业务域名)：建议600-1800秒。既能保证日常缓存效率，又在需要切换时能有相对较快的生效速度。除非你的业务对故障切换速度有极高的要求(比如交易系统)，否则不需要设到300秒以下。

　　CNAME记录(别名记录)：CNAME指向的目标域名本身也会有解析延迟，叠加起来会延长整体生效时间。建议CNAME的TTL不低于600秒，避免频繁查询对上游域名造成压力。

　　MX记录(邮件交换记录)：邮件系统对稳定性要求极高。如果TTL太短，邮件服务器可能频繁查询DNS导致邮件队列积压。建议MX记录的TTL设在3600秒以上，甚至4小时也不过分。除非你明确知道邮件服务器近期要迁移IP，否则不要动MX的TTL。

　　TXT记录(验证、SPF、DKIM)：这类记录通常用于域名所有权验证或者邮件反垃圾配置。验证服务商一般只会在添加时查询一次，不太依赖TTL。设成3600秒甚至更长都没问题。

　　NS记录(权威服务器记录)：NS记录的TTL不建议低于86400秒。因为NS记录变更涉及到域名的整体解析权转移，如果TTL太短，容易导致解析不稳定，甚至出现NXDOMAIN错误。

　　几个常见的误区

　　“TTL越短，网站访问越快”：错。TTL决定的是DNS解析的快慢，不是网站加载的快慢。DNS解析在整个页面加载过程中只占很小一部分。TTL长了缓存命中率高，DNS解析更快;TTL短了反而因为要频繁回源，单次解析可能更慢。

　　“改完解析后手动刷新就能立即生效”：不能。你在浏览器里按F5刷新的是页面，不是DNS缓存。递归DNS的缓存不归你管，也不受你本地操作影响。要强制刷新本地DNS缓存可以用 ipconfig /flushdns(Windows)，但这对用户毫无意义，你不可能控制你网站所有访问者的电脑。

　　“TTL设成0可以实时生效”：理论上RFC允许TTL=0，表示缓存时间0秒，每次查询都回源。但实际使用中，很多递归DNS服务器会忽略0值，强制按照自己的最低TTL限制来处理。而且TTL=0会导致权威服务器负载急剧上升，极其不推荐。

　　最后总结一句核心原则：TTL的合理值，取决于你对解析变更频率的预期。 如果你经常需要换IP，就把TTL放短;如果你几年都不会动一次解析，TTL设长一点也没关系。没有绝对正确的数值，只有适不适合你的业务节奏。