结论先行：有一类域名劫持不动你的解析记录，而是在流量经过的路径上把应答改掉：先宣告虚假路由把流量引走，再篡改其中的解析数据。所以企业自查时后台一切正常——记录没改、服务器没被动、监控没报警，异常只发生在用户那一侧。要发现它，得把观测点放到「解析结果对不对」上，而不是「解析服务活着没有」。

本文只谈企业侧如何发现与申告这类劫持，不谈运营商与注册机构层面的路由治理。

劫持发生在路径上，权威记录一切正常

一般的域名事故，原因在自己这侧：解析记录配错、服务器故障、证书过期。这类问题有明确的现象，查日志就能定位。而路径劫持是另一回事——攻击者在路由层面宣告虚假的地址前缀与更短的路径，把一部分流量引到自己控制的网络里，再对流量中的解析数据动手。

由于篡改不落在企业的权威服务器上，企业侧看到的指标全是好的：解析服务在线、记录未变更、响应时间正常。用户的体验却是访问被带到别的站点。两者之间的落差，正是这类攻击难以被发现的原因。

两种改法：直接换答案，或者换掉回答的人

一种是直接把解析值改成目标站点地址，用户请求什么域名，回来的是另一个地址。另一种更隐蔽：把解析值指向一台恶意的解析服务器，用户后续的域名请求都发给它，由它返回伪造的答案。

两种手法在观测上的表现不一样。前者表现为「应答内容突变」——同一个域名在短时间内解析出此前从未出现过的地址；后者表现为「应答来源突变」——客户端实际通信的解析服务器地址变了。分开看这两种现象，排查方向才清楚。

企业侧能看见的三样东西

其一，核心域名的解析地址基线。为对外的核心域名建一份解析记录基线：正常解析出哪几个地址、各自属于哪个网段、由谁维护。任何一次解析结果偏离基线，都应当触发告警，而不是靠用户反馈。基线的更新要走变更，不能随手改。

其二，解析应答报文的异常。多地多点做主动探测，比对同一域名在不同出口拿到的应答是否一致。这类攻击往往只影响部分区域的流量，单点探测看不出来，多点比对才能发现「这个省份解析到了别处」。

其三，路由路径的变更。对核心网段做路径探测，记录正常的路由跳数与关键节点。路径突然变短或改道，是一个需要核实的信号——这类异常在网络侧比在应用侧更早出现。

确认之后，申告路径要提前写下来

发现劫持之后，企业自己能做的处置有限，大部分动作在运营商与注册机构一侧：处置异常的地址前缀宣告、切断劫持链路。所以申告路径要提前写成一张联系表：上游运营商的对口人、域名注册与解析服务商的支持通道，以及内部谁有权发起申告。

这张表平时用不上，出事那天决定处置速度。行业里常见的延误不是技术判断慢，而是「不知道该找谁」。

边界与前提

三点说明。其一，本文所述技术过程引自公开的调查报告，属对该类攻击的一般性描述，不针对任何具体事件或主体；文中未涉及具体网络标识与地址。其二，路径劫持的发现依赖多点探测能力，单点监测无法覆盖；企业若无多点出口，可借助第三方拨测服务补足。其三，本文讨论的是发现与申告，处置权限在网络运营方一侧，企业侧的动作以核实、止损与协作为主。

深圳市奇摩计算机有限公司在网络运维交付中，对客户的核心域名与对外网段建立解析基线与路径基线，多地比对解析结果，异常时按预置联系表向上游申告；变更走书面确认与留痕。预约咨询，可以把核心域名的解析基线先建起来。