DNS TTL 调低之后，高并发访问会不会把服务器查询请求打爆

这个问题实际在线上经常遇到，尤其是做灰度切流、故障切换、跨区域调度的时候，很多人第一反应是：TTL 从 600 秒改成 30 秒，甚至 10 秒，用户量一大，DNS 查询是不是会猛增，然后把服务器打爆？

这里要先把“服务器”这个词拆开。用户访问业务时，DNS 查询请求通常不会打到你的 Web 服务器、游戏服务器、API 服务器上。DNS 查询打到的是 DNS 体系里的 Recursive Resolver 和 Authoritative DNS。也就是说，除非你自己搭了 Authoritative DNS，并且把域名 NS 指过去，否则 TTL 再低，也不是直接把业务机器打爆。

真正可能被打爆的是权威 DNS 服务、递归 DNS 缓存层，或者你自己部署的 DNS 服务进程，比如 BIND、PowerDNS、CoreDNS。业务服务器承受的是后面的 HTTP、TCP、UDP、WebSocket、游戏协议流量，不是 DNS 查询本身。

低 TTL 影响的是缓存命中，不是每个用户都直接查源

TTL 的作用很简单：告诉 DNS 缓存，这条记录可以缓存多久。TTL 600 秒，递归 DNS 拿到 A 记录后，可以缓存 10 分钟；TTL 30 秒，就只能缓存 30 秒。

但很多人容易误判一个地方：不是每个用户、每次打开页面都会直接向权威 DNS 查一次。用户设备一般会查运营商 DNS、公共 DNS 或企业内网 DNS，这些 Recursive Resolver 会缓存结果。一个小区、一个公司、一个运营商出口下面可能很多用户共用同一组递归 DNS。TTL 变短后，递归 DNS 回源频率变高，但不会变成“每个用户一次”。

举个接近真实的场景：一个站点同时在线 10 万用户，域名 TTL 设为 30 秒。假设这些用户分布在全国不同运营商和公共 DNS 上，真正向权威 DNS 发起查询的可能是几百到几千个递归出口，而不是 10 万个终端。每个递归出口在 TTL 过期后查一次，然后继续缓存给后面的用户用。

当然，这不是说低 TTL 没成本。TTL 越低，Authoritative DNS 的 QPS 越高，递归 DNS 的缓存效果越差。只是它和业务并发不是一比一关系。

用数据感受一下 TTL 对 DNS QPS 的影响

实际估算时，不要拿“用户数”直接除 TTL，更接近的方法是看活跃递归 DNS 数量。比如一个域名的主要访问来自 2000 个 Recursive Resolver 出口，TTL 设为 300 秒，理论上权威 DNS 这边稳定查询大约是 2000 / 300 ≈ 6.7 QPS。TTL 改成 30 秒，变成 2000 / 30 ≈ 66.7 QPS。

这个量级对专业 DNS 服务商来说很小。主流云 DNS、Anycast DNS 扛几万、几十万 QPS 都不是稀奇事。但如果是自己拿一台小机器跑 BIND，没做 Anycast，没做防护，没做限速和监控，那几十到几百 QPS 也许不是问题，突发、攻击、递归放大、异常客户端叠加起来就不好说了。

实际使用中发现，低 TTL 的风险通常不是“正常用户太多”，而是这些情况叠在一起：域名被爬虫频繁解析、客户端 SDK 写得差疯狂重试、DNS 记录频繁变更导致缓存失效、遭遇 DNS Query Flood，或者权威 DNS 节点离用户太远导致解析慢。

不同 TTL 下的直观差异

TTL 600 秒：适合稳定业务，比如官网、后台、下载域名。切换慢一点，但缓存命中高，DNS 压力低。

TTL 300 秒：线上比较常见，兼顾变更速度和缓存效果。很多生产环境默认放在 300 秒。

TTL 60 秒：适合需要快速切流的业务，比如多机房容灾、游戏入口调度、直播回源调度。DNS QPS 会明显增加，但专业权威 DNS 一般能承受。

TTL 10 到 30 秒：适合临时发布、迁移、故障切换窗口。长期这么跑也不是不行，但要看 DNS 服务能力、客户端行为、递归 DNS 是否尊重 TTL。

TTL 0 秒：理论上不缓存，实际环境里很多递归 DNS、浏览器、系统不会完全按 0 秒处理。除非非常明确知道链路行为，否则不建议依赖 TTL 0 做生产调度。

低 TTL 不一定能做到秒级切换

这里补充一点，很多人把 TTL 当成强控制指令，这是不准确的。TTL 是 DNS 侧的缓存建议，递归 DNS 大多数会遵守，但不是所有客户端链路都会完全按你想的方式执行。

Windows、Linux、Android、iOS、浏览器、JVM、Go Runtime、Nginx、Envoy、游戏客户端，都可能有自己的 DNS 缓存策略。有些应用进程启动后解析一次，后面一直复用 IP；有些连接池长连接不断，DNS 已经切了，老连接还挂在旧 IP 上；有些本地 DNS 缓存会把很低的 TTL 拉高到一个最小值。

所以 TTL 30 秒并不等于 30 秒内所有用户都切走。真实切换时间要看 DNS 缓存、客户端连接保持、业务重连机制、负载均衡健康检查共同作用。

做游戏、直播、跨境电商这种场景尤其明显。DNS 只是入口调度的一环，后面还要看线路质量，比如 BGP、CN2、GIA、韩国回国优化、德国双 ISP 这类网络质量。如果你也在找这种海外业务入口和服务器承载环境，可以看看129云，像德国双ISP-C型适合 Tiktok、亚马逊、电商、游戏类场景，8C、8G DDR4 ECC、80G SSD、70Mbps 峰值带宽，业务切流时至少网络侧别先掉链子。需要人工确认线路和防护参数，也可以直接打客服热线 400-9177118。

哪些情况下真的会把 DNS 服务打爆

正常低 TTL 很少把成熟 DNS 平台打爆，但下面这些情况在线上确实见过。

自己搭权威 DNS，机器规格和架构太单薄

有些团队为了可控，把域名 NS 指到自建 BIND 或 PowerDNS。机器可能只有一台，单 IP，单机房，没有 Anycast，没有高防，没有多节点同步。平时几十 QPS 很稳，一旦 TTL 降到 30 秒，再遇到客户端重试或攻击，named 进程 CPU 飙高，UDP 丢包，解析开始超时。

DNS 服务和 Web 服务不一样。Web 服务慢了可能还能重试，DNS 解析慢了，用户看到的就是打不开。尤其 UDP 查询没有连接状态，丢包后客户端等待超时，体验很差。

客户端写法有问题

这个在线上很常见。某些客户端每次请求业务接口前都主动解析一次域名，不走系统缓存，甚至失败后毫秒级重试。TTL 设置多少已经不重要了，因为客户端绕开了正常缓存机制。

更麻烦的是 IoT、游戏启动器、爬虫、代理程序这类客户端，部署量一大，行为不规范就会放大 DNS 查询。比如 20 万客户端，每 5 秒主动解析一次，同一个域名就是 4 万 QPS，权威 DNS 可能还没事，但递归 DNS、链路、日志系统都要被拖进去。

DNS 记录频繁变动

TTL 低只是允许缓存更快过期，不代表可以不停改记录。频繁改 A 记录、CNAME 记录，会让递归 DNS 不断回源。很多 DNS 平台还有变更传播时间，不是控制台点完立即全球一致。

实际切流时更稳的方式是提前把 TTL 降下来，等旧 TTL 周期过去，再改记录。比如原来 TTL 600 秒，计划 20:00 切 IP，那 19:30 先把 TTL 降到 60 秒，等缓存逐步过期，20:00 再改 A 记录。切完观察稳定后，再把 TTL 拉回 300 或 600 秒。

DNS Query Flood 或反射攻击

DDoS 里 DNS 是高频目标。攻击者可以直接打你的权威 DNS，也可以伪造源地址做放大。自建 DNS 如果没做响应速率限制、递归关闭不彻底、ACL 配错，很容易被拿来当放大器。

权威 DNS 服务器不要开放递归，这是基本要求。Authoritative 只回答自己负责的域名，Recursive Resolver 才负责帮客户端递归查询。两种角色混在公网一台机器上，安全风险会变大。

业务服务器为什么通常不会因为 DNS 查询被打爆

业务服务器上跑的是 Nginx、Apache、Tomcat、Node.js、Go 服务、游戏网关这类程序。用户 DNS 查询阶段还没开始连你的 80、443 或业务端口。DNS 解析完成后，客户端拿到 IP，才会发起 TCP 握手或 UDP 业务包。

所以 TTL 低带来的直接压力在 DNS 系统，间接影响才可能传到业务侧。比如 TTL 很低导致切流更快，大量用户同时从旧 IP 转到新 IP，新 IP 后面的 SLB、源站、数据库连接池承压。这不是 DNS 查询打爆服务器，而是流量调度变化让业务流量集中到了某个节点。

这个区别很关键。排查时不要看到“改了 TTL 后服务器压力上来了”，就认定 DNS 查询打到了服务器。更应该看访问日志、连接数、带宽、SYN、UDP PPS、DNS 服务日志分别怎么变化。

实际线上怎么设置 TTL 更稳

稳定域名可以放 300 到 600 秒。比如官网、管理后台、普通 API，没有频繁切流需求，TTL 太低意义不大。缓存命中高，解析更快，权威 DNS 压力也低。

需要调度的入口域名可以放 60 到 120 秒。比如多地域服务、海外业务入口、游戏登录服、下载调度域名。这个范围在故障切换和 DNS 压力之间比较好控制。

发布、迁移、故障演练期间可以临时降到 30 秒。提前降，不要临切前一分钟才降。等变更完成，观察连接数、5xx、延迟、带宽都稳定，再恢复到正常 TTL。

不要把所有域名都无脑设成 10 秒。低 TTL 会增加 DNS 查询量，也会让一些递归 DNS 和客户端表现更不稳定。对大多数业务来说，TTL 30 秒以下带来的收益有限，排障时反而增加变量。

权威 DNS 承载能力要看什么

看 DNS 服务是不是 Anycast。Anycast DNS 会把同一个服务 IP 广播到多个节点，用户就近访问，单点故障和跨地域延迟都会好很多。没有 Anycast 的单点 DNS，跨境访问时解析延迟可能非常明显。

看 QPS 限制和套餐限制。有些 DNS 服务标称可用，但免费版、低配版有隐藏频控。平时没事，活动、游戏开服、促销大促时，解析 QPS 上来就开始限速。

看 SLA 和抗 DDoS 能力。DNS 是入口，入口挂了，后面服务器再强也没用。高防 DNS、Anycast DNS、智能解析、健康检查这些能力，要按业务重要程度选，不是所有域名都需要，但核心入口最好别省。

看日志和监控。至少要能看到解析量、地区分布、运营商分布、失败率、记录命中情况。没有数据时讨论 TTL，基本都在猜。

海外业务还要注意解析路径和访问路径不是一回事

海外服务器经常碰到一个误区：DNS 解析到了海外 IP，不代表用户访问线路就好。DNS 查询走的是用户到递归 DNS、递归 DNS 到权威 DNS 的路径；业务访问走的是用户到服务器 IP 的网络路径。

比如用户在国内，递归 DNS 是 223.5.5.5 或 114.114.114.114，权威 DNS 在海外，解析可能还行。但业务 IP 如果走普通国际线路，高峰期丢包高，HTTP 建连慢，游戏 UDP 抖动大，用户还是会觉得卡。

所以做跨境电商、Tiktok、亚马逊运营、游戏服，DNS TTL 只是入口管理。服务器线路要单独看，是否双 ISP、是否回国优化、是否有 CN2/GIA/BGP 质量，带宽是共享还是峰值，防火墙策略能不能扛异常流量。像129云的德国双ISP-B型，4C、4G DDR4 ECC、60G SSD、50Mbps 峰值带宽，适合轻量电商、账号环境、游戏辅助业务；韩国-E型是 8C、8G DDR4 ECC、70GB SSD、10Mbps 带宽，带傲盾防火墙和回国优化，更偏向需要低延迟回国链路的场景。

排查时看这些指标更快定位

如果怀疑低 TTL 带来问题，不要只盯服务器 CPU。DNS 和业务链路要分开看。

权威 DNS 侧看 QPS、响应耗时、SERVFAIL、NXDOMAIN、超时率、地区分布。如果 QPS 在 TTL 下调后按比例上升，但响应耗时稳定，说明 DNS 服务承受得住。

递归 DNS 侧不一定拿得到数据，可以通过客户端拨测间接判断。不同运营商、不同地区跑 dig 或 nslookup，看解析耗时、返回记录是否一致、TTL 是否按预期递减。

业务服务器侧看连接数、带宽、PPS、SYN_RECV、5xx、应用延迟。TTL 低导致切流时，如果新节点连接数突然翻倍，问题在流量集中，不在 DNS 查询。

客户端侧看重试策略和 DNS 缓存。移动端、游戏端、IoT 端尤其要查。不要每次请求都解析域名，不要失败后疯狂重试，最好复用系统 DNS 缓存，并设置合理的连接重建策略。

自建 DNS 时要特别克制

如果业务规模不大，自建权威 DNS 看起来成本低，但维护成本不低。至少要多节点、不同机房、不同 ASN，关闭递归，配置 RRL，监控 UDP/TCP 53，做好 zone 同步，准备 DDoS 防护。只放一台 VPS 跑 BIND，然后把核心业务域名 NS 指过去，这种在线上风险很高。

多说一句，DNS 服务对延迟很敏感。解析慢 200ms，用户访问首包就慢 200ms。页面里有多个域名，慢感会叠加。权威 DNS 节点离用户太远，即使业务服务器线路很好，也会在打开第一步被拖一下。

TTL 可以低，但不要用它替代流量治理

TTL 适合做入口切换和缓存控制，不适合承担完整的故障治理。真正的高可用还要靠 SLB、健康检查、应用重试、连接池管理、限流、熔断、DDoS 防护、跨区域容灾。

DNS 切换还有一个天然问题：它偏粗粒度。一个递归 DNS 后面可能有很多用户，你把它解析到某个 IP，这批用户都会过去。它不像 L7 Load Balancer 可以按请求、按连接、按权重细分调度。

所以低 TTL 可以用，但要知道它能解决什么，不能解决什么。比如一台源站挂了，DNS 把 A 记录切走可以减少新连接打到故障节点；但已经建立的 TCP 长连接、客户端本地缓存、递归 DNS 未过期记录，不会因为你点了 DNS 修改立刻消失。

比较稳的上线操作节奏

计划迁移 IP 或切换机房时，提前至少一个旧 TTL 周期降低 TTL。原来 600 秒，就提前 10 分钟以上；更稳一点提前半小时。把 TTL 从 600 改到 60，等旧缓存过期。

确认新服务器、SLB、证书、回源、防火墙、安全组都已经准备好。DNS 切过去以后，问题经常不是解析本身，而是新 IP 443 没放行、证书 SNI 配错、源站白名单没加、WAF 规则误拦。

切换时先小流量验证。有条件就用权重解析，比如 5%、10%、30%、50% 慢慢放。如果 DNS 平台不支持权重，可以用临时子域名、灰度客户端、地区解析做验证。

切完后观察递归缓存残留。旧 IP 在一段时间内仍然会有流量，旧服务器不要马上关。至少保留几个 TTL 周期，长连接业务要保留更久。

稳定后把 TTL 拉回正常值。生产域名长期 30 秒也不是不能跑，但如果没有持续切流需求，300 秒会更省心。

一句话回答这个问题

DNS 低 TTL 会增加 DNS 查询量，但正常情况下不会把你的业务服务器打爆，因为 DNS 查询不打到业务服务器。它可能打到权威 DNS、递归 DNS，或者你自建的 DNS 服务。真正要关注的是权威 DNS 承载能力、客户端解析行为、切流后业务流量是否集中，以及服务器线路和防护能力是否跟得上。