某天深夜，你像往常一样打开手机浏览器，输入一个用了三年的网址，按下回车。
页面确实跳转了，但映入眼帘的不是新闻首页，而是一个花花绿绿的博彩页面。URL栏里，还赫然显示着你刚才输入的域名。
你清了缓存、换了浏览器、甚至重启了路由器，问题时好时坏。
你的域名没有被盗，网站也没有被黑——你的DNS被劫持了。
这不是个案，而是一场正在蔓延的"隐形疫情"
近期，安全社区持续监测到一批来自 103.70.77.* 网段的可疑IP。大量用户反馈：访问正常网站时被悄悄重定向至广告、博彩或钓鱼页面。
但这远不是孤例。
2024年8月，国内家用路由器DNS劫持事件集中爆发。CNCERT曾通报一起波及全国所有省份、影响超400万IP地址的路由器DNS篡改事件。印度数十个政府官网在DNS层被劫持，集体跳转至博彩平台。DeFi领域120多个应用因DNS记录被篡改而沦为钓鱼入口，用户资产一夜归零。
DNS安全威胁，正在以复杂化、规模化、隐蔽化的姿态全面升级。
到底什么是DNS劫持？
每次你在浏览器输入一个网址——比如 www.example.com——你的设备并不知道这个名字对应哪台服务器。它需要先问一个"翻译官"：DNS（域名系统）。
DNS把人类可读的域名翻译成机器可识别的IP地址。拿到IP之后，你的浏览器才能真正连上目标服务器。
DNS劫持，就是有人在你和翻译官之间做了手脚。
当你问"example.com在哪里？"时，本该回答 1.2.3.4 的翻译官，被胁迫或替换后回答了 103.70.77.xx。于是你的浏览器像一个被指错路的出租车，载着你驶向一个完全陌生的目的地。
常见的劫持手段有三种：
路由器DNS篡改——攻击者扫描公网上暴露管理端口的家用路由器，利用默认密码或已知漏洞登录后台，把DNS服务器地址悄悄改成自己控制的恶意服务器。这台路由器下的所有设备——手机、电脑、智能电视——全部沦陷。
运营商链路劫持——部分小型ISP或被入侵的运营商设备，在DNS查询的UDP链路上注入伪造应答包。传统DNS基于UDP且无加密，攻击者只需比正常应答快一步到达客户端，就能"抢答"成功。
Local DNS缓存投毒——攻击者向运营商的递归DNS服务器发送精心构造的伪造响应，将错误记录写入缓存。此后所有依赖该Local DNS的用户，在缓存过期之前都会被导向恶意IP，形成大面积"传染"。
DNS缓存投毒：一次投毒，万人中招
如果说DNS劫持是"精确狙杀"，那DNS缓存投毒更像是"水源下毒"。
传统DNS体系中，为了提升解析效率，运营商会在本地部署递归缓存服务器（Local DNS）。某个域名被首次查询后，结果会被缓存一段时间（由TTL控制），后续查询直接从缓存返回，无需再向权威服务器求证。
这本来是一个高效的设计，但也留下了一个巨大的攻击面——如果有人在缓存写入阶段注入了一条错误记录呢？
经典的Kaminsky攻击利用的就是这个漏洞：攻击者向Local DNS发送大量精心伪造的DNS响应包。只要时机恰好赶在真正的权威服务器响应之前到达，Local DNS就会将错误的IP地址写入缓存。
此后，所有使用该Local DNS的用户——可能是一个小区、一座城市、甚至一个省——在TTL过期之前，都会被导向攻击者指定的IP。
更可怕的是，用户完全无感知。地址栏显示的依然是你输入的域名，浏览器没有任何告警。你甚至不知道自己打开的已经不是原来的网站。
为什么"换个DNS"治标不治本？
面对DNS劫持，最常见的建议是：把DNS换成 223.5.5.5 或 8.8.8.8。
但这只是把信任从一个Local DNS换到了另一个——查询链路上的UDP包依然是明文传输，依然可以被中间人抢答，依然可以被运营商链路上的设备拦截。
只要你还在用传统DNS协议，你的解析请求就是在"裸奔"。
手动配置DNS治不了运营商链路劫持，防不住缓存投毒扩散，也解决不了移动网络下Local DNS跨网调度导致的延迟问题。
对于App开发者和企业而言，用户的网络环境千差万别——你不可能要求每个用户都去改DNS设置。
HTTPDNS：从协议层釜底抽薪
既然UDP链路不安全，那就不走UDP。
HTTPDNS的核心思路极其简洁：将DNS解析从传统UDP协议迁移到HTTP/HTTPS协议。当客户端需要解析域名时，不再向Local DNS发送UDP查询，而是通过HTTP(S)请求直接访问HTTPDNS服务端。整个过程绕过运营商Local DNS，彻底斩断劫持链路。
为什么这能从根本解决问题？
协议层加密。 传统DNS查询基于UDP 53端口，明文传输，任何网络路径上的中间设备都能看到并篡改。HTTPDNS走HTTPS（TLS加密），中间人既看不到你在解析什么域名，也无法伪造响应——即使运营商设备想"抢答"，也因为无法伪造TLS证书而失败。
绕过Local DNS。 HTTPDNS请求直接发往服务商的解析集群，不经过运营商的递归缓存服务器。Local DNS的缓存投毒对你完全无效——因为你根本不用它。
精准调度。 传统DNS中，权威服务器看到的"客户端IP"实际上是Local DNS的出口IP，跨运营商、跨区域的解析经常被调度到距离很远的节点。HTTPDNS由客户端直接发起请求，服务端能拿到真实客户端IP，返回距离最近、链路最优的解析结果。对游戏、视频、直播类场景，这意味着可感知的延迟降低。
实时生效。 传统DNS的TTL缓存机制导致域名变更后需要等待各级缓存逐步刷新，最慢可达48小时。HTTPDNS支持服务端主动刷新缓存，域名切换秒级生效——在故障切换、灰度发布、流量调度等场景下，这是救命的能力。
哪些业务场景应该认真考虑接入？
移动App。 用户网络环境极度碎片化，Local DNS质量参差不齐，运营商劫持高发。接入HTTPDNS后，App内的域名解析完全自主可控，彻底告别"一部分用户打不开"的玄学问题。
金融/支付类应用。 DNS劫持可以将用户引导至钓鱼页面，对资金安全构成直接威胁。HTTPS加密解析确保链路不可篡改。
游戏/直播/音视频。 对延迟极度敏感，传统DNS跨网调度可能导致用户被分配到远端节点。精准调度能力直接提升体验。
全球化业务。 海外Local DNS质量更加不可控，部分国家甚至存在政策性DNS干预。全球节点覆盖确保各地区用户都能获得正确且快速的解析结果。
写在最后
DNS是互联网最古老的基础设施之一，也是最脆弱的一环。
它设计于一个"默认信任"的年代，却要在一个"默认对抗"的环境中运行。从 103.70.77.* 这样的劫持IP，到400万路由器被批量篡改，再到DeFi应用因DNS记录被劫而让用户血本无归——每一次事件都在提醒我们：
你以为的"网络正常"，可能只是攻击者希望你看到的幻象。
HTTPDNS不是银弹，但它确实从协议层面封堵了传统DNS最大的三个缺陷：明文传输、依赖中间缓存、调度不精准。以阿里云云解析DNS的移动HTTPDNS为例，目前已在游戏、社交、金融等行业被大规模验证，支持全球节点覆盖与毫秒级解析响应，接入成本也相当低——几行SDK代码就能完成集成。
对于任何认真对待用户体验和安全的团队来说，这是一笔投入产出比极高的基础设施投资。
毕竟，你的用户不会去研究"为什么网页跳转到了博彩网站"——他们只会卸载你的App。
如果你也想让自己的App告别这类隐患，可以了解一下 阿里云云解析DNS · 移动HTTPDNS，几行SDK代码即可完成接入，从协议层为你的用户筑起第一道防线。
