千万 QPS 下的 DNS 治理：从“够用”到“可控”

导读：DNS 解析是网络请求的第一步，却常常被架构师忽视。本文将深入探讨为什么在系统规模从百万 QPS 跃升到千万 QPS 时，DNS 会从"偶发异常"变成"系统性风险"，以及如何通过 HTTPDNS 等方案实现 DNS 的工程化治理。

一、为什么 DNS 在千万 QPS 下成为瓶颈

在百万 QPS 系统中，LocalDNS 的缓存机制通常表现良好，解析延迟稳定在几十毫秒以内，偶发的 DNS 劫持也在可控范围。但当系统规模跃升到千万 QPS，DNS 层面的问题会发生质变。

这不是简单的线性放大。原因通常不是"单次解析慢了 1ms"，而是以下三个维度的变化。

网络与客户端的多样性上升。用户覆盖更多地区、运营商、企业网、Wi-Fi，递归解析链路质量差异巨大。有的网络会插入劫持、重定向、缓存污染；有的会对 TTL 处理不一致。解析失败不再是"少数"，而是会在某些网络域里形成"片区性、持续性"的失败簇。

域名调度复杂后，LocalDNS 缓存可能"帮倒忙"。当你希望按地域、运营商、负载、故障进行快速调度时，LocalDNS 和中间递归节点可能对 TTL、CNAME 链、EDNS Client Subnet 策略处理不一致。结果是调度的"生效时间"和"生效范围"不可控，故障切流不够快或不够一致。

DNS 变成"安全与可用性共同体"的入口。劫持、污染、强插广告并不会因为 QPS 更高而"更容易发生"，但你的用户盘更大、网络环境更复杂，被影响的"绝对人数"更大。一旦 DNS 被污染，往往触发 TLS 握手失败、重试风暴、连接雪崩等二次伤害。

核心结论：千万 QPS 不是“DNS 更快一点”的问题，而是“DNS 必须可治理”的问题。DNS 需要像登录态、证书、限流那样被纳入工程体系——可观测、可控、可降级、可回滚。

二、LocalDNS 的典型问题

下面这些问题在百万 QPS 也会出现，只是更像"边角料"；在千万 QPS 则更容易成为"系统性痛点"。

劫持、重定向与污染。运营商、热点 Wi-Fi、企业网可能对特定域名做重定向或注入。被劫持后常见表现不是"解析慢"，而是返回错误 IP 导致连到错误站点、TLS 失败、业务失败，或者返回"可连但不对"的中间页。规模越大，越容易遇到"某省某运营商某品牌路由器固件"的局部问题。

调度不可控。你给了 TTL=60s，并不意味着 60s 内一定切完。中间递归可能过度缓存导致 TTL 被放大，也可能不缓存导致解析放大，还可能对 CNAME 链不同环节做不一致缓存。故障切流时，"有的用户已切走，有的用户还在旧线路"，会显著加大排障难度。

解析失败的二次伤害。DNS 失败后客户端通常会重试，在高并发场景下可能触发短时间内大量新建连接、连接复用失效、上游负载被重试放大。真正需要治理的是：失败路径是否会把系统推向更糟状态。

三、HTTPDNS：把解析做成"可控的解析服务"

HTTPDNS 的核心思想是：客户端不走系统递归链路解析业务域名，而是用 HTTPS 请求你的解析服务（或第三方 HTTPDNS），拿到 IP 列表与策略，然后直连 IP。

它能带来的核心能力包括：抗劫持（解析结果通过 HTTPS 获取，减少被本地递归链路篡改的概率）、调度可控（可以按地域、运营商、实时负载、故障状况返回不同 IP 列表）、灰度与回滚（解析策略可以像配置中心一样快速生效、可回滚）、多 IP 返回加质量排序（返回多个候选 IP，客户端可做快速探测与切换）。

但它不是银弹，你必须正视新增的工程成本。

引导问题：HTTPDNS 本身也需要一个可访问的入口，通常用一个"尽可能稳定"的域名或内置 IP 加证书策略。

过期与缓存策略：客户端要实现 TTL、stale-while-revalidate、抖动避免同一时刻集体刷新。

与 TLS/SNI 的关系：直连 IP 时仍需使用域名做 SNI 与证书校验，不能"因为拿到 IP 就跳过校验"。

隐私与合规：解析服务会看到更多客户端网络信息，需要评估数据处理边界。

降级与兜底：HTTPDNS 不可用时，必须能回退到系统 DNS，否则你把单点从运营商递归换成了你自己。

工程落点：HTTPDNS 的价值不是"更快"，而是更确定、可调度、可治理。

四、落地实践：客户端与服务端设计要点

客户端侧（建议做成 SDK 或中间层）

缓存结构：按 hostname 缓存 {ips[], ttl, fetched_at, strategy_version}。

更新策略：命中缓存直接用；TTL 快到期时异步刷新（stale-while-revalidate）；刷新加随机抖动，避免整点羊群效应。

多 IP 探活与切换：首选 IP 失败后快速切换次优 IP，限制重试次数避免重试风暴；可记录简单的质量分（RTT/失败率）做短期排序。

安全：HTTPDNS 请求必须 HTTPS；可选证书锁定或公钥锁定；直连 IP 时仍使用域名做 SNI/Host 校验，这点至关重要。

服务端侧（当作"控制面服务"对待）

高可用：多地域部署、就近接入，Anycast 或全局流量调度均可。

策略管理：支持按地域、运营商、应用版本灰度；支持快速回滚。

观测：解析命中率（客户端缓存命中加服务端命中）、返回 IP 的后续连接成功率（需要端到端闭环指标）、失败分布（省份、运营商、版本、机型）。

防滥用与限流：HTTPDNS 也是 API，需要鉴权、签名、限流，避免被刷。

五、DNS 预解析：追求“恰好需要时已就绪”

预解析在高规模下更像“连接与解析的预热工程”，目标是减少首包耗时与失败重试。关键原则是：别追求“越早越好”，追求“恰好需要时已就绪”。

关键域名优先：只对核心链路域名做预解析，如登录、首页 API、CDN 主域名等，不要把所有域名都预解析。

时机选择：App 启动后延迟一点做，避开启动 IO 峰值；页面或业务即将触发前做，更贴近真实需求。

并发控制：限制同时预解析个数，避免在弱网下放大拥塞。

与缓存配合：将预解析结果写入 HTTPDNS 缓存，并设置合理 TTL 与抖动。

失败处理：失败不要无限重试；对失败做短期负缓存（negative caching），防止反复打爆解析服务。

六、一个反直觉的案例

很多人直觉会盯着 DNS 的"速度"。但在千万 QPS，更常见的真实故事是这样的：

你在 14:02 发现某地机房链路抖动，14:03 做了 DNS 切流，把该地解析权重切到备机房。结果 14:10 仍有一部分用户持续命中旧地址，因为某些 LocalDNS/递归节点把 TTL 放大或缓存链路不一致。这部分用户在失败后疯狂重试，导致备机房被重试流量冲击，原本可控的故障变成"跨机房连锁反应"。

这里的关键不是"解析慢"，而是调度生效时间和覆盖范围不可控。HTTPDNS/DoH 这类方案的价值在于：你把切流变成"配置变更"，而不是"赌递归链路什么时候更新"。

七、什么时候需要上 HTTPDNS

客观给出判断标准，不是一句"千万 QPS 必须 HTTPDNS"。

更适合引入 HTTPDNS/DoH 的信号：用户网络环境复杂（多运营商、多国家地区、企业网、校园网占比高）；需要更精细的流量调度与快速故障切流；已经观察到明显的 DNS 劫持、污染、TTL 不一致导致的问题；解析失败会引发明显的重试放大，威胁整体可用性。

可能仍可先用“系统 DNS+工程化治理”顶住的情况：用户网络环境相对单一；调度策略简单，主要依赖 CDN/边缘；有很高的连接复用率，DNS 触发频次低；已通过观测证明 DNS 不是主要尾延迟或故障来源。

写在最后

从系统 DNS 到 HTTPDNS，本质差异是：DNS 从"够用的默认能力"变成“需要可观测、可控、可回滚的基础设施”。很多系统会从“系统 DNS+预解析”升级到 HTTPDNS/DoH/DoT，核心是把不可控的递归链路变成可控的解析控制面。

在千万 QPS 的世界里，DNS 治理的目标不是“更快”，而是“更确定”。