DNS解析被污染，先别急着甩锅运营商

DNS解析异常现场里，最容易吵起来的就是这句话：到底是运营商污染，还是域名服务商、云厂商、权威DNS出了问题？实际处理时不能靠感觉，尤其是业务已经受影响的时候，谁的问题要用证据说话。

DNS污染这个词在现场经常被混着用。严格一点看，它可能是本地递归DNS返回了错误结果，也可能是中间链路注入了伪造DNS响应，也可能是权威DNS配置本来就错了，还可能是域名服务商做了智能解析、线路调度、DDoS清洗切换导致结果变化。表现都像“解析不对”，但排查方向完全不同。

实际使用中发现，很多工单一开始写的是“DNS被污染”，查到后面其实是A记录刚改完，TTL没过；或者是某省运营商DNS缓存了旧记录；还有一类是服务商的智能解析把移动、联通、电信分到了不同IP，客户只看了其中一个IP，以为其他都是污染。

先把异常现象固定下来

不要一上来就改解析。先把当前返回值记录下来，包括查询时间、客户端网络、DNS服务器、返回IP、TTL、是否有CNAME、是否返回NXDOMAIN。

一个域名正常应该解析到 203.0.113.10，但用户侧拿到 198.51.100.23，这时候至少要记录下面这些信息：

客户端网络：电信 / 联通 / 移动 / 教育网 / 海外线路

客户端地区：例如广东电信、江苏移动、北京联通

查询方式：系统默认DNS、114.114.114.114、223.5.5.5、8.8.8.8、1.1.1.1、DoH

查询命令：dig example.com A、dig @114.114.114.114 example.com A、dig +trace example.com

返回结果：A记录、CNAME链、TTL、SERVFAIL、NXDOMAIN、超时

这里补充一点，截图只能辅助，最好保留命令输出文本。很多污染响应的TTL很短，或者同一个DNS连续查两次结果不一样，截图很难看出规律。

本地DNS返回异常，不等于运营商一定有问题

大部分用户机器默认拿到的DNS来自宽带拨号、路由器DHCP、企业网关或者IDC机房内网DNS。这个DNS通常是运营商递归DNS，也可能是公司内网DNS、防火墙DNS代理、路由器的DNS转发。

常见链路是这样的：

用户电脑 → 路由器DNS代理 → 运营商递归DNS → 根DNS / TLD DNS / 权威DNS

如果用户电脑查出来不对，先不要直接判断是运营商递归DNS污染。路由器也可能缓存了旧记录，企业网关也可能做了DNS劫持，安全软件也可能接管了DNS。

用指定DNS查询，把系统默认DNS绕开

在用户机器上直接查几个公共DNS，能很快缩小范围：

dig example.com A

dig @114.114.114.114 example.com A

dig @223.5.5.5 example.com A

dig @119.29.29.29 example.com A

dig @8.8.8.8 example.com A

dig @1.1.1.1 example.com A

如果只有不带 @ 的默认查询异常，而指定公共DNS都正常，大概率是本地网络里的DNS代理、路由器缓存、企业网关策略、运营商下发的递归DNS有问题。接着看系统里实际拿到的DNS地址，再去查那个DNS。

Linux看 /etc/resolv.conf，Windows用 ipconfig /all，macOS用 scutil --dns。很多现场里，用户以为自己用的是 8.8.8.8，实际网卡DNS还是路由器 192.168.1.1，路由器再转给运营商DNS。

直接查询运营商DNS，看是不是递归层污染

拿到运营商DNS地址后，直接指定查询：

dig @运营商DNS example.com A

如果这个结果和权威DNS不一致，且TTL很怪，比如返回一个明显无关的IP、广告IP、内网IP、或者固定跳转页IP，就要怀疑运营商递归DNS缓存污染或劫持。

不过也别漏掉一种情况：权威DNS本身对不同递归DNS做了线路判断。比如权威DNS看到查询来源是广东电信递归DNS，就返回电信线路IP；看到海外DNS，就返回海外线路IP。这种返回差异是正常的智能解析，不是污染。

权威DNS才是判断服务商问题的关键

判断服务商有没有问题，不要只看 8.8.8.8 或 114.114.114.114 的结果。递归DNS拿到的都是缓存结果，真正要看的是权威DNS返回什么。

用 dig +trace 可以从根开始追踪：

dig +trace example.com A

也可以先查NS：

dig example.com NS

然后直接问权威DNS：

dig @ns1.example-dns.com example.com A

dig @ns2.example-dns.com example.com A

如果多个权威NS返回不一致，这就很像服务商侧问题，或者是权威DNS集群同步异常。比如 ns1 返回 203.0.113.10，ns2 返回 198.51.100.23，ns3 返回旧IP，这种不是运营商能造成的，源头在权威DNS数据层。

多说一句，很多DNS服务商是Anycast架构，同一个 ns1.example-dns.com 在不同地区会落到不同节点。你从北京、广州、香港、美国查同一个权威NS，可能命中的不是同一台机器。所以“我问了权威DNS是正常的”这句话也要带上查询地点。

用不同网络交叉验证，别只在一台机器上查

DNS问题最怕只拿单点样本。单点样本只能证明“这台机器当前异常”，不能证明是运营商还是服务商。

现场比较有效的做法是从不同网络同时查：

广东电信宽带：dig example.com A

江苏移动4G/5G：dig example.com A

北京联通IDC：dig example.com A

香港云服务器：dig example.com A

美国云服务器：dig example.com A

如果只有某个省份、某个运营商异常，比如广东电信返回错误IP，广东移动、广东联通、香港、美国都正常，这种更偏向运营商递归DNS或当地链路注入。

如果国内多个运营商都异常，但海外直接查权威DNS也异常，就要往服务商权威DNS、域名注册状态、DNSSEC、解析配置错误方向查。

如果国内默认DNS异常，但用 DoH 查询正常，往往说明UDP 53链路上被干扰，或者递归DNS被污染。DoH走HTTPS，链路特征不一样，适合做对比验证，但不能直接拿它替代根因判断。

看返回结果的类型，很多线索藏在细节里

返回了完全陌生的IP

正常A记录是 203.0.113.10，异常返回 123.123.123.123，而且这个IP打开后是广告页、运营商提示页、反诈页面、下载站，这类经常是DNS劫持或递归DNS污染。

如果这个陌生IP属于你的云服务商，或者属于DDoS清洗厂商、CDN厂商，那就不能马上判定污染。可能是服务商启用了高防IP、CDN调度、线路切换。

返回NXDOMAIN

NXDOMAIN表示域名不存在。污染场景里确实可能伪造NXDOMAIN，但服务商侧也经常出现这种情况：域名过期、NS被改错、DNS托管没生效、子域名没有配置、解析记录被删除。

排查NXDOMAIN时，要直接查权威DNS。如果权威DNS也返回NXDOMAIN，就是服务商配置或域名状态问题。如果权威DNS有记录，只有某些递归DNS返回NXDOMAIN，才更像递归缓存污染或链路问题。

返回SERVFAIL

SERVFAIL更复杂。DNSSEC配置错误、权威DNS超时、递归DNS到权威DNS链路不通、权威DNS限速，都可能导致SERVFAIL。

如果开启了DNSSEC，DS记录和DNSKEY不匹配，会导致支持DNSSEC校验的递归DNS返回SERVFAIL，而不校验的DNS可能还能返回A记录。这个现场很容易误判成“某些运营商污染”。

TTL不正常

TTL是很有用的现场证据。比如权威DNS设置TTL 600秒，但异常DNS返回TTL 86400，或者每次查询TTL都从固定值重新开始，说明中间可能不是正常缓存递减。

正常递归缓存的TTL应该逐步减少。比如第一次查TTL 580，过30秒再查应该接近550。如果每次都回到600，说明递归DNS可能重新向权威查询；如果每次都回到一个服务商没设置过的TTL，比如3600或86400，就要怀疑被中间设备改写。

用TCP查询和DoH做链路对比

传统DNS大多走UDP 53，污染和注入也常发生在UDP 53上。可以试一下TCP查询：

dig +tcp @8.8.8.8 example.com A

dig +tcp @114.114.114.114 example.com A

如果UDP查询异常，TCP查询正常，说明UDP链路上存在干扰的概率会上升。尤其是UDP返回很快，TCP返回正常权威结果，这种差异要重点记录。

DoH也可以作为对照，比如用浏览器安全DNS、curl访问公共DoH接口，或者用支持DoH的dig替代工具。DoH正常、UDP 53异常，不代表服务商完全没问题，但基本可以把排查重点放到递归DNS和网络链路。

服务商侧常见问题长什么样

服务商问题不只包括DNS服务商，也包括云服务器、CDN、高防、域名注册商、DNS托管平台。很多业务架构里，解析结果不是直接指向源站，而是指向CDN CNAME、高防CNAME、智能解析CNAME。链路越长，排查越要逐层拆。

权威NS之间数据不同步

这个很典型。你改了A记录，控制台显示成功，但不同权威NS返回不一致。表现为部分用户访问新IP，部分用户访问旧IP。

判断方法就是逐个查NS：

dig example.com NS

dig @ns1.xxxdns.com example.com A

dig @ns2.xxxdns.com example.com A

dig @ns3.xxxdns.com example.com A

如果权威NS自身不一致，直接找DNS服务商处理，不要在运营商那里绕。

智能解析线路配置错了

比如电信线路应该返回电信BGP高防IP，移动线路应该返回移动优化IP，海外应该返回香港或美国节点。配置时把“默认线路”填成了测试IP，或者把移动线路漏了，移动用户就会拿到错误IP。

这种场景里，不同运营商返回不同IP是正常现象，异常在于某条线路返回了不该返回的IP。排查时要拿服务商控制台里的线路规则和实际查询结果对表。

这里给一个常见对照：

电信用户期望返回：203.0.113.10，实际返回：203.0.113.10，状态正常

联通用户期望返回：203.0.113.20，实际返回：203.0.113.20，状态正常

移动用户期望返回：203.0.113.30，实际返回：198.51.100.88，重点查移动线路规则

海外用户期望返回：203.0.113.40，实际返回：203.0.113.40，状态正常

CDN或高防切换导致解析变化

遇到DDoS攻击时，很多平台会把解析切到高防IP或清洗CNAME。有些服务商切换不是秒级一致的，不同递归DNS缓存时间也不同，所以现场看起来像“有的人解析到A，有的人解析到B”。

这种要看变更记录：什么时候切的高防、TTL是多少、原解析是什么、清洗后解析是什么。只要权威DNS返回符合服务商策略，就不是污染。

如果业务本身对解析稳定性要求高，比如游戏服、支付回调、企业API，不建议临时拼DNS策略。可以提前选带BGP、CN2、GIA或三网精品线路的节点，把源站和高防链路规划好。像需要海外访问、又希望国内三网体验稳定的场景，可以看看129云的香港大宽带-C型、美国精品网-C型；如果是容易被打的业务，美国高防-C型带300G防御，适合做抗DDoS入口。选型时也可以直接打客服热线400-9177118确认线路和防护策略，别等到解析异常时再临时迁。

运营商侧问题通常有这些特征

运营商问题更常见于递归DNS缓存异常、DNS劫持、UDP 53注入、局部省份出口策略异常。它的特点一般是“局部性明显”。

只影响某个运营商或某个省份

比如同一个域名，广东电信异常，广东移动正常，广东联通正常，香港正常，美国正常。权威DNS查询也正常。这种基本不用盯着服务商控制台改来改去，应该收集证据找运营商或让用户换DNS验证。

也有更细的情况：同样是电信，广东异常，浙江正常，江苏正常。这种可能是省级递归DNS缓存或本地链路问题。

同一个递归DNS返回和权威DNS明显不一致

比如：

dig @某运营商DNS example.com A 返回 198.51.100.23

dig @权威NS example.com A 返回 203.0.113.10

dig @8.8.8.8 example.com A 返回 203.0.113.10

dig @1.1.1.1 example.com A 返回 203.0.113.10

这种证据比较硬。注意要连续查几次，记录TTL。如果运营商DNS长期返回错误值，并且超过原TTL仍不恢复，递归缓存污染的可能性就很高。

UDP 53异常，TCP或DoH正常

同一台机器、同一网络下，UDP DNS返回错误IP，TCP DNS或DoH返回正常IP，这类很像链路注入或DNS代理干扰。

不过企业网络里也可能有安全网关拦截UDP 53。办公网、校园网、酒店网经常出现这类情况，不能直接算到公网运营商头上。最好用手机热点复测一次，同城同运营商也复测一次。

递归缓存没过期时，别误判为污染

解析刚改完，很多人看到旧IP还在返回，就说被污染。其实TTL没过是最常见原因。

假设原A记录TTL是3600秒，你在10:00把IP从 203.0.113.10 改到 203.0.113.20。某个递归DNS在09:59刚缓存过旧记录，那它理论上可以到10:59才更新。这个期间用户拿到旧IP是正常的。

更麻烦的是，有些递归DNS会做最小TTL或最大TTL策略。你在权威DNS设置TTL 60秒，不代表所有递归DNS都严格按60秒执行。部分网络环境里，缓存可能比预期长。

排查时要看权威DNS是否已经返回新值。如果权威DNS已经新值，递归DNS还旧值，并且还在TTL窗口内，那不是污染。超过TTL很久还旧值，才继续查递归缓存异常。

域名注册和NS状态也要查

有时候A记录没问题，权威DNS也没问题，但上层NS委派错了。比如注册商处NS还是旧服务商，控制台改的是新DNS平台，自然怎么查都不对。

可以查：

whois example.com

dig example.com NS

dig +trace example.com

如果whois里NS是 ns1.old-dns.com，而你实际在 ns1.new-dns.com 上改记录，那问题不在运营商，也不在递归DNS，是NS委派没切过去。

还有一种是域名过期、clientHold、serverHold。域名被注册商暂停解析后，递归DNS可能返回NXDOMAIN或SERVFAIL。这个现场也经常被误报成DNS污染。

排查时可以按这个判断路径走

遇到解析被污染的报障，现场可以按下面这个顺序查，速度会比较快。

确认用户实际拿到的错误结果：域名、记录类型、返回IP、TTL、网络环境、时间。

查询系统默认DNS，再指定公共DNS查询，判断是不是本地DNS或递归DNS差异。

查询权威DNS，确认服务商源头返回是否正确。

逐个查询所有权威NS，看是否存在权威节点不一致。

跨运营商、跨地区查询，判断异常范围是局部还是全局。

对比UDP、TCP、DoH结果，判断是否可能存在UDP 53链路干扰。

检查TTL和最近变更时间，排除正常缓存未过期。

检查NS委派、域名状态、DNSSEC状态、CDN或高防调度记录。

几个现场案例的判断方式

案例一：广东电信解析到陌生IP，其他网络正常

现象：用户反馈 example.com 打不开。广东电信宽带下 dig example.com 返回 198.51.100.23，页面是运营商提示页。广东移动、北京联通、香港服务器查询都返回 203.0.113.10。

继续查权威DNS：

dig @ns1.dns-provider.com example.com A 返回 203.0.113.10

dig @ns2.dns-provider.com example.com A 返回 203.0.113.10

再查广东电信下的公共DNS：

dig @223.5.5.5 example.com A 返回 203.0.113.10

dig @114.114.114.114 example.com A 返回 198.51.100.23

这个结果说明权威DNS没问题，异常集中在特定递归DNS或链路。处理方向是让用户临时切换DNS，同时把域名、错误IP、查询时间、递归DNS地址提交给运营商处理。

案例二：所有地区都有人解析到旧IP

现象：上午把业务从旧服务器 203.0.113.10 迁到新服务器 203.0.113.20，下午仍有用户访问旧服务器。国内外都有零散反馈。

查权威DNS已经是新IP：

dig @权威NS example.com A 返回 203.0.113.20，TTL 600

查部分递归DNS返回旧IP，但TTL还剩几百秒，且变更前原TTL是86400。

这种基本是缓存问题，不是污染。迁移前如果没有提前把TTL降下来，旧记录在递归DNS里存一天并不奇怪。处理方式是旧服务器不要立刻下线，至少保留到原TTL周期之后，或者在旧服务器上做反向代理、301、业务转发。

案例三：权威NS返回不一致

现象：同一个域名，有的用户解析到 203.0.113.10，有的解析到 203.0.113.20。查多个公共DNS结果也不一致。

逐个查权威NS：

dig @ns1.provider.net example.com A 返回 203.0.113.20

dig @ns2.provider.net example.com A 返回 203.0.113.10

dig @ns3.provider.net example.com A 返回 203.0.113.20

这就是权威DNS数据不同步或节点异常。递归DNS只是缓存了不同权威NS给出的结果。这个锅不该给运营商，应该找DNS服务商修权威节点数据。

案例四：DNSSEC导致部分DNS返回SERVFAIL

现象：8.8.8.8 查询SERVFAIL，部分国内DNS能解析。用户说海外被污染。

查DNSSEC发现DS记录还在父区，但权威DNS上的DNSKEY已经换过，校验失败。支持DNSSEC校验的递归DNS直接返回SERVFAIL，不校验的递归DNS还能返回A记录。

这种不是污染，是DNSSEC链断了。处理方式是修DS/DNSKEY，或者临时关闭DNSSEC并等待父区记录更新。

服务商和运营商责任边界怎么说清楚

给运营商或服务商提工单时，别只写“DNS污染了”。这样对方很难处理，也容易来回踢。

给运营商的证据最好包含：

异常用户所在地区和运营商

异常递归DNS地址

异常查询命令和返回结果

权威DNS正常返回结果

其他运营商或公共DNS正常结果

错误IP归属和访问截图

给DNS服务商的证据最好包含：

域名和记录类型

所有权威NS的逐个查询结果

不同地区访问同一权威NS的返回差异

控制台当前配置截图

最近变更时间和变更内容

是否开启DNSSEC、智能解析、CDN、高防调度

这样发工单，对方基本能直接进入排查，不会再反复问“请提供截图”“请提供本地网络环境”。

业务侧可以提前做的准备

DNS异常不可完全避免，尤其是跨地区、跨运营商、跨境访问的业务。业务侧能做的是降低故障影响。

重要域名的TTL不要长期设太大。需要频繁切换的业务，TTL可以设300或600秒；非常稳定的官网类解析可以设1800或3600秒。不要为了“解析快”长期设60秒，递归DNS未必严格遵守，还会增加权威DNS查询压力。

迁移服务器前，提前一天把TTL降下来。等旧TTL过完再切IP。切完后旧服务器保留一段时间，不要立刻关机。

源站、CDN、高防的CNAME链路要有文档。出了问题要知道 example.com 到底先指向哪个CNAME，CNAME再指向哪个平台，最终落到哪些IP。

监控不要只监HTTP状态，也要监DNS解析结果。至少从电信、联通、移动、香港、美国几个探测点查A记录和CNAME链。发现解析结果偏离预期时，先报警给运维，而不是等用户反馈。

如果业务部署在海外，但主要用户在国内，线路质量也会影响误判。DNS解析正常不代表访问正常，访问慢、丢包、绕路，有时候也会被用户描述成“解析错了”。需要三网访问稳定的海外业务，可以优先考虑三网精品、CN2、GIA、BGP优化线路。129云的美国精品网-C型适合企业站、API、跨境业务这类场景；香港大宽带-C型有300Mbps峰值带宽，适合需要香港入口和较大带宽的业务。

常用命令放在手边

查看默认解析结果

dig example.com A

nslookup example.com

指定递归DNS查询

dig @114.114.114.114 example.com A

dig @223.5.5.5 example.com A

dig @8.8.8.8 example.com A

dig @1.1.1.1 example.com A

查询权威NS

dig example.com NS

dig @ns1.provider.com example.com A

dig @ns2.provider.com example.com A

追踪解析链路

dig +trace example.com A

使用TCP查询

dig +tcp @8.8.8.8 example.com A

查看CNAME链

dig example.com CNAME

dig example.com A +short

查看TTL变化

dig @114.114.114.114 example.com A

等待30秒后再次执行同一条命令，对比TTL是否递减

最后处理时别反复改解析

DNS异常现场最怕边查边改。改一次解析，就引入一次新的TTL和缓存变量，原来的证据也会被冲掉。除非已经确认配置错误，否则先固定现场、拿查询结果、判断异常范围，再决定是否切换。

如果确认是服务商权威DNS异常，可以临时切到备用DNS托管，但要注意NS变更在父区也有缓存，不会立即全网生效。如果确认是运营商递归污染，让用户临时换DNS、走DoH、切备用域名，通常比反复改A记录更有效。

对线上业务来说，备用域名很有价值。主域名异常时，客户端、APP、游戏登录器、管理后台能不能切备用域名，直接决定恢复速度。备用域名最好不和主域名放在同一个DNS托管平台，也不要完全共用同一条CNAME链。

查DNS问题的时候，手里只要有权威DNS结果、递归DNS结果、跨网络结果、TTL变化，基本就能把责任边界拆清楚。剩下就是按证据找对应方处理，不要在“污染”这个词上来回绕。