DNS分地区解析配错了会造成什么后果，怎么快速回滚

DNS分地区解析看起来只是把不同地区用户解析到不同IP，实际出问题时影响会很直接。国内用户被解析到美国节点，香港用户被解析到大陆源站，海外用户被解析到防火墙没放行的高防IP，这类事故在云上并不少见。

实际使用中发现，DNS分地区解析最容易被低估的地方不是“解析错了”，而是“错了以后缓存还在”。权威DNS上改回来了，不代表用户马上恢复。递归DNS、运营商Local DNS、浏览器、系统DNS缓存、App内置DNS缓存都会延迟恢复，TTL只是一个参考值，不是强制命令。

分地区解析配错后，最常见的影响

延迟突然升高是最容易观察到的。比如原本华南用户解析到香港CN2或精品线路节点，RTT在20ms到40ms之间，误配到美国西海岸后，RTT可能变成160ms到220ms。网页还能打开，但接口耗时会明显变长，游戏、支付、登录这类链路会被用户直接感知。

更麻烦的是跨区流量被打到错误线路上。原本海外用户走美国精品网，国内用户走香港或国内加速入口，结果华东、华南用户被解析到普通海外线路，丢包在高峰期从0.5%上升到5%甚至更高。看监控会发现源站CPU没满、带宽没满，但业务端就是慢，这时很容易误判成应用问题。

如果节点之间的安全策略不同，还会出现部分地区完全不可用。比如A地区IP只允许CDN回源，B地区IP只开放办公网，GeoDNS策略写反后，公网用户解析到不该暴露的入口，轻则403、502，重则TCP连接直接超时。

多说一句，DNS分地区解析配错还可能把DDoS流量引到普通节点上。原本攻击区域应该解析到高防清洗入口，误配后打到普通云服务器，带宽瞬间打满，连带同机房同段业务都受影响。这里不是DNS本身抗不抗攻击的问题，而是调度入口错了。

一个真实场景拆开看

某业务域名使用GeoDNS：华东、华南走香港节点，北方走BGP优化入口，海外走美国节点。变更时把“默认线路”指向了美国IP，又漏配了部分运营商线路，结果大量国内Local DNS没有命中精细规则，全部掉到默认线路。

变更前：华南用户解析香港IP，平均RTT 28ms，接口P95 180ms。变更后：华南用户解析美国IP，平均RTT 185ms，接口P95 900ms以上。客服收到的反馈不是“DNS错了”，而是“登录慢”“图片加载不出来”“支付一直转圈”。

排查时如果只看源站监控，会看到美国节点流量突然上涨，香港节点流量下跌。Nginx日志里国内IP比例异常升高，TCP重传率上升。这个特征基本可以把问题锁定到调度层，尤其是最近刚改过DNS策略时。

快速判断是不是DNS分区策略的问题

不要只用本机dig一次就下结论。本机解析结果通常只代表当前网络和当前递归DNS。需要从不同地区、不同运营商、不同递归DNS同时查。常用方式是：本地dig、指定公共DNS查、云监控探测点查、线上日志反查客户端来源和命中的服务IP。

可以直接看这类命令输出：dig example.com @114.114.114.114、dig example.com @223.5.5.5、dig example.com @8.8.8.8。国内运营商Local DNS有时会带EDNS Client Subnet，有时不会带，GeoDNS平台根据来源判断地区时就可能出现偏差。

这里补充一点，很多DNS平台里的“中国大陆”“华东”“电信”“默认”不是同一个维度。默认线路经常承接所有没命中的请求，所以默认线路不能随便指向测试IP，更不能指向只给海外用户使用的节点。

回滚前先做止血，不要急着反复改

事故现场最怕连续点保存。DNS不是配置中心，连续改三次不会让全网马上变成第三次结果，反而会让缓存状态更乱。正确动作是先冻结变更，把当前权威DNS记录导出或截图，确认哪些线路被改过、哪些记录还在缓存期内。

如果错配IP还能访问，先临时把安全组、WAF、Nginx、回源白名单补齐，让被错误解析过去的用户至少能打开业务。比如国内用户已经缓存到美国IP，权威DNS改回香港也需要等待缓存过期，这段时间美国节点要临时具备服务能力。

如果错配IP不能承载业务，可以在错误节点上做临时反向代理，把流量转回正确源站。Nginx proxy_pass、四层转发、云负载均衡都能用。这个动作的价值是绕开DNS缓存等待期，先把用户请求接住。

权威DNS侧的快速回滚动作

回滚时优先恢复最近一次稳定版本，不要凭记忆手工重填。成熟一点的做法是DNS记录变更前导出zone文件，或者在平台里保留变更历史。没有历史记录时，只能从监控、日志、旧截图、工单记录里拼。

TTL如果原来是60秒，回滚会比较轻松；如果原来是600秒、1800秒甚至更高，就要接受缓存残留。权威DNS改回正确值后，继续保留错误IP上的临时代理或服务，至少覆盖一个到两个TTL周期。实际运营商缓存不一定严格遵守TTL，保守一点可以观察30分钟到2小时。

如果使用CNAME分层，比如业务域名CNAME到调度域名，调度域名再A记录到节点IP，回滚会更清晰。把业务入口层保持不动，只回滚调度层记录。大型业务里不建议把所有地区规则直接堆在主域名上，回滚和审计都麻烦。

缓存没过期时的处理方式

DNS回滚后用户仍然访问旧IP，这不是回滚失败，而是缓存还没消失。这个阶段要靠业务侧兜住旧IP流量。常见动作包括：旧IP继续保留服务、错误节点临时代理到正确节点、负载均衡后端临时加入正确源站、CDN或WAF入口放行错误地区流量。

如果误解析到了完全不可控的IP，比如已经释放的云主机IP，处理难度会高很多。能做的是立即重新购回同IP或联系云厂商冻结资源，购不回就只能等缓存过期，同时在App、页面、客户端侧尽量触发重试或切换备用域名。

这里也能看出备用域名的价值。主域名DNS缓存卡住时，客户端如果支持api-bak.example.com这种备用入口，可以通过配置中心或客户端策略切到备用域名。Web站点也可以通过CDN规则、页面资源降级缓解一部分影响。

线路选择不清晰，也会放大回滚成本

分地区解析不是只填IP，还要知道每个IP背后的网络质量和承载能力。香港节点适合低延迟回国，美国节点适合海外用户或跨境业务，高防节点适合攻击流量入口。把这些节点混着用，平时看不出问题，事故时就会发现每个IP都不能随便接流量。

如果业务需要香港低延迟入口、海外稳定回国线路、临时承接流量的备用节点，可以看看129云。比如香港大宽带-D型提供300Mbps峰值带宽，适合图片、下载、活动页这类突发流量；美国精品网-E型走CMIN2，高速回国，适合海外节点承接国内访问；香港多IP站群-B型偏SEO和多IP场景，适合对IP资源有要求的站点。选型时可以直接按业务入口、备用入口、清洗入口分开规划，客服热线400-9177118可以确认线路和带宽细节。

变更前把回滚路径写清楚

DNS变更前最有价值的准备不是审批截图，而是回滚路径。要明确旧记录是什么、TTL是多少、哪些地区受影响、哪些节点能临时接管、旧IP是否保留、监控从哪里看。

TTL建议在计划变更前提前降。比如原来TTL是600秒，准备做GeoDNS调整，可以提前一天降到60秒或120秒。变更稳定后再拉回300秒或600秒。不要在变更同时才改TTL，因为旧TTL已经被递归DNS缓存了。

默认线路要指向最稳的入口，而不是测试入口。很多事故都是精细线路没命中后掉到默认线路，默认线路又没有业务能力。默认线路最好选择能覆盖最大用户群、带宽和安全策略都相对稳的节点。

监控要看解析结果，也要看真实流量

DNS平台显示配置正确，不代表用户侧解析正确。监控需要覆盖两层：解析监控和业务监控。解析监控负责从多地区、多运营商查询域名返回值；业务监控负责看各节点QPS、带宽、状态码、RTT、错误率。

一个比较明显的异常信号是地域流量比例突变。比如香港节点平时承接国内70%流量，突然降到20%；美国节点平时承接海外流量，突然国内IP占比升到60%。这种变化比单纯看CPU更快发现问题。

日志里也要保留Host、client IP、upstream、server IP、X-Forwarded-For等字段。出问题时可以直接按server IP聚合，看哪些地区用户打到了错误节点。没有这些字段，排查会变成猜。

常见误配来源

运营商线路和地域线路混用是高频问题。比如配置了“华东电信”，但没有配置“华东联通”和“华东移动”，结果联通、移动掉到默认线路。还有平台把“境外”排除在“中国大陆”之外，默认线路如果没处理好，海外用户会被带到不该去的地方。

另一个来源是复制规则时忘记改IP。测试域名验证通过后，把规则复制到生产域名，但其中某条地区记录仍然指向测试机。因为只影响特定地区，监控覆盖不足时会拖很久才发现。

还有一种是CDN、DNS、源站同时变更。CDN回源域名改了，DNS地区策略也改了，源站安全组又收紧了。出问题时三层都可能有锅，回滚也不知道该先动哪一层。生产环境里这类联动变更要拆开做，至少要留出观察窗口。

回滚后的清理动作

回滚稳定后，不要立刻释放错误节点或删掉临时代理。先看各地区解析结果是否回到预期，再看旧IP流量是否明显下降。旧IP连续多个TTL周期没有有效请求后，再逐步下线临时配置。

DNS平台里的临时规则要标注清楚。事故中加的“临时默认线路”“临时海外代理”“临时TTL 60”如果没人清理，过几周又会变成新的风险。变更记录里写清楚时间、原因、影响域名、回滚人、验证结果，比事后口头同步可靠。

如果业务对延迟敏感，建议把DNS分地区解析和链路压测一起做。国内访问香港CN2、GIA、CMIN2，美国访问美国本地，东南亚访问香港或新加坡，不同线路实际表现差异很大。只看IP能ping通不够，要看高峰期RTT、丢包、P95接口耗时和回源稳定性。

直接可用的应急顺序

发现异常后，先暂停DNS继续变更，保留现场配置；同时从多地区dig确认解析结果，和业务节点流量对比。确认是分地区解析误配后，立刻恢复上一个稳定版本的DNS记录，TTL维持低值，不要来回改。

接着处理缓存残留：错误IP能控就补服务、补安全组、补反代；错误IP不能控就尝试购回或联系云厂商处理，并准备备用域名或客户端切换。监控上重点看错误节点流量是否下降、正确节点流量是否恢复、核心接口P95是否回落。

等旧解析流量自然衰减后，再撤临时代理和放行策略。DNS这类问题，真正的恢复时间不是权威DNS保存成功的那一秒，而是用户侧缓存、运营商递归DNS、业务兜底全部回到可控状态的那一刻。