DNS被污染之后，最快恢复业务的动作不是改解析

业务因为DNS污染中断时，很多人第一反应是去DNS控制台改A记录、改CNAME、切DNS服务商。这个动作不一定错，但它通常不是最快的。

原因很简单：DNS污染的麻烦点不在权威DNS有没有返回正确结果，而在用户侧递归DNS、运营商链路、Local DNS缓存、甚至中间路径已经把错误结果塞给用户了。你在权威DNS上改得再快，用户那边仍然可能拿到脏结果。

实际使用中发现，如果主域名已经被污染，最快恢复业务入口的方式通常是：启用备用域名，切到干净解析链路，再把后端服务挂到可用节点上。也就是说，不要在脏域名上硬救，先把业务入口换掉。

先判断是哪一层出问题，不要盲目操作

DNS异常大概分几类：权威DNS故障、递归DNS缓存错误、运营商DNS污染、域名被劫持、解析记录配置错误。它们表现都像“域名打不开”，但恢复动作完全不同。

现场排查可以很粗暴，但要快。拿几台不同网络的机器测同一个域名，比如本地宽带、移动网络、境外服务器、公共DNS、权威DNS直查。

常用命令：

dig yourdomain.com @8.8.8.8
dig yourdomain.com @1.1.1.1
dig yourdomain.com @223.5.5.5
dig yourdomain.com @114.114.114.114
dig yourdomain.com @ns1.yourdns.com

如果权威DNS查出来是正确IP，但国内多个Local DNS返回奇怪IP、空结果、127.0.0.1、0.0.0.0，或者返回了完全不属于自己的地址，基本可以按DNS污染处理。

这里补充一点：TTL在这种场景下经常救不了命。TTL能影响正常缓存刷新，但污染结果可能不是按你的TTL来的。线上故障时不要把希望押在“等TTL过期”。

最快恢复路径：备用域名加备用入口

主域名被污染后，最快恢复不是继续折腾主域名，而是让用户访问另一个没有被污染的域名。这个备用域名最好提前准备，证书、解析、回源、防护、监控都提前配好。

临时注册一个新域名也能救急，但速度会慢很多。注册、实名认证、DNS生效、证书签发、业务配置、前端替换、客户端热更新，任何一个环节卡住都会拖时间。

实际恢复时的顺序通常是这样：

备用域名已经存在：直接改入口配置，分钟级恢复。
备用域名没有解析：新增A记录或CNAME，等待生效，通常10到30分钟。
备用域名没有证书：签发证书、部署证书，可能拖到30分钟以上。
客户端只写死主域名：只能发版、热更新、配置中心兜底，时间不可控。

所以DNS污染的应急能力，不是故障发生时才开始建，而是平时就把备用入口养着。

Web业务怎么切

Web业务如果主域名打不开，302跳转基本没用，因为用户连主域名都解析不到。能用的是站外通知、App内公告、短信、邮件、客服入口、搜索广告、社群公告，把用户引导到备用域名。

备用域名要提前绑定站点，HTTPS证书也要提前部署。证书建议覆盖www、api、static等常用子域名，不要等故障时再发现某个资源域名没有证书，页面能打开但CSS、JS、图片全挂。

API业务怎么切

API比Web更麻烦，因为很多客户端把域名写死了。移动App如果没有远程配置，DNS污染会直接变成客户端不可控故障。

比较稳的做法是客户端内置多个API域名，启动时从配置中心拉取当前可用入口。配置中心本身也要有备用域名，甚至可以准备HTTPDNS或DoH通道。

如果客户端已经发出去了，且只写死一个域名，现场能做的事情很有限。能热更新就热更新，不能热更新只能引导用户升级，恢复速度取决于用户更新率。

服务端到服务端怎么切

服务端调用相对好处理。可以临时改hosts、改服务发现、改配置中心，把域名解析绕开。比如支付回调、游戏区服网关、登录鉴权、内部API，只要调用方机器可控，恢复会快很多。

但临时hosts不是长期方案。故障过后要把它清掉，否则后面迁移IP、扩容、切CDN时容易留下隐患。

直接用IP访问能不能救急

能，但只适合部分场景。

HTTP明文接口、内部系统、临时管理后台，用IP访问可以快速绕开DNS。HTTPS业务就会遇到证书和SNI问题。浏览器访问https://IP，大概率证书不匹配。API客户端如果校验证书，也会失败。

如果确实要走IP兜底，平时要准备好这几件事：证书支持对应访问方式、客户端支持备用IP、服务端SNI策略允许兜底、WAF或负载均衡允许IP入口访问。

多说一句，很多业务平时把“IP访问禁用”当成安全策略，这没问题。但如果完全没有应急白名单，故障时就少了一条路。比较好的方式是默认禁用，故障时通过安全组、WAF规则、源IP白名单临时打开。

切DNS服务商有没有用

有用，但不是所有DNS污染都能靠它恢复。

如果是原DNS服务商故障，切到另一个权威DNS服务商很有效。比如原来的NS不可用、控制台异常、解析记录下发失败，换NS或者启用备用DNS能恢复。

如果是运营商侧污染，权威DNS本身返回正确结果，切DNS服务商可能没有明显效果。用户请求还没走到你新的权威DNS，就已经在递归DNS层拿到错误结果了。

这里可以按场景看：

权威DNS故障：切DNS服务商，效果明显。
解析配置错误：修正记录，等待缓存刷新。
Local DNS污染：备用域名、HTTPDNS、DoH更快。
主域名被大范围污染：备用域名通常最快。
单地区运营商异常：按地区调度，避开异常线路。

备用入口放在哪里，影响恢复速度

备用域名只是入口，后面还要有可承载流量的服务器、带宽、防护和回源链路。很多故障恢复慢，不是因为没有域名，而是备用入口后面没有资源。

如果业务面向国内用户，但不想在污染期间继续依赖原入口，可以准备香港、新加坡、美国等节点做应急接入。香港节点延迟低，适合临时Web入口、下载页、API中转；新加坡适合东南亚用户；美国精品线路适合跨境业务或备用管理入口。

如果你也在找这种应急接入节点、海外云服务器、G口大带宽或高防服务器，可以看看129云。它的产品线里有香港大带宽-A型，300Mbps峰值带宽、1TB双向流量，适合临时承接Web入口、静态资源、下载分发；美国精品网-A型是三网精品线路，适合跨境访问和备用管理面；新加坡节点带宽30Mbps、流量200G到4TB，适合东南亚方向业务。需要按业务场景确认线路和防护，可以直接打客服热线400-9177118沟通。

注意，不要把备用节点做成“摆设”。至少要定期压测一次，确认Nginx、证书、回源、数据库白名单、安全组、监控都能跑。实际事故里经常见到备用服务器开着，但数据库不允许连接；备用域名解析好了，但证书过期；备用线路能访问，但带宽只有5Mbps，用户一来就打满。

CDN能不能解决DNS污染

CDN能降低一部分风险，但不能保证主域名被污染后一定可用。

CDN通常通过CNAME接入，用户仍然要先解析你的业务域名。如果业务域名本身被污染，CNAME还没机会发挥作用。CDN更适合解决源站隐藏、缓存加速、DDoS缓冲、跨地区调度，不要把它当成DNS污染的唯一解。

但备用域名接CDN很有价值。主域名异常时，备用域名直接CNAME到CDN，CDN再回源到源站或备用源站。这样可以快速把用户流量接住，而且不暴露真实源站IP。

HTTPDNS和DoH适合什么场景

HTTPDNS在移动App里比较常见。客户端不走系统Local DNS，而是通过HTTPS请求自己的解析服务，拿到IP后直连业务节点。这样可以绕开一部分Local DNS污染和劫持。

DoH也是类似思路，把DNS查询放到HTTPS里。浏览器、App、客户端工具都可以接入，但要看终端环境是否可控。

这类方案的关键问题是：解析服务本身也要能访问。如果HTTPDNS服务域名也被污染，那还是会挂。所以通常要准备多个解析服务入口，甚至内置少量IP作为兜底。

游戏、IM、直播、跨境电商App比较适合做HTTPDNS。纯Web站点面对普通浏览器用户，可控性弱，备用域名和多入口通知更直接。

提前准备的配置，故障时能省很多时间

DNS污染应急不是只看DNS控制台，真正影响恢复速度的是这些配置有没有提前准备：

备用主域名：至少准备一个不同后缀、不同注册商管理的域名。
备用子域名：api、www、static、download、admin这些入口提前建好。
证书：提前签发并部署，避免故障时临时申请。
备用DNS服务商：权威DNS不要只依赖一家。
短TTL：常用入口TTL控制在60到300秒，但不要迷信TTL。
备用云服务器：香港、新加坡、美国等节点至少保留一个可接入环境。
安全组白名单：源站、数据库、缓存、对象存储的访问规则提前配置。
客户端配置中心：App不要只写死一个域名。
监控探测：从不同运营商、不同地区探测解析结果和HTTP状态。

实际使用中发现，备用域名最好不要和主域名放在同一个DNS服务商、同一个账号、同一套自动化脚本里。账号被风控、服务商控制台异常、API限流时，备用入口也会一起受影响。

故障现场可以按这个顺序处理

发现业务大面积打不开时，先从外部网络确认解析结果，不要只看自己办公室网络。办公室DNS正常，不代表用户正常。

确认主域名被污染后，马上启用备用域名。Web业务切页面入口，API业务切配置中心，服务端调用改服务发现或临时hosts。并行检查备用节点的带宽、证书、回源和安全策略。

同时保留现场证据：不同DNS的dig结果、污染IP、影响地区、运营商、时间点、访问截图。这些信息后面要给域名注册商、DNS服务商、云厂商、安全团队排查用。

如果备用域名还没准备，只能临时走次优路线：注册或启用现有闲置域名，接入可用DNS，签发证书，绑定到云服务器或CDN，发布用户通知。这个过程正常会比预案慢很多。

对于企业内部系统，可以先让员工切VPN、改企业DNS、下发hosts或走堡垒机入口。对公网用户就不能指望用户手工改DNS，操作成本太高，投诉量也会很快上来。

污染恢复后，主域名不要马上切回去

主域名看起来恢复解析后，不建议立刻把全部流量切回。先做分地区、分运营商探测，确认污染结果是否还在局部缓存里。

可以用监控节点每分钟查询一次A记录和CNAME结果，至少覆盖电信、联通、移动、教育网、境外公共DNS。HTTP层也要测，不只测DNS。因为有时DNS恢复了，但中间链路仍然有缓存、拦截或证书异常。

切回时建议按流量比例来，先让小部分用户回主域名，观察错误率、连接耗时、TLS握手失败率、HTTP 5xx、业务登录成功率。不要只看服务器CPU和带宽，DNS污染类故障经常表现为“服务器很空，用户打不开”。

平时演练时重点测这些细节

演练不要只测“备用域名能不能打开首页”。要测真实业务链路。

登录能不能成功，支付回调能不能回来，图片上传是否正常，静态资源是不是还引用主域名，App配置是否能热更新，WebSocket是否连到了正确地址，管理后台白名单有没有放行，源站日志能不能区分备用域名流量。

还有一个容易忽略的地方：邮件、短信、第三方平台回调地址。很多业务把回调URL写在第三方控制台里，主域名污染后，即便用户侧切到备用域名，第三方仍然向旧域名回调，订单状态就会异常。

这类地址要么提前支持多回调入口，要么故障时有权限快速修改。权限别只在某个人账号里，真到凌晨故障，人联系不上会很难受。

最短恢复时间大概能做到什么水平

如果备用域名、证书、DNS、云服务器、CDN、配置中心都提前准备好，DNS污染后的可见业务恢复可以压到5到15分钟。这里的时间主要花在确认污染范围、切配置、验证业务链路、发布入口通知上。

如果只有备用域名但没部署证书和站点，大概需要20到60分钟，看证书签发、自动化部署和人员熟练度。

如果什么都没有，现场从注册域名开始救，时间就不可控。域名注册、实名认证、解析生效、证书签发、业务适配、用户通知，每一步都可能卡住。公网业务中断超过2小时并不稀奇。

DNS污染这种故障，真正快的恢复方式是绕过被污染的名字，把用户流量接到另一个已经验证过的入口上。主域名继续排查、申诉、清理缓存，但业务不要挂在它身上等。