DNS被污染了，别急着改解析，先把链路拆开看

DNS问题最麻烦的地方在于，表面现象都很像：域名打不开、解析到奇怪IP、部分地区访问正常、部分地区访问异常、换个DNS又好了。实际排查时不能只盯着控制台里的解析记录，因为用户拿到的结果不一定来自权威DNS，中间可能经过了本机缓存、运营商Local DNS、公共递归DNS、EDNS Client Subnet、DNS劫持设备，甚至还有应用自己的DNS缓存。

现场处理这类问题，一般先把“谁给了错误答案”找出来。不要一上来就把A记录删了重加，也不要马上切CDN。DNS链路拆开后，大概是这样：

客户端应用 → 系统DNS缓存 → 本地配置的Resolver → 运营商/公共递归DNS → 权威DNS → 返回结果 → 应用连接目标IP。

污染可能发生在任何一段。所谓“污染”，在排障里不要只理解成被解析到黑洞IP，有时候表现为NXDOMAIN，有时候是返回旧记录，有时候是只污染UDP 53，有时候TCP 53正常，有时候DoH正常但传统DNS异常。

先确认是不是DNS问题，而不是网络或应用问题

用IP直连把DNS从链路里拿掉

如果业务是HTTP/HTTPS，先拿到一个确认可用的源站IP或CDN节点IP，用curl指定Host测试。

命令可以这样看：curl -v --resolve example.com:443:1.2.3.4 https://example.com/

如果指定IP后访问正常，而直接访问域名异常，DNS嫌疑就很大。如果指定IP也不通，那就先别纠结DNS，去查路由、端口、防火墙、源站服务、SNI证书、WAF策略。

这里补充一点，HTTPS站点不要简单用浏览器访问IP判断，因为证书和SNI会影响结果。curl的--resolve比直接访问IP更接近真实业务请求。

看异常返回到底是什么类型

DNS异常不要只说“解析错了”，要记录具体返回。常见几种：

返回了陌生A记录：例如权威DNS配置是203.0.113.10，用户解析到198.51.100.8。这种更像递归DNS缓存异常、运营商污染、劫持或某个CDN调度异常。

返回NXDOMAIN：域名明明存在，但某些DNS说不存在。可能是递归DNS污染，也可能是权威DNS链路不可达后被错误缓存。

返回SERVFAIL：常见于DNSSEC、权威DNS不可达、递归DNS校验失败。

超时：可能是UDP 53被拦、权威DNS被打、递归DNS到权威的链路异常，也可能是本地网络策略问题。

TTL异常：权威设置TTL 60秒，但递归侧返回TTL 86400，这种要特别留意缓存污染或中间设备伪造响应。

从用户机器开始查，不要跳过本地缓存

本机DNS缓存经常背锅，也经常真有问题

实际使用中发现，很多“DNS污染”最后是在用户侧机器解决的。Windows有DNS Client缓存，macOS有mDNSResponder，Linux上可能有systemd-resolved、nscd、dnsmasq，容器里还可能走CoreDNS。

Windows查看缓存：ipconfig /displaydns

Windows清缓存：ipconfig /flushdns

macOS清缓存：sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux如果是systemd-resolved：resolvectl flush-caches，然后用resolvectl statistics看缓存情况。

如果清缓存后立刻恢复，说明问题可能不在本机缓存。如果清缓存后短时间正常，过一会又异常，要看本机使用的上游Resolver是谁，以及是否有代理软件、杀毒软件、网关DNS劫持。

确认机器实际用的是哪个DNS

不要只看网络面板里配置的DNS，很多环境会被VPN、代理、DHCP、容器网络改掉。

Linux看：cat /etc/resolv.conf，另外再看 resolvectl status。

Windows看：ipconfig /all。

macOS看：scutil --dns。

如果发现DNS指向192.168.1.1、10.x.x.x这类网关地址，真正发起递归查询的可能是路由器或企业网关，不是用户机器。这个时候在用户机器上dig出来的结果，只能说明“网关给了这个答案”，还不能说明公网递归DNS有问题。

用dig指定DNS，定位是哪个Resolver返回脏数据

同一个域名，对比多个递归DNS

排查时常用这种方式：

dig example.com A @223.5.5.5 +short

dig example.com A @119.29.29.29 +short

dig example.com A @8.8.8.8 +short

dig example.com A @1.1.1.1 +short

dig example.com A @114.114.114.114 +short

如果只有某一个Resolver返回异常，大概率是该递归DNS缓存或策略问题。如果国内多个运营商DNS都异常，而海外公共DNS正常，要考虑运营商链路污染、域名在部分区域被干扰、权威DNS到国内递归的链路异常。

对比时要加上完整输出，不要只看+short。完整输出里有SERVER、status、ANSWER SECTION、AUTHORITY SECTION、TTL，这些字段能帮你判断答案从哪来、是否走了缓存。

看TTL能判断是不是老缓存

比如权威DNS里A记录TTL是300秒，但某个递归DNS返回的TTL还有7200秒，说明它手里拿的不是当前权威记录，或者中间有非标准缓存。

如果TTL每查一次正常递减，说明这是一个缓存答案。如果TTL每次查询都重新变成固定大值，可能每次都被同一个设备伪造或改写。

多说一句，TTL不是绝对证据，但在排查污染时很好用。尤其是遇到“我已经改解析半小时了，用户还是访问旧IP”这种情况，TTL能快速判断是不是递归缓存还没过期。

直接问权威DNS，看源头有没有错

查NS记录，找到权威DNS

先看域名的权威NS：

dig example.com NS +short

然后直接指定权威DNS查询：

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

如果权威DNS返回就是错的，那问题在DNS服务商控制台、区域文件、解析记录、DNS服务商的同步节点上。这个时候没必要继续怀疑运营商。

如果权威DNS返回正确，但某些递归DNS返回错误，问题就在递归DNS到权威DNS之间，或者递归DNS自身缓存/策略。

用+trace看递归路径，但不要迷信它

dig example.com A +trace

+trace会从根开始一路查到权威，适合确认委派链路是否正常，比如根、TLD、NS是否能返回正确结果。

不过+trace是本机直接迭代查询，它不等于用户使用运营商Local DNS时的真实路径。它能证明权威链路是否通，不能证明某个运营商递归DNS没有污染。

判断污染发生在UDP 53还是更上游

UDP和TCP都查一遍

很多DNS污染只针对UDP 53，因为传统DNS默认走UDP。可以同一个Resolver查两次：

dig example.com A @8.8.8.8

dig example.com A @8.8.8.8 +tcp

如果UDP返回异常，TCP返回正常，说明中间链路对UDP 53做了干扰或注入。这个场景在跨境链路、公共DNS直连、某些企业出口里都见过。

如果UDP和TCP都异常，再看DoH/DoT结果。如果DoH正常，传统DNS异常，说明污染更可能发生在明文DNS链路。

抓包看是不是有两个DNS响应

在Linux上可以抓：

tcpdump -ni any port 53

污染注入比较典型的现象是：客户端发出一个DNS query，很快收到一个错误answer，随后又收到一个正确answer，但客户端已经采用了先到的那个错误answer。

这类问题肉眼看dig结果不一定看得出来，抓包能看到响应源IP、到达时间、Transaction ID是否一致、Answer内容是否异常。

如果错误响应的源IP伪装成你查询的DNS服务器，但TTL、MAC路径、到达延迟明显异常，就要怀疑链路中间注入。

按地域和运营商拆样本，别只用自己电脑测

同城正常不代表全国正常

DNS污染经常是区域性的。北京联通正常，不代表广州电信正常；移动正常，不代表教育网正常；国内正常，不代表海外用户正常。

建议至少覆盖这些维度：电信、联通、移动、海外节点、办公网络、手机4G/5G。业务如果面向跨境用户，还要测香港、日本、韩国、美国西海岸、欧洲。

这里如果自己没有足够多节点，可以用云服务器做探针。比如需要韩国回国优化线路，可以看129云的韩国 B型，带傲盾防火墙和精品线路，适合放一个轻量探测脚本；如果要美国方向跑大流量压测或DNS监控，美国精品大宽带-E型有1Gbps峰值和三网精品线路；欧洲侧只做解析探测、业务可达性监控，德国双ISP-特惠这种小规格机器就够用。选节点时不要只看CPU，DNS排查更看网络位置、运营商路径和是否方便长期留探针。需要确认线路也可以直接打客服热线400-9177118问。

记录样本时要带上Resolver和出口IP

不要让用户只发一句“打不开”。至少要拿到这些信息：

用户所在地区和运营商，例如上海电信、深圳移动、北京联通。

用户实际DNS服务器，例如192.168.1.1、223.5.5.5、运营商下发DNS。

dig完整输出，包含status、ANSWER、TTL、SERVER。

用户出口IP，可以访问 ifconfig.me 或 ipinfo.io 看。

访问目标域名解析到的IP。

如果有条件，再加一份mtr到解析出来的IP。因为有时候用户说DNS错了，其实DNS解析到了正确IP，只是那条路由被DDoS清洗、BGP绕路或防火墙策略影响。

CDN场景要特别看ECS和调度结果

同一个域名解析到不同IP不一定是污染

CDN和Anycast DNS环境里，不同地区解析到不同IP很正常。比如上海电信拿到华东节点，北京联通拿到华北节点，海外拿到新加坡或洛杉矶节点，这不是污染。

判断是否异常，要看解析结果是不是属于CDN厂商节点、是否在预期调度范围、访问是否命中正确证书和Host。

可以用whois、IP归属库、CDN控制台节点信息对比。不要看到IP不同就直接判定DNS被污染。

EDNS Client Subnet会影响结果

很多公共DNS支持ECS，也就是递归DNS会把客户端网段信息带给权威DNS或CDN调度系统。这样同样查询8.8.8.8，不同用户可能得到不同结果。

排查时可以用支持subnet参数的dig版本：

dig example.com A @8.8.8.8 +subnet=1.2.3.0/24

用不同subnet模拟不同地区用户，看CDN调度是否符合预期。

如果不带ECS时正常，带某个地区subnet时返回异常，就要查CDN调度规则、区域封禁、节点健康状态，而不是只盯着DNS污染。

权威DNS也可能是“某个节点”坏了

DNS服务商的多个NS节点结果不一致

权威DNS通常有多个NS，例如ns1、ns2、ns3。如果其中一个节点同步失败，就会出现部分递归DNS拿到新记录，部分递归DNS拿到旧记录。

可以逐个查：

dig @ns1.dnsprovider.com example.com A

dig @ns2.dnsprovider.com example.com A

dig @ns3.dnsprovider.com example.com A

如果ns1返回新IP，ns2返回旧IP，问题就很明确了：权威DNS集群同步不一致。

这个场景在刚迁移DNS服务商、刚改NS、刚批量导入记录时比较常见。尤其是域名注册商处的NS变更，还会叠加TLD缓存时间，看起来像污染，实际上是委派链路还没完全切干净。

Glue记录错误会让问题变得很隐蔽

如果权威NS使用的是域名自身的子域，例如ns1.example.com，那么注册局里会有Glue记录。Glue记录错了，递归DNS可能连权威DNS都找错地方。

查Glue可以看：

dig example.com NS +trace

关注TLD返回的NS和对应A记录是否正确。

如果TLD层返回的ns1.example.com地址还是旧IP，而你只在自己的DNS控制台改了ns1.example.com的A记录，递归DNS可能仍然去旧的权威服务器查。这种问题很容易被误判成运营商污染。

把“哪个节点出问题”缩小到具体层级

本机层

现象：同一网络下其他设备正常，只有某台机器异常；清DNS缓存后恢复；浏览器和命令行结果不一致。

重点查：系统DNS缓存、浏览器DNS缓存、代理软件、VPN、hosts文件、杀毒软件、容器内部DNS。

Chrome可以看 chrome://net-internals/#dns，部分新版本入口变了，但浏览器确实有自己的DNS和Socket缓存。hosts文件也别忘了，Windows在 C:\Windows\System32\drivers\etc\hosts，Linux/macOS在 /etc/hosts。

网关层

现象：同一个办公室、同一个Wi-Fi下都异常，换手机流量正常；机器配置的DNS是路由器IP。

重点查：路由器DNS代理、企业网关策略、旁路安全设备、DHCP下发的DNS、透明DNS劫持。

可以在客户端直接指定公共DNS测试。如果指定8.8.8.8仍然返回网关伪造结果，说明网络里可能有透明代理或DNS重定向。

递归DNS层

现象：指定某个Resolver异常，换Resolver正常；TTL异常；同一Resolver在不同地区返回不同结果。

重点查：递归DNS缓存、运营商Local DNS、公共DNS策略、ECS、DNSSEC校验。

这个时候可以临时建议用户切换到可信Resolver，或者业务侧接入稳定的权威DNS/CDN调度。但长期处理还是要确认污染来源，尤其是企业业务不能只靠“让用户换DNS”解决。

权威DNS层

现象：直接查权威NS返回错误；多个权威NS结果不一致；+trace链路里NS或Glue异常。

重点查：解析记录、线路解析策略、NS同步状态、域名注册商NS配置、DNSSEC DS记录、Glue记录。

DNSSEC引起的SERVFAIL也不少见。比如权威侧换了DNS服务商，但注册商那里DS记录没删，递归DNS校验失败，就会直接SERVFAIL。普通用户看起来就是打不开。

链路注入层

现象：UDP 53异常，TCP 53或DoH正常；抓包看到多个响应；错误响应延迟极低；只有特定跨境路径异常。

重点查：运营商链路、国际出口、企业安全设备、透明DNS代理。

这种问题业务侧很难直接“修复”链路，只能绕开明文DNS，比如客户端支持DoH/DoT，或者通过应用内置解析、私有DNS、就近探测节点做容灾。网站类业务则要配合CDN、备用域名、合理TTL来降低影响。

现场排查时常用的命令组合

查当前Resolver返回

dig example.com A

看SERVER字段，确认到底是谁回答的。

指定公共DNS对比

dig example.com A @223.5.5.5

dig example.com A @119.29.29.29

dig example.com A @8.8.8.8

dig example.com A @1.1.1.1

直接查权威DNS

dig example.com NS +short

dig @权威NS example.com A

查委派链路

dig example.com A +trace

查TCP DNS

dig example.com A @8.8.8.8 +tcp

抓DNS包

tcpdump -ni any udp port 53

tcpdump -ni any port 53

验证业务访问

curl -v https://example.com/

curl -v --resolve example.com:443:1.2.3.4 https://example.com/

一个真实排查思路的还原

现象

某业务域名在华南部分用户访问异常，用户反馈浏览器提示连接超时。运维控制台看到A记录没问题，CDN也显示节点正常。华东办公室访问正常，海外监控正常。

先把访问和解析拆开

让用户执行dig，发现域名解析到了一个不属于业务CDN的IP。TTL为3600，而权威DNS里这个记录TTL实际是120。

同一用户机器指定223.5.5.5，返回正确；指定本地运营商DNS，返回异常。用户DNS来自路由器DHCP，路由器上游是当地运营商Local DNS。

这个时候问题已经缩到运营商Local DNS或其上游缓存。

继续确认不是CDN调度

从华南移动、华南电信、华南联通三台探针分别查询。只有华南电信某两个城市异常，移动和联通正常。直接查权威NS全部正确，多个NS返回一致。

再用+tcp查询异常运营商DNS，TCP返回正确，UDP返回错误。抓包能看到两个响应，错误响应先到，正确响应后到。

结论不是权威DNS错，也不是CDN调度错，而是这段网络里的UDP 53响应被注入或污染。

处理动作

短期让受影响客户改用可信DNS或DoH，业务侧把TTL维持在120，避免后续调度切换时扩大影响。同时把异常样本整理给DNS服务商和运营商，包括时间、地区、出口IP、Resolver、错误答案、抓包截图。

业务如果有客户端，可以内置DoH或备用解析通道。纯Web业务可以准备备用域名，并确保备用域名不和主域名使用完全相同的NS与解析链路。

容易误判的场景

解析到旧IP不一定是污染

如果刚改过解析，递归DNS缓存没过期，用户拿到旧IP很正常。先看旧记录原来的TTL是多少。以前设置过86400，就别指望5分钟全球生效。

解析到国外IP不一定是污染

CDN调度、Anycast、海外线路回源、GIA/CN2优化线路都可能让用户拿到不同地域IP。要结合IP归属、CDN厂商、访问质量判断。

公共DNS正常不代表运营商DNS正常

很多排查只测8.8.8.8和1.1.1.1，结果得出“DNS没问题”。但真实用户可能用的是运营商DHCP下发的Local DNS。面向国内用户的业务，必须测运营商DNS。

权威DNS正常不代表用户侧正常

权威DNS只是源头。递归DNS缓存、中间链路、透明代理都可能改写结果。直接查权威正确，只能说明源头没错。

ping域名结果不能直接当DNS结论

ping会触发系统解析，但它还受ICMP策略影响。有的服务器禁ping，有的CDN节点丢ICMP，有的本地安全软件拦截。DNS排查还是用dig、nslookup、drill这类工具更干净。

排查记录建议直接写成证据链

不要只贴一张截图

给运营商、DNS服务商、CDN厂商提交问题时，信息越完整，定位越快。建议按这个格式记录：

时间：2026-xx-xx 14:23:10 GMT+8

用户地区和运营商：广州电信

用户出口IP：x.x.x.x

查询域名：example.com

使用Resolver：202.x.x.x

异常返回：198.51.100.8，TTL 3600

权威DNS返回：203.0.113.10，TTL 120

公共DNS对比：223.5.5.5正常，119.29.29.29正常，8.8.8.8正常

UDP/TCP对比：UDP异常，TCP正常

抓包现象：同一Transaction ID收到两个answer，错误answer先到

有这些证据，对方才好判断是缓存问题、调度问题、链路注入，还是某个节点同步异常。

业务侧能提前做的防护

TTL别长期设太大

核心业务域名TTL建议保持在60到300秒之间。不是越低越好，太低会增加权威DNS压力，也可能被部分递归DNS强制调整；但TTL设到86400，出问题时切换会很难受。

权威DNS要有多节点和监控

至少监控每个NS节点返回是否一致。不要只监控“域名能不能解析”，要监控“每个权威NS返回的答案是否符合预期”。

关键业务准备备用域名

备用域名不要和主域名完全复用同一条DNS链路。否则主域名污染时，备用域名可能也一起受影响。备用域名的证书、回源、WAF、CDN配置要提前验证，别等故障时才发现证书没签或Host没放行。

客户端业务可以考虑DoH

App、游戏启动器、企业客户端这类可控环境，可以引入DoH作为备用解析通道。传统UDP 53异常时，走HTTPS解析能绕开一部分链路污染。

但DoH也要注意可用性和合规要求，不要把所有解析都硬编码到单一服务。服务不可用时要有降级路径。

监控节点要覆盖真实用户网络

DNS监控只放在云厂商同一个Region意义不大。真实用户在电信、联通、移动、海外住宅宽带、企业出口。监控节点越贴近用户，越容易提前发现污染和调度异常。

如果业务有游戏、高防、海外访问场景，选择服务器时可以顺手把探针能力考虑进去。像129云这类提供高防服务器、G口大带宽服务器、海外云计算线路的服务商，适合把业务节点和监控节点一起规划，尤其是韩国、美国、德国这些常用方向，既能看解析，也能看BGP路径、回国延迟和丢包。

排到最后，定位结果通常会落在这些位置

本机或浏览器缓存

清缓存恢复，换设备正常。处理本机缓存、hosts、代理、浏览器DNS缓存。

企业网关或路由器DNS代理

同一局域网都异常，换网络正常。查DHCP、网关DNS代理、透明DNS策略。

运营商Local DNS缓存污染

指定运营商DNS异常，公共DNS正常。收集样本提交运营商，同时给用户临时切换DNS。

明文DNS链路注入

UDP异常，TCP或DoH正常，抓包看到抢答。客户端侧可启用DoH/DoT，业务侧准备备用解析策略。

权威DNS同步异常

不同NS返回不一致。联系DNS服务商处理节点同步，必要时临时切换权威DNS。

域名委派或Glue错误

+trace里TLD返回异常NS或旧Glue。到注册商处修正NS/Glue记录，等待上层缓存刷新。

CDN调度异常

权威返回的确是CDN给出的结果，但某区域调到了不可用节点。查CDN区域策略、节点健康、ECS、回源状态。

DNS污染排查不要靠猜。把客户端、Resolver、权威DNS、传输协议、地域运营商逐层拆开，错误答案从哪一层开始出现，问题节点就在那里。