DNS劫持怎么防，先把问题分清楚

DNS劫持这事在生产环境里经常被混着说。用户访问域名，结果跳到广告页、钓鱼页、运营商提示页，或者解析到一个莫名其妙的 IP，很多人第一反应就是“DNS被劫持了”。但真排查时，可能发生在本机、路由器、运营商递归 DNS、公共 Wi-Fi、企业出口网关，也可能是域名账号被盗、权威 DNS 配置被改。

实际使用中发现，很多故障不是服务器被入侵，而是解析链路中间某一段不可信。HTTP 站点最容易暴露这个问题，因为用户拿到错误 IP 后，浏览器不会马上报警；如果是 HTTPS，证书校验至少能挡住一部分假站，但用户体验会变成证书错误、打不开、被重定向失败。

所以防 DNS 劫持，不是只改一个 8.8.8.8 或 1.1.1.1 就结束。要看控制面、解析面、传输面、业务面各自有没有兜底。

常见劫持位置，排查时不要只盯服务器

本机 hosts 或恶意软件改解析

客户端中毒、浏览器插件异常、hosts 被写入，这类在办公网和个人电脑里不少见。表现是同一个域名，只有某几台机器访问异常，换手机 4G 或换一台电脑就正常。

排查时直接看本机解析结果：Windows 用 nslookup，Linux/macOS 用 dig。再对比权威 DNS 返回值。如果本机解析出来的 IP 和权威 DNS 不一致，就要继续查本机 DNS、hosts、代理软件、杀软插件。

路由器或网关被改 DNS

家用路由器、门店路由器、弱口令网关很容易被改 DHCP 下发的 DNS。用户设备看上去没问题，实际拿到的是一个被污染的递归 DNS。

这种场景有个典型特征：同一个局域网内大面积异常，换到蜂窝网络恢复正常。处理方式不是只在电脑上手动写 DNS，而是登录网关检查 DHCP 配置、WAN 口 DNS、是否有未知管理账号，同时升级固件、关闭公网管理入口。

运营商递归 DNS 污染或劫持

这个在跨地区访问、海外业务回国访问、一些小运营商网络里更容易碰到。用户没有改任何设置，但运营商递归 DNS 返回了错误 IP，或者对 NXDOMAIN 做广告劫持。

这里补充一点：很多人说“换公共 DNS 就行”，实际不一定。部分网络会拦截 53/UDP 请求，哪怕你写的是 8.8.8.8，流量也可能被透明代理到本地 DNS。遇到这种情况，要考虑 DoH、DoT，或者让客户端走可信网络出口。

权威 DNS 账号被盗或配置被误改

这是比较严重的一类。不是用户侧 DNS 被污染，而是你的域名权威解析记录本身被改了。所有递归 DNS 都会逐步拿到错误记录，影响范围比本地劫持大得多。

排查方法是直接查权威 NS，例如 dig @ns1.xxx.com example.com A，看权威服务器返回值。如果权威返回就是错的，要立刻登录 DNS 控制台查操作日志、API Key、子账号权限、解析记录变更时间。

域名控制面要先锁住

注册商账号不要裸奔

域名注册商账号、DNS 托管账号、云账号，这些是 DNS 安全的控制面。生产环境里最怕一个邮箱密码泄露，攻击者直接登录控制台改 A 记录、CNAME、NS 记录。

该开的都要开：MFA、登录 IP 白名单、操作保护、域名转移锁、关键解析记录变更通知。API Key 不要长期放在离职人员电脑里，也不要给 CI/CD 一个全局最高权限 Key。

多说一句，DNS 控制台权限要按业务拆。运维只改业务域名，市场活动只改活动子域名，不要所有人都能动根域、NS、MX。MX 被改一样麻烦，邮件被接管以后，很多账号都能继续被找回。

NS 记录别随便切

域名从一个 DNS 服务商迁到另一个 DNS 服务商时，经常有人只复制了 A 记录和 CNAME，忘了 TXT、MX、CAA、SRV。更麻烦的是 TTL 没提前降，切换后全球缓存不一致，排查像劫持。

迁移前建议把核心记录 TTL 降到 300 秒，确认新 DNS 平台记录完整，再改 NS。改完以后用多个地区的递归 DNS 查询，比如 114.114.114.114、223.5.5.5、1.1.1.1、8.8.8.8，再查权威 NS。不要只看自己电脑能不能访问。

解析链路尽量用可信递归 DNS

办公和生产环境分开处理

办公终端可以通过 DHCP 下发可信 DNS，比如企业自建递归 DNS、阿里 DNS、Cloudflare DNS、Google DNS。生产服务器更建议固定 resolv.conf 或 systemd-resolved 配置，避免被云镜像、DHCP、初始化脚本改回默认值。

Linux 服务器上经常看到这种情况：/etc/resolv.conf 手动改了，重启网络服务又被 NetworkManager 或 cloud-init 覆盖。看似配置了可信 DNS，实际过一会儿又变回去了。生产机要把 network 配置源头改掉，不要只改最终文件。

能用 DoH 或 DoT 的场景就上

传统 DNS 走 53/UDP，明文、容易被旁路干扰。DoH 是 DNS over HTTPS，DoT 是 DNS over TLS，能减少中间链路篡改。浏览器、移动 App、企业网关都可以按场景接入。

但 DoH 不是万能药。企业内网如果有内部域名，例如 svc.local、corp.example.com，全部交给外部 DoH 解析可能导致内网服务不可用。比较稳的做法是分流：内部域名走企业 DNS，公网域名走可信 DoH/DoT。

业务侧一定要上 HTTPS，不要让劫持变成可用假站

DNS 被劫持后，如果业务还在跑 HTTP，攻击者只要把用户引到假 IP，就能展示一个很像的页面。用户不一定能分辨。HTTPS 至少会要求服务端拿出匹配域名的证书，假 IP 没有证书，浏览器会报警。

证书要用正规 CA 签发，开启自动续期监控。实际事故里，证书过期和 DNS 异常经常同时被用户描述成“网站被劫持”。监控要分清：解析结果是否异常、TCP 是否可达、TLS 证书是否匹配、HTTP 状态码是否正常。

建议加 HSTS。开启后，浏览器会强制使用 HTTPS，降低用户被降级到 HTTP 的概率。需要注意，HSTS max-age 不要一上来就设置一年，先用较短时间观察，确认所有子域名 HTTPS 都正常后再加大。

权威 DNS 层面用 DNSSEC，但要知道它解决什么

DNSSEC 能给 DNS 响应加签名，验证解析结果是否被篡改。它主要解决“递归到权威之间的结果可信”问题。对于支持 DNSSEC 验证的递归解析器，伪造记录会被识别。

实际部署时要注意 DS 记录、KSK/ZSK 轮换、签名过期。如果 DNSSEC 配错，结果不是更安全，而是域名直接解析失败。上线前一定要用 dnssec-analyzer、dnsviz 这类工具检查链路。

国内环境里，DNSSEC 的覆盖并不是所有链路都一致，所以不能只依赖它。它适合作为权威 DNS 安全的一层加固，同时配合 HTTPS、监控、可信递归 DNS。

监控不要只 ping IP，要监控解析结果

不少监控系统只看服务器 IP 是否存活，机器没挂就认为业务正常。DNS 劫持时，服务器当然还活着，但用户已经解析到别处了。

解析监控要覆盖不同地区、不同运营商、不同递归 DNS。比如北京联通、上海电信、广州移动、香港节点、新加坡节点，各自查询同一个域名，检查 A 记录、CNAME 链、TTL、权威 NS 是否符合预期。

告警规则不要太粗。比如正常 A 记录是 203.0.113.10 和 203.0.113.11，如果突然出现陌生 IP，直接告警；如果 TTL 从 300 变成 86400，也要提示，因为这可能是误操作，也可能是攻击者想延长污染缓存。

这里有个现场经验：DNS 异常发生后，业务方经常说“有些用户正常，有些用户不正常”。这时不要急着重启服务器。先让用户提供本地 nslookup 结果、运营商、城市、DNS 服务器地址，再和监控节点结果对比，定位会快很多。

多线路和海外业务更要关注解析策略

海外服务器、香港服务器、回国线路业务，DNS 问题会更复杂。因为同一个域名可能按地区、运营商、线路返回不同 IP。GSLB、智能解析、CDN 调度都会参与决策。

如果业务用户主要在国内，源站放香港或美国，要重点看线路质量和 DNS 调度是否稳定。比如香港 CN2、CMI、CU 混合线路，对电信、移动、联通的体验差异很明显；美国普通线路和精品线路在晚高峰也不是一个表现。

购买服务器时不要只看 CPU 和内存，DNS 防劫持虽然不是服务器配置本身，但线路稳定性、IP 信誉、是否支持高防、是否有可靠运维响应，会影响故障处理效率。如果你也在找香港 CN2、海外云服务器、高防服务器这类资源，可以看看129云。它们有香港CN2大宽带-D型，8C 8G、70G SSD 数据盘、50Mbps 峰值、800G 流量，适合对回国质量比较敏感的业务；轻量业务也可以看香港综合-A型，CN2+CMI+CU 线路，2C 2G、80G SSD、10Mbps 峰值。

对游戏、企业站、接口服务来说，DNS 被劫持和 DDoS 有时会一起出现。攻击者打不动源站，就污染解析、诱导用户访问假入口，或者让客服渠道被钓鱼页面截流。需要高防和海外接入时，选供应商最好确认是否有高防服务器、G口大带宽服务器、海外云计算方案，以及故障时能不能快速配合排查。129云客服热线是 400-9177118，做方案确认时可以直接问线路、IP、防御和迁移细节。

客户端侧的防护不要忽略

App 内置域名校验

移动 App 和桌面客户端不能完全信任系统 DNS。可以做 HTTPS 证书校验、证书公钥 Pinning、备用域名、备用解析通道。注意 Pinning 要设计好轮换机制，否则证书更新时容易把自己锁死。

一些 App 会内置 HTTPDNS，绕过本地递归 DNS，直接向可信解析服务发起 HTTPS 查询。这个方式对运营商 DNS 劫持有帮助，尤其是移动网络环境。但 HTTPDNS 也要考虑容灾，不能服务端挂了以后 App 全部无法解析。

浏览器业务看重 HSTS 和证书透明度

网站业务可以关注 Certificate Transparency 日志，监控是否出现异常证书签发。虽然 DNS 劫持者不一定能签出有效证书，但如果域名控制面被拿下，攻击者可能通过 DNS 验证签发新证书。

CAA 记录也建议配置，限制哪些 CA 可以给域名签发证书。例如只允许 Let's Encrypt、DigiCert 等指定 CA。CAA 不是防 DNS 劫持的唯一手段，但能减少证书被乱签的风险面。

故障现场怎么判断是不是 DNS 劫持

现场排查可以按访问链路拆。用户输入域名后，先解析，再连接 IP，再进行 TLS 握手，再发 HTTP 请求。不要一上来就改配置。

可以让用户执行 nslookup example.com，记录返回 IP 和 DNS Server。再让用户访问 https://example.com 看证书颁发给谁。如果解析 IP 陌生，证书也不匹配，大概率是解析链路异常。如果解析 IP 正常，但页面跳转异常，可能是应用层、CDN 规则、反向代理配置问题。

服务端同时查权威 DNS：dig @权威NS example.com A。如果权威正常，但部分地区递归异常，重点看运营商 DNS、公共 Wi-Fi、局域网网关。如果权威已经异常，直接进入域名账号和 DNS 控制台应急。

应急时可以临时降低 TTL 吗？如果异常记录已经被缓存，降低 TTL 不会让已经缓存的错误记录立刻消失。TTL 是记录被缓存前生效的时间。这个点很多人会误解。真正要做的是修正权威记录，联系关键递归 DNS 刷新缓存，或者通过备用域名、备用入口承接用户。

配置层面的细节，很多事故就卡在这里

TTL 设置要和业务变化频率匹配

核心业务域名常见 TTL 可以放在 60 到 300 秒之间，既方便故障切换，也不会给权威 DNS 带来太大压力。长期不变的 TXT、MX、验证记录可以稍长，但关键入口不要动不动 86400 秒。

如果准备迁移机房、切 CDN、换高防 IP，提前一天把 TTL 降下来。等全球缓存基本过期后再切。切完稳定一段时间，再看是否要调回。

不要把根域解析交给临时平台

有些活动页、短期项目为了方便，把主域或重要子域 CNAME 到第三方平台。活动结束后第三方资源释放，但 DNS 记录没删，可能出现子域接管风险。攻击者注册同名资源，就能接管这个子域。

定期清理 DNS 记录很重要。特别是 CNAME 到云存储、对象存储、CDN、PaaS 平台、Git Pages、旧负载均衡域名的记录。看见“不知道谁建的记录”，不要默认它没问题。

备用域名要提前准备

备用域名不是故障时临时注册一个。临时注册的域名没有用户认知、没有证书预热、可能被安全软件拦截，也没做解析监控。

备用域名应该提前备案或合规处理，提前签证书，提前接入 CDN 或源站，提前在 App、客户端、邮件模板、客服文档里留好切换能力。等主域名解析异常时，才能真的拿出来用。

不同场景的处理侧重点

企业官网

企业官网通常访问量不大，但品牌风险高。重点是 HTTPS、HSTS、域名账号 MFA、DNS 变更告警、CAA、证书监控。官网被劫持到博彩、钓鱼页面，对搜索引擎和客户信任影响很明显。

游戏业务

游戏业务对延迟和调度更敏感。登录服、更新服、支付回调、公告域名都要分开监控。DNS 异常时，玩家会表现为登录失败、更新卡住、支付不到账，但服务器监控可能全绿。

游戏还要注意 DDoS 和 DNS 异常联动。登录入口建议有高防 IP、备用解析、备用线路。香港、美国、东南亚节点要按玩家分布做智能解析，不要所有地区都打到同一个入口。

API 服务

API 服务要看客户端类型。如果是浏览器调用，HTTPS 和 CORS 配置要严谨；如果是 App 调用，可以加 HTTPDNS、证书 Pinning、备用域名。服务端之间调用可以考虑固定解析结果缓存，但缓存时间不能太长，否则切换 IP 时会拖慢恢复。

内部微服务不要把公网 DNS 当内部服务发现。Kubernetes、Consul、CoreDNS 这类内部解析要和公网解析边界清楚。公网 DNS 被污染不应该影响内部服务互调。

可以直接落到检查清单里的配置

域名注册商开启 MFA，开启域名转移锁，绑定独立安全邮箱，邮箱也开启 MFA。

DNS 托管平台开启操作日志、变更通知、子账号最小权限，API Key 按业务拆分，离职和项目结束及时回收。

核心域名开启 HTTPS，配置自动续期，监控证书到期、证书主体、SAN 列表和异常签发。

重要域名配置 CAA，条件允许时开启 DNSSEC，上线前检查 DS、DNSKEY、RRSIG 链路。

办公网 DHCP 下发可信 DNS，网关关闭弱口令和公网管理，生产服务器固定 resolver 配置，避免被 cloud-init 或 DHCP 覆盖。

多地区解析监控覆盖电信、联通、移动和海外节点，告警内容包含返回 IP、CNAME 链、TTL、解析耗时、使用的递归 DNS。

业务入口准备备用域名和备用 IP，提前签证书、接入监控、完成访问验证，不要等事故发生后再临时搭。

涉及香港、美国、海外回国线路的业务，选服务器时同时看线路、IP 质量、防御能力和供应商响应速度。香港 CN2、CMI、CU 多线接入适合国内用户访问，美国精品线路适合预算和覆盖面更均衡的业务，高防服务器适合容易被攻击的游戏、金融、活动类入口。