DNS 劫持防护：从被动监测到主动防御

引言：当 0.1% 的劫持率遇上千万 QPS

DNS 劫持是互联网的"老问题"，但在不同流量规模下，这个问题的严重程度截然不同。

对于百万 QPS 的系统，0.1% 的 DNS 劫持率意味着每秒约 1000 个请求被劫持——这个数字虽然不小，但通常在可接受范围内，可以通过客服工单、用户反馈等被动方式逐步发现和处理。

但当系统规模达到千万 QPS，同样 0.1% 的劫持率意味着每秒 10000 个请求被导向错误地址。更关键的是，千万 QPS 系统往往承载着核心业务场景，劫持带来的不仅是技术问题，更是直接的业务损失和安全风险。

这就是本文要探讨的核心命题：千万 QPS 系统必须将 DNS 劫持防护从"被动监测"升级为"主动防御"。

一、劫持放大效应：为什么规模改变了问题的性质

1.1 数量级差异带来的质变

1.2 劫持的"长尾效应"

DNS 解析结果会被客户端缓存，一次劫持的影响会持续整个 TTL 周期。在千万 QPS 系统中，即使劫持只发生在某个地区的部分用户，其影响也会因为用户基数而被显著放大。

假设某地区 LocalDNS 被劫持，影响该地区 5% 的用户：

• 百万 QPS 系统：约 5 万用户受影响，可通过引导用户切换 DNS 或等待缓存过期来解决

• 千万 QPS 系统：约 50 万用户受影响，等待被动恢复的时间成本不可接受

二、主动防御体系：HTTPDNS 与加密 DNS

2.1 HTTPDNS：绕过传统 DNS 链路

HTTPDNS 的核心思路是将 DNS 解析从 UDP 协议迁移到 HTTP 协议，直接与可信的 DNS 服务器通信，从根本上绕过可能被劫持的 LocalDNS。

HTTPDNS 的关键设计考量：

1. 服务端 IP 如何获取：HTTPDNS 服务本身的 IP 需要内置在客户端或通过可信渠道下发，避免"鸡生蛋"问题

2. 降级策略：当 HTTPDNS 服务不可用时，需要有合理的降级方案

3. 缓存策略：客户端需要实现本地缓存，减少对 HTTPDNS 服务的请求压力

2.2 DoH/DoT：标准化的加密 DNS 方案

DoH（DNS over HTTPS）和 DoT（DNS over TLS）是 IETF 标准化的加密 DNS 方案：

千万 QPS 系统中的选型建议：

• 移动端 App：优先使用 HTTPDNS，可控性强，便于集成业务逻辑

• Web 场景：关注浏览器对 DoH 的支持情况，考虑渐进式部署

• IoT/嵌入式设备：根据设备能力选择，DoT 的实现复杂度相对较低

三、劫持实时检测：防御的最后一道防线

即使部署了 HTTPDNS，也不能完全放弃对传统 DNS 链路的监测——部分场景可能仍依赖传统 DNS，降级时也需要知道当前环境是否安全。

3.1 多维度检测机制

3.2 检测策略设计

客户端主动探测：

1. 定期解析预设的"canary 域名"

2. 对比解析结果与预期 IP 列表

3. 检测首次连接时的证书指纹

4. 上报异常情况供后端分析

服务端被动校验：

1. 记录请求来源 IP 的地理位置

2. 对比 DNS 解析应返回的机房与实际访问机房

3. 检测异常的流量分布模式

3.3 响应时效性要求

四、架构演进：从单一方案到纵深防御

千万 QPS 系统的 DNS 劫持防护不是单点方案，而是需要构建纵深防御体系：

关键设计原则：

1. 默认安全：首选 HTTPDNS/DoH，传统 DNS 作为备选

2. 持续验证：即使使用安全方案，也要持续检测环境变化

3. 快速恢复：检测到异常时，能在秒级完成链路切换

4. 可观测性：完整记录解析链路，便于问题回溯

五、总结

DNS 劫持防护体现了百万 QPS 与千万 QPS 系统的一个本质差异：对"小概率事件"的容忍度。

百万 QPS 系统可以将 DNS 劫持视为"偶发问题"，通过被动监测和人工处理来应对。但千万 QPS 系统必须将其视为"必然发生的风险"，需要：

• 从架构层面主动规避（HTTPDNS/DoH）

• 建立实时检测能力

• 具备自动化的快速响应机制

这不是简单地把百万 QPS 的方案"做大 10 倍"，而是需要从被动应对转变为主动防御——这正是规模带来的架构思维转变。