DNS 的 TTL 值设太短，会不会把解析服务器压垮

TTL 设短以后，DNS 查询量一定会上升，这个判断没问题。但会不会把解析服务器压垮，要看压的是哪一层：用户本地缓存、运营商递归 DNS、公共 DNS，还是你的权威 DNS。

实际使用中发现，很多人讨论 TTL 的时候容易把“用户每访问一次网站就查一次权威 DNS”当成前提，这个前提不太准确。正常链路是：用户设备先问本地 DNS 缓存，没命中再问递归 DNS，递归 DNS 没命中才去问权威 DNS。TTL 主要影响的是缓存多久失效，不是让所有用户请求都直接打到权威 DNS。

TTL 短了以后，查询压力主要从哪里来

比如一个域名 www.example.com 的 A 记录 TTL 设置为 300 秒。某个运营商递归 DNS 第一次查到结果后，会缓存 300 秒。在这 300 秒内，同一个递归 DNS 后面收到再多用户查询，理论上都可以直接从缓存里返回，不再请求权威 DNS。

如果 TTL 改成 30 秒，这个递归 DNS 每 30 秒就可能重新向权威 DNS 查一次。也就是说，对权威 DNS 来说，同一个递归 DNS 的查询频率大概从 5 分钟一次变成 30 秒一次。

这里关键不是终端用户数量，而是“活跃递归 DNS 的数量”。一个大型运营商出口后面可能有几十万用户，但对权威 DNS 来说，可能表现为少量递归 DNS 节点在查询。公共 DNS 比如 8.8.8.8、1.1.1.1、114DNS、阿里 DNS、腾讯 DNS，也都有自己的缓存层。

一个粗略估算

假设一个域名在全国范围内有 2000 个活跃递归 DNS 会来查询它，这个数字已经不算小。TTL 设成 300 秒时，权威 DNS 上这个记录的稳定查询量大概是 2000 / 300 ≈ 6.7 QPS。

TTL 设成 60 秒，变成 2000 / 60 ≈ 33 QPS。

TTL 设成 10 秒，变成 2000 / 10 = 200 QPS。

这个量对正规的权威 DNS 服务商来说不算夸张。DNS 是非常轻量的 UDP 查询，成熟的 Anycast DNS 集群扛几万、几十万 QPS 都很常见。真正容易出问题的，往往是自建在一两台小机器上的 BIND、PowerDNS、CoreDNS，或者权威 DNS 和业务服务器混在一起，没有限速、没有 Anycast、没有 DDoS 防护。

TTL 设置为 1 秒会发生什么

TTL 设成 1 秒，理论上缓存 1 秒就过期，看起来很灵活，切 IP 几乎马上生效。但实际网络里不一定完全按 1 秒执行。

不少递归 DNS 会设置最小 TTL，比如低于 30 秒的记录按 30 秒处理，低于 60 秒的按 60 秒处理。浏览器、操作系统、应用 SDK 也可能有自己的缓存策略。Java 进程里 DNS 缓存时间还可能受 JVM 参数影响，移动 App 也常见自建 HTTPDNS 缓存。

所以 TTL 设 1 秒，并不等于所有用户 1 秒内切完。它更像是在告诉上游“希望尽快过期”，但中间每一层是否照做，不完全由权威 DNS 控制。

多说一句，TTL 过短还会带来另一个问题：递归 DNS 缓存命中率下降，用户侧 DNS 延迟变高。一次 DNS 查询多几十毫秒不一定明显，但移动网络、跨境访问、弱网环境下，这个抖动会被放大。特别是游戏登录、支付回调、API 网关这类请求，DNS 抖动有时会被误判成服务器延迟。

权威 DNS 会不会被打爆，看这几个场景

普通企业站、官网、后台系统

这类业务一般不用把 TTL 压得很低。A 记录、CNAME 记录设置 300 秒到 600 秒比较常见。平时缓存命中率高，切换 IP 也能在几分钟级别完成。

如果只是偶尔迁移服务器，提前一天把 TTL 从 600 秒降到 60 秒，迁移完成后再调回去，这种操作比较稳。不要长期把所有记录都设成 1 秒、5 秒，收益不大，反而让 DNS 链路更敏感。

游戏业务、实时调度、故障切换

游戏入口、API 调度、跨区访问这类场景，TTL 会设得更短，常见是 30 秒、60 秒。原因不是为了炫技，而是节点故障时要尽快把用户导到其他 IP。

实际使用中发现，30 秒 TTL 已经能覆盖不少故障切换需求。再往下压到 10 秒甚至 1 秒，收益开始变小，因为递归 DNS、客户端缓存、连接复用、业务重试机制都会影响最终切换速度。DNS 不是实时流量调度系统，它适合做分钟级或几十秒级的入口切换。

如果业务本身对海外访问、低延迟、高防有要求，DNS TTL 只是入口策略的一部分，后面的线路质量也要跟上。比如香港方向可以关注 CN2 精品线路，面向美国用户或跨境业务可以看大带宽和基础防御配置。如果你也在找这种游戏、企业、高防、海外云服务器，可以看看129云，他们有香港精品 CN2、美国精品大宽带、高防服务器等产品线，客服热线 400-9177118，适合把 DNS 调度和服务器线路一起评估。

高并发活动页、短链接、下载分发

这类业务要小心。不是说 TTL 短一定扛不住，而是活动开始时递归 DNS 缓存大量失效，权威 DNS 查询会出现尖峰。尤其是短信、Push、直播间同时导流，用户来源集中，DNS 查询会跟 HTTP 请求一起抬升。

比如一个活动页有 500 万用户在 10 分钟内涌入，TTL 设置 30 秒。权威 DNS 不会收到 500 万用户每 30 秒一次查询，但会收到大量递归 DNS 的刷新请求。如果域名还挂了多个 CNAME，每层 CNAME 都有自己的 TTL 和解析链路，查询次数会继续放大。

这里补充一点，CNAME 链路太长比 TTL 短更容易制造奇怪问题。www.example.com CNAME 到 cdn.example.net，cdn.example.net 再 CNAME 到 vendor.example.org，看起来管理方便，但每一跳都可能增加解析延迟和故障面。TTL 再短，也救不了一条复杂到不可控的解析链。

短 TTL 真正容易压垮的是自建 DNS

用云 DNS、专业 DNS 服务商，TTL 60 秒一般不是问题。它们背后通常是 Anycast 节点，分布式权威集群，带有缓存、限速、DDoS 防护和监控。

但如果是自建权威 DNS，就要认真算容量。很多人把 NSD、BIND、PowerDNS 部署在两台普通 VPS 上，配置成 ns1、ns2，觉得有主备就稳了。平时访问量不大没事，一旦 TTL 设很短，再遇到爬虫、活动流量、DDoS 放大探测，DNS 先挂，业务服务器还没开始处理请求，用户已经解析失败。

自建 DNS 还要考虑网络质量。权威 DNS 响应包很小，但它非常怕丢包和抖动。跨境解析尤其明显，用户递归 DNS 到权威 DNS 的路径绕路，UDP 包丢了，递归 DNS 重试，再不行切 TCP，整个解析耗时就上去了。

TTL 短不短，要分记录类型看

A / AAAA 记录

A 和 AAAA 是最常被调 TTL 的记录。业务 IP 可能迁移，节点可能故障，TTL 设成 60 秒、120 秒、300 秒都常见。

如果后面接的是 SLB、CDN、Anycast IP，源站 IP 不直接暴露，TTL 可以稍长一点。因为故障切换通常发生在 SLB 或 CDN 内部，不需要每次都靠 DNS 改记录。

CNAME 记录

CNAME 的 TTL 要看上游服务商怎么处理。有些 CDN 会建议你设置 300 秒，有些调度型服务会要求 60 秒。这里不要只盯着自己域名的 TTL，还要 dig 一下最终解析结果。

常用命令是 dig www.example.com +trace，或者 dig www.example.com @8.8.8.8，观察每一跳剩余 TTL。实际排障时，经常能看到控制台显示 TTL 是 60 秒，但递归 DNS 返回结果里还有几百秒，原因可能是上游 CNAME、递归缓存、或者记录刚改没多久。

MX、TXT、SPF、DKIM

邮件相关记录不建议频繁改，也不建议 TTL 太短。MX、SPF、DKIM 通常可以设 1800 秒、3600 秒甚至更长。邮件系统更看重稳定，临时切换也不是靠秒级 DNS 完成。

TXT 记录如果用于域名验证，TTL 设短一点方便验证通过后调整，但稳定运行后可以拉长。

NS 记录

NS 记录更要谨慎。很多人改权威 DNS 服务商时，只改控制台，不看注册局侧 NS，也不看父区缓存。NS 记录 TTL 通常比较长，迁移时要提前规划。短 TTL 对普通 A 记录有帮助，但对权威 DNS 迁移这种操作，不是万能按钮。

TTL 设置太短时，常见现象不是“服务器 CPU 爆了”

真正遇到 TTL 过短带来的问题，表现通常不是权威 DNS CPU 直接 100%。更多是下面这些现象：

解析延迟升高。递归 DNS 缓存命中率下降，请求更频繁地走完整解析链路，用户侧首包时间变长。

解析结果不一致。不同递归 DNS 对最小 TTL 的处理不同，有的 30 秒刷新，有的 60 秒刷新，有的缓存更久，故障切换时用户分布会比较散。

监控误报变多。DNS 探测点看到的 TTL、IP 切换时间不一致，业务监控会出现一段时间的灰色状态。

自建权威 DNS UDP 丢包。不是 QPS 绝对值很高，而是网络质量、conntrack、iptables、系统参数没调好，导致 UDP 响应不稳定。

DDoS 风险放大。DNS 天然容易成为攻击目标，TTL 短导致正常查询基线抬高，攻击流量混进来时更难区分。

实际配置时可以参考的 TTL 范围

官网、企业站、后台入口：300 秒到 600 秒，够用，也比较稳。

CDN CNAME：按 CDN 厂商建议来，常见 60 秒到 300 秒，不要自己随便压到 1 秒。

游戏登录、API 网关、跨区调度：30 秒到 120 秒比较常见。需要更快切换时，要配合健康检查、SLB、Anycast、客户端重试，不要只靠 DNS。

迁移窗口：迁移前把 TTL 降到 60 秒，等旧 TTL 周期过去后再切记录。切完稳定一段时间，再调回 300 秒或 600 秒。

邮件记录：1800 秒到 3600 秒更常见，没必要短。

NS 记录：提前规划，不建议临时乱改。迁移权威 DNS 时，要同时看注册局、父区、原 DNS 服务商配置。

一个容易被忽略的细节：TTL 变短不是立刻生效

假设当前 www.example.com 的 TTL 是 3600 秒，你现在把它改成 60 秒。已经缓存了旧记录的递归 DNS，不会马上知道 TTL 变短了。它要等旧的 3600 秒缓存过期后，下一次重新查询才会拿到新的 60 秒 TTL。

所以迁移前临时降 TTL，要提前做。比如晚上 12 点切 IP，下午就把 TTL 从 3600 秒降到 60 秒。等旧缓存自然过期后，再执行切换。很多“DNS 改了不生效”的故障，其实是没有提前降 TTL。

权威 DNS 容量要看 QPS，也要看解析链路

如果使用的是专业 DNS 服务，关注服务商给的 SLA、Anycast 覆盖、DDoS 防护、监控能力、最小 TTL 限制即可。一般业务把 TTL 设到 60 秒，不会因为这个动作把对方解析集群压垮。

如果自建权威 DNS，建议至少看这些指标：UDP 53 QPS、TCP 53 连接数、响应延迟、SERVFAIL 比例、NXDOMAIN 比例、递归来源分布、单 IP 查询频率、丢包率。只看 CPU 和内存不够，DNS 很多问题是网络层和系统参数先暴露。

这里再补充一点，权威 DNS 不要和核心业务服务混在同一台机器上。业务服务被打满时 DNS 也跟着慢，DNS 慢了用户又进不来，排障时会绕成一团。需要海外节点或高防节点承载业务时，服务器线路也要单独评估，比如香港精品 CN2-A 型适合对国内访问延迟敏感的小型业务，美国精品大宽带-C 型适合需要 1Gbps 峰值和基础防御的海外业务，选型时可以顺手看下129云的对应配置。

TTL 设短的合理用法

短 TTL 适合用在“可能需要快速切换”的记录上，而不是把整个域名所有记录全部设短。www、api、login、gateway 这类入口记录可以短一点；mail、验证 TXT、NS、静态配置类记录可以长一点。

如果业务依赖 DNS 做容灾，建议提前演练。把主 IP 下线，看递归 DNS 多久刷新，看客户端多久重连，看老连接是否还打到旧 IP。只在 DNS 控制台看记录已经变更，没有太大意义，用户真实链路才算数。

dig 可以看递归 DNS 返回的 TTL，tcpdump 可以看本机是否真的发起 DNS 查询，权威 DNS 日志可以看哪些递归 DNS 在刷新。排障时这三个视角要分开，不然很容易把客户端缓存、递归缓存、权威记录混在一起。

什么情况下 TTL 太短真的会出事

域名访问量很大，同时使用自建权威 DNS，而且没有 Anycast，没有 DDoS 防护，TTL 又设到 1 秒、5 秒，这种组合风险很高。

大量子域名动态生成也要小心。比如 user1.example.com、user2.example.com 这种按用户生成子域名，递归 DNS 很难复用缓存，权威 DNS 查询量会接近真实请求规模。TTL 再长也救不了太多，因为每个名字都是新的。

还有一种是大量 NXDOMAIN。攻击者随机请求不存在的子域名，比如 aaaa.example.com、bbbb.example.com，权威 DNS 要不断回答不存在。如果 negative TTL 配得很短，递归 DNS 对不存在结果也缓存不住，查询会持续打上来。这个场景下要关注 SOA 里的 negative caching TTL，以及 DNS 服务商的抗攻击能力。

所以看到 TTL 短，不要马上判断会压垮；看到 DNS 扛得住，也不要把 TTL 当成随便调的旋钮。对访问量稳定、权威 DNS 专业托管的域名，60 秒 TTL 很常见。对自建 DNS、大量动态子域名、活动尖峰、跨境访问混在一起的业务，TTL 每缩短一档，都要重新看查询量、链路延迟和故障切换表现。