2021年10月4日，Facebook全球瘫痪近6小时；两个月前，Akamai的一次DNS配置更新让PlayStation、UPS、Airbnb同时失联；再往前一年，T-Mobile一条光纤闪断12分钟，却引发注册风暴，全美语音瘫痪超过12小时，FCC报告显示至少41%的呼叫未完成。这三个事故背后有一个共同的影子：DNS——这个平时没人多看一眼的基础件，一旦倒下，最先死的往往不是网页，而是语音。本文从FCC官方故障报告和Cloudflare复盘出发，拆解运营商核心网对DNS的隐性依赖、四个最阴的经典故障模式，以及一套可落地的监控与演练方案，回答一个问题：为什么你排障三天查不出根因，最后发现凶手是一台DNS。
2021年10月4日15:40（UTC），Cloudflare的全球BGP监测系统捕捉到一串异常密集的路由撤销——来自Facebook的AS32934。8分钟后，1.1.1.1解析器开始对facebook.com、whatsapp.com返回SERVFAIL。Cloudflare工程师第一时间开的内部工单名字很有戏剧性：“Facebook DNS lookup returning SERVFAIL”——他们一度以为是自己的解析器出了问题。
真实的故障链条是：Facebook内部骨干网的一次配置变更引发级联故障，BGP路由被全部撤销，其中就包括承载其权威DNS服务器的前缀（129.134.30.0/23和185.89.218.0/23）。路由没了，全世界的解析器都连不上Facebook的DNS服务器，域名解不出来，服务自然全灭。facebook.com的解析从15:50中断，直到21:20才恢复——整整5个半小时。Facebook官方事后披露，更尴尬的是：由于DNS服务器与数据中心深度绑定，数据中心被禁用，连工程师回公司刷卡开门都失灵了，一批人站在自己机房门口进不去。
两个月前的7月22日15:45（UTC），CDN巨头Akamai的一套软件配置更新触发了Edge DNS组件的bug，PlayStation Network、UPS、Home Depot、Airbnb、HBO Max等一大批看似毫无关联的服务同时失联，最长持续约1小时。Akamai回滚配置后恢复，并明确声明这不是网络攻击。Cisco Umbrella事后分享的复盘里有个细节：他们的SmartCache功能靠缓存旧解析结果兜底，客户在故障期间几乎无感——这从反面证明，DNS层面的冗余设计是有用的。
这两场事故都是互联网侧的故事。但对运营商的工程师来说，看完只会后背发凉——因为在电信网内部，DNS的戏份比互联网更重，而且更隐蔽。
很多人对DNS的认知停留在“上网用的”。但按3GPP规范（TS 23.003定义的S-NAPTR解析流程），EPC和IMS核心网里有一大票关键业务，每次呼叫、每次attach都在默默查DNS。下面这张表是笔者按18年核心网运维经验整理的依赖清单：
| 网元/业务 | 用DNS做什么 | 关键记录类型 | DNS挂了之后的表现 |
|---|---|---|---|
| S-GW/P-GW | APN解析出PGW/SGW的FQDN与IP（S-NAPTR流程） | NAPTR/SRV/A | 新用户无法建立PDN连接，老用户靠缓存撑着 |
| MME | 跨MME的S10选择、TA-LI映射查询 | NAPTR/A | TAU、切换、寻呼出现区域性异常 |
| IMS终端 | P-CSCF地址发现 | DHCP+DNS/A/SRV | VoLTE/VoNR注册直接失败，电话打不出去 |
| S-CSCF/IRAT网元 | 用户注册后定位业务侧节点 | NAPTR/SRV/A | 注册成功率下降，呼叫时延飙升 |
| ENUM网关 | E.164号码反查SIP URI（RFC 6116） | NAPTR | 号码路由错误或呼叫失败，且是“部分号码”失败，极难察觉 |
| 计费/网管后台 | CG、EM、文件服务器的域名解析 | A/AAAA | 话单堆积、告警风暴——注意，用户业务可能完全正常 |
最后两行是最要命的。ENUM出问题不是全网打不通，而是某些号段打不通——比如某省运营商曾经出现的“打座机正常、打手机奇慢”，查了三天无线参数，最后发现是ENUM的NAPTR链里有一环指向了一个早已下线的测试系统。这种“部分失败”模式是DNS类故障的典型特征，也是它阴险的地方：你的话统看不出全网性劣化，投诉量增长缓慢，等到发现时已经烧了一周的口碑。
还有一层认知误区要打破：核心网里很多DNS查询有缓存兜底，所以DNS坏了不会立刻表现为“全挂”，而是表现为“变慢”“时好时坏”“新注册的用户不行”。这种灰度故障在NOC的告警台上几乎不显眼——没有红色告警，只有一堆黄的和灰的，混在每天上万的告警里。等你意识到是DNS，往往是被更资深的工程师一句“先看看解析链路”点醒的。
如果说Facebook和Akamai证明了DNS是互联网的软肋，那么FCC这份2020年10月22日发布的官方故障报告，则完整解剖了电信网版本的灾难。这份报告的可贵之处在于：FCC拿到了T-Mobile的机密呼叫成功率和分代呼叫失败数据，是极少数有官方数据的全国性语音瘫痪案例。
| 时间（2020年） | 事件 |
|---|---|
| 6月15日中午前后（美东） | 东南部一条租用光纤链路故障，持续仅约12分钟 |
| 故障发生时 | 同区域一台新装机路由器配置不完整，备用路径无法正确承载信令 |
| 随后数分钟 | 亚特兰大市场开始出现"注册风暴"，终端反复注册失败 |
| 数小时内 | 风暴随终端漫游扩散，蔓延出亚特兰大市场，波及全国 |
| 当天白天至傍晚 | 终端依次尝试4G、3G、2G注册，最后转WiFi通话，继续失败 |
| 当天深夜（12小时以上后） | 服务逐步恢复 |
| 10月22日 | FCC发布网络故障报告，估算影响并给出整改建议 |
flowchart TD
A["光纤链路闪断12分钟"] --> B["备用路径路由配置不全"]
B --> C["信令无法走通备份路由"]
C --> D["亚特兰大注册风暴"]
D --> E["IMS核心网信令拥塞"]
E --> F["4G注册大面积失败"]
F --> G["终端自动降级3G和2G"]
G --> H["老旧网络被拖垮"]
H --> I["全国语音中断12小时以上"]
关键在于第三步之后：光纤12分钟就恢复了，但注册风暴没有停。数百万终端在持续重试注册，信令量远超正常水位，IMS核心网被自己的用户打死。FCC估算，故障期间至少41%的呼叫未完成——而且报告明确说，这个数字还不包括VoLTE和VoWiFi的失败呼叫，如果算上会“大得多”。紧急呼叫方面，因为911设计上绕过注册流程，受影响相对小，但T-Mobile自报仍有24,000通911呼叫失败。
严格说，T-Mobile这起事故的直接导火索不是DNS，而是路由+软件缺陷的复合故障。但它对本文主题的启示恰恰在这里：故障的传播载体是“注册-解析-路由”这条信令链。终端每一次注册失败后的重试，都伴随着一轮完整的网络选择与解析流程；当解析和路由基础设施处于亚健康状态时，重试风暴会把这些平时被缓存的“隐藏依赖”全部暴露出来。FCC报告给行业的整改建议里，除了路由变更的灰度验证、软件缺陷的潜伏期检测，反复强调的一个词是complexity——网络的隐性依赖越叠越多，任何单一故障的爆炸半径都在指数级放大。
这个逻辑对国内运营商同样成立。你现网里那些“从没人动过、从没人看过”的DNS服务器、ENUM数据、GTP对端静态配置，就是FCC说的隐性依赖。它们不出事的时候，没人记得它们存在。
下面这四个坑，来自笔者和同行这些年踩过或见过的真实场景（具体运营商信息隐去，机制以3GPP和RFC公开规范为准）。它们的共同点：现象离根因十万八千里，告警台上几乎无声。
DNS响应超过约512字节（EDNS0下常见上限1232字节）会被置TC标志截断，客户端自动转TCP 53重试。问题在于：很多核心网机房的防火墙策略是“放行UDP 53，没考虑TCP 53”。平时查询短、响应小，一切正常；一旦某条NAPTR链变长、或者上了DNSSEC、或者运营商把ENUM数据从十几个号段扩到几百个，响应一变大，TCP fallback全被丢弃。现象是“大查询失败、小查询正常”，比如某类特定业务（恰好查询链长的）注册失败率高，其他都好。排障时dig默认UDP测试正常，必须用dig +tcp复现。
IMS割接最经典的事故形态：网元IP换了，配置文件全改了，验证通过，割接结束。凌晨三点，第一批话务进来——一部分呼叫打到旧地址去了。原因：PDN网关或S-CSCF缓存里的旧记录TTL还没过期。反过来，TTL设太短，缓存穿透，每次呼叫都去查权威，权威一抖，呼叫建立时延跟着抖。经验基线：核心网内部域名TTL控制在分钟级——长到能扛住权威侧闪断，短到割接窗口内能自然收敛。割接单里必须有一项：割接后主动刷新缓存或等待TTL过期再放话务，这一条写不进割接单的割接，都是赌博。
Linux的resolver在首选DNS服务器无响应时会等超时再试下一个，一轮超时常见就是5秒量级。对网页浏览，用户感知是“慢一点”；对呼叫建立，5秒意味着用户已经把手机从耳边拿下来了。这类故障的诡异之处在于：业务没失败，只是慢——话统里接通率正常，但呼叫建立时延KPI悄悄劣化。往往是一个DNS服务器的网卡半瘫（丢包但不完全断），监控ping通、端口探测通，唯独解析超时率升高。所以探测必须带真实解析请求，不能只ping。
核心网设备上的resolv.conf如果配了搜索域（search域）和默认NDOTS阈值，短主机名会先被追加搜索域逐个尝试。例如查cg01这个计费网关短名，实际会先查cg01.ims.mnc001.mcc460.3gppnetwork.org失败，再查cg01.core.net失败，最后才查到cg01本身——每次呼叫附带两次注定失败的查询。单次无感，乘上话务峰值就是权威DNS的无谓负载，也给故障注入了不确定性：哪天有人把搜索域顺序调换，路由目标就变了。规范上3GPP域名要求全限定名（FQDN），一线的教训是：配置里禁用短名和搜索域猜测，宁可长，不可歧义。
Facebook那次故障里，Cloudflare的工程师是从自己的1.1.1.1异常中第一时间发现的——不是Facebook告诉他们的。这就是DNS类故障的残酷现实：受害者往往比责任方先知道。运营商的DNS监控要做到“自己先知道”，核心是把DNS当业务系统监控，而不是当主机监控。
flowchart TD
A["探测点部署在核心网机房"] --> B["真实域名解析拨测"]
B --> C["解析成功率与响应码分布"]
B --> D["解析时延P95和P99"]
A --> E["端口与协议存活探测"]
E --> F["UDP53与TCP53分别探测"]
A --> G["数据一致性核对"]
G --> H["主备权威应答比对"]
C --> I["低于阈值自动告警"]
D --> I
F --> I
H --> I
具体指标基线，给一张可以直接抄进值班手册的表：
| 监控项 | 探测方式 | 建议基线 | 告警阈值参考 |
|---|---|---|---|
| 解析成功率 | 每分钟对关键FQDN发起真实查询 | 99.9%以上 | 低于99.5%即告警 |
| 解析时延P95 | 拨测结果分位数统计 | 10ms量级（内网） | 超100ms告警 |
| SERVFAIL/NXDOMAIN占比 | 响应码分布统计 | 接近0 | 突增即告警 |
| TCP 53可用性 | 强制TCP探测 | 100%通 | 不通即告警 |
| 主备权威一致性 | 同一查询比对双机应答 | 完全一致 | 不一致即告警 |
| ENUM链路抽查 | 每小时抽测标准测试号码 | 全链路返回正确URI | 失败即告警 |
特别说明两点。第一，探测点要放在用户所在的位置——从核心网机房视角和从地市汇聚视角看到的DNS健康状况可能完全不同，中间隔着防火墙和传输。第二，主备一致性核对是被绝大多数现网忽略的：两台DNS服务器数据不同步（一台加了新号段数据另一台没加）时，故障表现为“主用正常、备用的解析是错的”——而切换演练不彻底的话，你会在真正切换的那天第一次发现它。
架构上，核心网DNS的可靠性设计原则并不复杂，难的是执行纪律：
把这张清单和FCC对T-Mobile的整改建议放在一起看，会发现精神完全一致：对低概率、高杀伤的基础件，用主动演练代替被动祈祷。FCC报告本身没有强制要求，但它把“注册风暴”“隐性依赖”“变更验证不足”这几个词写进了公开档案，此后全世界的运营商做韧性设计，都可以直接引用这份报告去说服管理层批预算——包括DNS相关的那部分。
回到开头的三场事故。Facebook用6小时证明了：连操控全球最大社交网络的顶级工程团队，也会被一个内部配置变更+DNS的连锁反应放倒，甚至进不了自己的机房。Akamai用1小时证明：专业DNS服务商自己也会被一条配置更新击中。T-Mobile用12小时、41%呼叫失败率和24,000通打不出去的911证明：电信网的注册与解析链路一旦在故障中被点燃，用户会亲手把你剩余的容量踩塌。
对一线工程师，本文想留下的只有三句话：第一，排障时把“查解析链路”放进标准动作，别让“先查无线再查核心”的惯性拖过黄金四小时；第二，监控必须用真实解析拨测，ping通不等于DNS活着；第三，任何DNS数据变更都要按核心网割接的规格管理——因为它就是核心网，只是长得不起眼。
网络里最危险的组件，永远是那些平时最安静、所有人默认它不会坏、坏了也没人第一时间想到它的组件。DNS排第一个，没人有意见。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。