很多人把这两个问题混着讲，其实它们的发生位置完全不同。劫持多发生在你能控制的环节：域名注册商的账号被人登了，解析服务商的后台被改了，NS 记录或者 A 记录被人换成别人的地址。污染发生的地方你控制不了：运营商的递归解析缓存被人塞了假结果，或者查询在链路上被人抢答。前者的表现是解析结果被你之外的某个人改掉了，后者是解析结果在传输过程中被替换。
共同的表现是：某个地区、某个运营商的用户访问站点时跳到了别的页面，而你自己在办公网里测试一切正常。这个测试环境的差异，往往就是排查的起点。
影响最大的是注册商环节。账号一旦失守，攻击者可以把 NS 记录整体指向自己的解析服务，域名从某种意义上就被移交了，后续所有解析都由对方说了算。其次是解析服务商，后台弱口令或者接口密钥泄露，记录可以被随时改动；这类改动通常很隐蔽，改完只影响一部分请求。
再往下是递归解析。缓存投毒影响范围可能是一整个片区，用户拿到的答案不是你设置的，但你的解析记录本身没有任何问题。最后是终端与本地网络，路由器被控、hosts 被改写，只影响局部，但在排查时最容易误导人。
注册商和解析服务商的后台，全部开启双因素认证，而且不要和邮箱用同一套口令——邮箱往往是找回密码的入口，邮箱一丢，前面的双因素也就没意义了。域名状态里的转移锁定要打开，防止有人拿着伪造材料把域名转走。
用接口管理解析时，密钥按最小权限发放，限定来源地址并定期轮换。权威解析至少要落到不同网络的两组地址上，避免单点。TTL 的设置也有讲究：太长会让切换变慢，太短会让被投毒之后的暴露时间变长，需要按变更频率取一个平衡。DNSSEC 能给解析结果做签名验证，但一定要先确认服务商支持情况和回退方案，配错了会导致域名直接解析失败，这个风险要提前评估。
邮件相关的记录也值得一起做：SPF、DKIM、DMARC 配齐，能减少域名被冒用发钓鱼信的概率。这类冒用虽然不是解析被改，但用户看到的发件人就是你的域名，造成的信任损失是一样的。
整理过几次事件记录会发现，域名相关的改动相当一部分发生在深夜或者节假日。原因很直白：这个时段值班的人少，监控告警可能没人第一时间处理，从改动到被发现之间的窗口最长。所以解析记录的告警不能只发到邮箱，要能推到值班人的终端上，并且明确谁负责响应。
判断改动是否异常也有个简单办法：把当前的解析结果与上一条记录做差异比对，只对变化的部分告警。这样既不会被无关信息淹没，也不会漏掉真正的改动。
权限上还有一点容易被忽视：能改解析的人不宜太多。每多一个入口，就多一处可能被钓鱼或者撞库突破的地方，出现问题时的排查范围也跟着扩大。按职责分配权限，改动走审批，是成本最低的一道防线。
定期从多个地区探测自己的域名，把结果和预期逐个比对；对解析记录做变更监控，任何改动都要有告警，哪怕是自己人做的，也应该知道是谁在什么时候改的。域名到期时间和证书到期时间都要提前提醒，这类问题看着低级，但每年都有站点因为忘了续费而失联。
先定位改动的位置——是注册商还是解析服务商，然后立即改回并强制所有相关账号下线改密。如果 NS 被整体改掉，要在注册商处锁定并联系服务商处理。短期可以引导用户走另一个域名，或者直接使用带有效证书的地址访问。事情过去之后要做复盘：账号是怎么丢的，是弱口令、是钓鱼、还是接口密钥泄露，没查清原因就谈不上修复。
售后客服
企业微信
