# 全城打不通电话，凶手是一台DNS ## 概述 2021年10月4日，Facebook全球瘫痪近6小时；两个月前，Akamai的一次DNS配置更新让PlayStation、UPS、Airbnb同时失联；再往前一年，T-Mobile一条光纤闪断12分钟，却引发注册风暴，全美语音瘫痪超过12小时，FCC报告显示至少41%的呼叫未完成。这三个事故背后有一个共同的影子：DNS——这个平时没人多看一眼的基础件，一旦倒下，最先死的往往不是网页，而是语音。本文从FCC官方故障报告和Cloudflare复盘出发，拆解运营商核心网对DNS的隐性依赖、四个最阴的经典故障模式，以及一套可落地的监控与演练方案，回答一个问题：为什么你排障三天查不出根因，最后发现凶手是一台DNS。 ## 目录 - 一、引子：半个互联网，栽在一台DNS手里 - 二、运营商核心网里，谁在偷偷依赖DNS - 三、T-Mobile 2020复盘：12分钟光纤闪断，12小时全网瘫痪 - 四、四个最阴的坑：一线排障实录 - 五、监控体系：别等用户打电话来骂 - 六、把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 很多人对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，往往是被更资深的工程师一句“先看看解析链路”点醒的。 ## 三、T-Mobile 2020复盘：12分钟光纤闪断，12小时全网瘫痪 如果说Facebook和Akamai证明了DNS是互联网的软肋，那么FCC这份2020年10月22日发布的官方故障报告，则完整解剖了电信网版本的灾难。这份报告的可贵之处在于：FCC拿到了T-Mobile的机密呼叫成功率和分代呼叫失败数据，是极少数有官方数据的全国性语音瘫痪案例。 ### 事件时间线 | 时间（2020年） | 事件 | |---|---| | 6月15日中午前后（美东） | 东南部一条租用光纤链路故障，持续仅约12分钟 | | 故障发生时 | 同区域一台新装机路由器配置不完整，备用路径无法正确承载信令 | | 随后数分钟 | 亚特兰大市场开始出现"注册风暴"，终端反复注册失败 | | 数小时内 | 风暴随终端漫游扩散，蔓延出亚特兰大市场，波及全国 | | 当天白天至傍晚 | 终端依次尝试4G、3G、2G注册，最后转WiFi通话，继续失败 | | 当天深夜（12小时以上后） | 服务逐步恢复 | | 10月22日 | FCC发布网络故障报告，估算影响并给出整改建议 | ### 级联链条拆解 ```mermaid 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呼叫失败**。 ### DNS在这场灾难里的角色 严格说，T-Mobile这起事故的直接导火索不是DNS，而是路由+软件缺陷的复合故障。但它对本文主题的启示恰恰在这里：**故障的传播载体是“注册-解析-路由”这条信令链**。终端每一次注册失败后的重试，都伴随着一轮完整的网络选择与解析流程；当解析和路由基础设施处于亚健康状态时，重试风暴会把这些平时被缓存的“隐藏依赖”全部暴露出来。FCC报告给行业的整改建议里，除了路由变更的灰度验证、软件缺陷的潜伏期检测，反复强调的一个词是complexity——网络的隐性依赖越叠越多，任何单一故障的爆炸半径都在指数级放大。 这个逻辑对国内运营商同样成立。你现网里那些“从没人动过、从没人看过”的DNS服务器、ENUM数据、GTP对端静态配置，就是FCC说的隐性依赖。它们不出事的时候，没人记得它们存在。 ## 四、四个最阴的坑：一线排障实录 下面这四个坑，来自笔者和同行这些年踩过或见过的真实场景（具体运营商信息隐去，机制以3GPP和RFC公开规范为准）。它们的共同点：现象离根因十万八千里，告警台上几乎无声。 ### 坑一：UDP截断后，TCP 53被防火墙拦死 DNS响应超过约512字节（EDNS0下常见上限1232字节）会被置TC标志截断，客户端自动转TCP 53重试。问题在于：很多核心网机房的防火墙策略是“放行UDP 53，没考虑TCP 53”。平时查询短、响应小，一切正常；一旦某条NAPTR链变长、或者上了DNSSEC、或者运营商把ENUM数据从十几个号段扩到几百个，响应一变大，TCP fallback全被丢弃。**现象是“大查询失败、小查询正常”**，比如某类特定业务（恰好查询链长的）注册失败率高，其他都好。排障时dig默认UDP测试正常，必须用`dig +tcp`复现。 ### 坑二：TTL与缓存的错位，割接后指错路 IMS割接最经典的事故形态：网元IP换了，配置文件全改了，验证通过，割接结束。凌晨三点，第一批话务进来——一部分呼叫打到旧地址去了。原因：PDN网关或S-CSCF缓存里的旧记录TTL还没过期。反过来，TTL设太短，缓存穿透，每次呼叫都去查权威，权威一抖，呼叫建立时延跟着抖。经验基线：核心网内部域名TTL控制在分钟级——长到能扛住权威侧闪断，短到割接窗口内能自然收敛。割接单里必须有一项：**割接后主动刷新缓存或等待TTL过期再放话务**，这一条写不进割接单的割接，都是赌博。 ### 坑三：解析超时的retry语义，呼叫建立慢半拍 Linux的resolver在首选DNS服务器无响应时会等超时再试下一个，一轮超时常见就是5秒量级。对网页浏览，用户感知是“慢一点”；对呼叫建立，5秒意味着**用户已经把手机从耳边拿下来了**。这类故障的诡异之处在于：业务没失败，只是慢——话统里接通率正常，但呼叫建立时延KPI悄悄劣化。往往是一个DNS服务器的网卡半瘫（丢包但不完全断），监控ping通、端口探测通，唯独解析超时率升高。所以探测必须带**真实解析请求**，不能只ping。 ### 坑四：搜索域与NDOTS，短域名查三遍 核心网设备上的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当业务系统监控，而不是当主机监控。 ```mermaid 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当核心件：双活、基线与演练 架构上，核心网DNS的可靠性设计原则并不复杂，难的是执行纪律： 1. **物理双活**：两套DNS服务器分属不同机房、不同供电、不同传输路由。同一机房双机不叫双活，叫心理安慰——T-Mobile那场事故里，故障域就是一条光纤路由。 2. **配置变更走灰度**：Akamai那次全球DNS事故的直接原因就是一次配置更新触发的bug。核心网DNS的任何数据变更，先在一台备机上生效、观察、比对，再推全网。变更窗口选话务低谷，变更单里写明回退命令。 3. **配置基线文档化**：监听地址、递归开关、允许查询的网段、最大响应大小、EDNS0配置、日志级别——全部写进基线并纳入定期审计。3GPP标准允许各设备厂家的解析实现细节有差异，具体行为以各厂家官方文档为准，但基线里必须明确你自己的网络用的是哪一种。 4. **纳入年度演练**：每年至少一次“拔线演练”——直接拔掉主用DNS，观察收敛时间和业务影响。Cisco Umbrella在Akamai事故中靠缓存兜底成功，靠的不是运气，是缓存策略平时就在生效。没演练过的双活，等于没有。 把这张清单和FCC对T-Mobile的整改建议放在一起看，会发现精神完全一致：**对低概率、高杀伤的基础件，用主动演练代替被动祈祷**。FCC报告本身没有强制要求，但它把“注册风暴”“隐性依赖”“变更验证不足”这几个词写进了公开档案，此后全世界的运营商做韧性设计，都可以直接引用这份报告去说服管理层批预算——包括DNS相关的那部分。 ## 七、结语：看不见的基础件，才是命门 回到开头的三场事故。Facebook用6小时证明了：连操控全球最大社交网络的顶级工程团队，也会被一个内部配置变更+DNS的连锁反应放倒，甚至进不了自己的机房。Akamai用1小时证明：专业DNS服务商自己也会被一条配置更新击中。T-Mobile用12小时、41%呼叫失败率和24,000通打不出去的911证明：电信网的注册与解析链路一旦在故障中被点燃，用户会亲手把你剩余的容量踩塌。 对一线工程师，本文想留下的只有三句话：第一，排障时把“查解析链路”放进标准动作，别让“先查无线再查核心”的惯性拖过黄金四小时；第二，监控必须用真实解析拨测，ping通不等于DNS活着；第三，任何DNS数据变更都要按核心网割接的规格管理——因为它就是核心网，只是长得不起眼。 网络里最危险的组件，永远是那些平时最安静、所有人默认它不会坏、坏了也没人第一时间想到它的组件。DNS排第一个，没人有意见。 ## 参考来源 1. [Understanding how Facebook disappeared from the Internet — Cloudflare Blog](https://blog.cloudflare.com/october-2021-facebook-outage) — Cloudflare工程师Celso Martinho的官方复盘，含BGP撤销时间线、1.1.1.1查询量30倍激增数据与恢复时间曲线 2. [FCC Issues Staff Report on T-Mobile Outage](https://www.fcc.gov/document/fcc-issues-staff-report-t-mobile-outage-0) — FCC官方网络故障报告入口，含2020年6月15日T-Mobile全国语音故障根因与整改建议 3. [FCC report on T-Mobile nationwide outage is a case study — Steve Blum's Blog](https://www.tellusventure.com/fcc-report-on-t-mobile-nationwide-outage-is-a-case-study-in-network-complexity-and-best-practices/) — 对FCC报告的解读，引用41%呼叫失败估算与注册风暴细节 4. [Akamai DNS Outage 2021 — Outage Atlas事件存档](https://outage-archive.jonathanrreed.com/incident/akamai-dns-outage-2021/) — 2021年7月22日Akamai Edge DNS配置变更事故的影响范围与官方回应存档 5. [3GPP TS 23.003（Numbering, addressing and identification）](https://www.3gpp.org/dynareport/23003.htm) — 定义APN解析的S-NAPTR流程与核心网域名规范，本文第二、四节机制的规范依据 --- > 本文由「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 等场景全覆盖。