**概述**：2021年12月9日下午，英国三家移动运营商的数据业务同时告急，用户“能打电话、上不了网”，连希思罗机场的护照闸机都瘫了。蹊跷的是，最重的受害者O2自己网内一切正常——根因在一家第三方网络服务商的一次路由配置变更上，它切断了运营商递归DNS通往上游任播解析集群的路径。本文复盘这起“没有当事运营商的断网”，回答两个运维问题：核心网里的DNS到底承担着什么？给这台最隐形的基础设施，该建哪几道护栏？ ## 目录 - 一、一次奇怪的断网：受害者不是一家 - 二、补课：核心网里的DNS和IT的DNS不是一回事 - 三、链条复盘：三层依赖，塌在最底层 - 四、时间线与影响面 - 五、处置与监管质询 - 六、运维的六道护栏 - 七、5G时代，DNS反而更不能挂 ## 一、一次奇怪的断网：受害者不是一家 2021年12月9日，伦敦时间午后，英国的故障投诉平台Downdetector上曲线开始陡升。用户报障的描述高度一致：手机有信号，电话能打，短信能发，就是移动数据不可用。网页转圈，App加载失败，社交平台上“全英国断网了”的话题迅速升温。 按照处理故障的惯例，第一反应是看自己网内：无线侧有没有大面积退服？核心网有没有网元宕机？O2的网管上什么都看不出来——基站正常，EPC网元正常，计费正常。但数据业务就是建立不起来，附着、TAU、新建PDN连接大面积失败或超时。 更蹊跷的在后面。这次故障的受害者名单拉出来，横跨好几个不相干的行业：O2首当其冲，旗下虚拟网giffgaff、Sky Mobile（租用O2网络）一并遭殃；Vodafone UK和Three的部分用户也报告了数据异常；希思罗机场的电子护照闸机（e-gates）无法办理自助通关，旅客在边境排起长队；快递公司DPD的派件系统出了问题，包裹卡在路上；一些企业办公系统同样失灵。 一群八竿子打不着的机构同时瘫痪，这在排障上本身就是一条重量级线索：**根因大概率不在任何一家网内，而在大家共享的某个公共依赖上**。电信工程师对这种模式不陌生—— power、传输光缆、公共DNS，都是典型的“一坏坏一片”的基础设施。这次，是最后一样。 O2当天对外表态：问题出在“一家第三方供应商”。这个说法当时还挨了不少嘲讽，运营商出事甩锅第三方，听上去像标准动作。几天后事情水落石出，这句表态居然字字属实。 ## 二、补课：核心网里的DNS和IT的DNS不是一回事 要理解这起事故，得先补一课：运营商核心网里的DNS，和IT部门管的企业DNS，干的活完全不是一个量级。 企业DNS管的是“把公司域名解析成IP”。运营商核心网DNS管的是**整张移动网络的节点选择**。它在3GPP架构里的位置，比大多数运维同事想象的要底层得多： **第一，开机附着那一步就离不开它。** 终端附着时要根据APN选择服务网关。网络侧拿到APN后，按规范（TS 23.003）拼出FQDN——APN加上“.mncXXX.mccYYY.gprs”后缀，再通过基于DNS的S-NAPTR流程（TS 29.303定义）逐级查询NAPTR/SRV记录，最终选出可用的S-GW/P-GW及其服务地址。这套流程对终端完全透明，用户感知不到，但它每时每刻都在发生。解析失败，附着就失败。 **第二，国际漫游的命脉。** 用户漫游到国外，拜访地网络要解析出他归属运营商的P-GW/归属路由地址，靠的就是到".3gppnetwork.org"域的DNS查询。没有DNS，国际漫游用户直接失联。ePDG发现（VoWiFi用户接入），也是按标准格式去解析`epdg.epc.mncXXX.mccYYY.3gppnetwork.org`这类FQDN。 **第三，IMS语音的门牌。** P-CSCF的发现机制，无论走DHCP+DNS还是走接入层信令，最终都落到DNS记录上。SIP服务器定位的NAPTR/SRV机制，源头就是IETF的RFC 3263。 **第四，5G时代不但没被边缘化，反而无处不在。** SBA架构下，NF之间全靠FQDN互访，NRF本身也有规范定义的域名格式（TS 29.510），UPF选择、切片DNN路由、边缘计算要“选最近的一个”，背后都是解析。DNS挂了，NF连NRF都找不到。 一句话总结：**IT的DNS坏了，上班打卡受影响；核心网的DNS坏了，用户“在线”这个状态本身就不存在了。** | 维度 | 企业IT内网DNS | 运营商核心网DNS | |---|---|---| | 服务对象 | 内部员工、办公系统 | 全网终端附着、漫游、IMS、SBA | | 关键记录 | A/AAAA、CNAME | NAPTR、SRV为主，配合A/AAAA | | 容量特征 | 工作日白昼潮汐 | 开机潮、节假日晚高峰、重大活动脉冲 | | 故障表现 | 打不开内部网站 | 附着失败、漫游中断、VoWiFi失联 | | 解析路径 | 内网权威+递归 | 网内递归+上游递归+3gppnetwork权威，链路长 | | 典型软肋 | 单点、配置错误 | 第三方上游依赖、缓存过期雪崩 | ## 三、链条复盘：三层依赖，塌在最底层 现在回到12月9日那天。把当天的公开信息串起来（以下机制描述综合当时BBC、The Register等媒体的报道与相关方声明），故障链条是这样的： 英国多家运营商和企业，把递归解析的上游托管给了Tata Communications的全球任播（anycast）DNS集群——这是电信行业常见的做法：自建递归解析器成本高、要跟着全球部署，外包给专业厂商，用任播把用户引到最近的节点。O2的核心网递归解析器，上游指向的就是这个集群。 当天下午，一家名叫Exponential-e的英国以太网与云连接服务商进行了一次计划内的网络变更，配置出错，错误的路由信息经BGP扩散，波及了Tata的全球路由可达性。结果就是：Tata的任播DNS节点，对一大片目的地变得不可达。 于是三层依赖塌了最底层： ```mermaid flowchart TD A["手机终端"] -->|"建立数据连接"| B["O2递归DNS"] B -->|"上游递归查询"| C["Tata任播DNS集群"] D["第三方路由变更"] -->|"配置错误"| E["错误路由扩散"] E -->|"波及全球路由"| C C -.->|"解析超时"| B B -.->|"无应答"| A F["机场闸机等企业"] -.->|"同源上游"| C ``` 这里有一个值得所有运维同事情细品的细节：**故障不是瞬间全网生效的，而是随着缓存过期逐步蔓延**。解析器缓存里还热着的记录，继续正常工作——所以故障初期，一部分用户还能用，一部分已经不行，投诉曲线是爬坡的。缓存是DNS体系自带的“电池”，它让故障显得更诡异，也让根因定位更容易被带偏：你会怀疑是某个区域、某个网元、某类APN的问题，其实是缓存过期在跟你玩“狼人杀”。 还有一个反直觉的点：**任播不是冗余开关**。很多方案评审会上，任播DNS被当成容灾的终极答案——“全球几十个节点，挂谁都还有别的节点接”。但12月9日证明了这句话的边界：所有任播节点共享同一套路由可达性、同一个上游体系。路由层面出问题，几十个节点一起“失联”，冗余在同一个故障域里不叫冗余，叫复制粘贴。 至于希思罗机场和DPD为什么会一起遭殃——因为它们恰好也使用同一上游递归服务。一条“企业也用运营商级DNS上游”的隐性依赖，让这次事故从通信行业溢出到了边境通关和物流。 ## 四、时间线与影响面 | 时间（2021-12-09，伦敦时间） | 事件 | |---|---| | 午后 | 多家运营商用户移动数据开始异常，投诉曲线陡升 | | 下午 | 故障面扩大：O2最重，Sky Mobile、giffgaff受累；Vodafone、Three部分用户；希思罗e-gates闸机停摆、DPD派单异常 | | 下午 | O2对外确认问题源于“第三方供应商”；Exponential-e定位到自身路由配置错误并执行回退 | | 傍晚 | 数据业务陆续恢复，当天基本收口 | | 次日起 | 监管机构Ofcom表示展开紧急质询，要求相关方说明情况 | 影响面上，O2是英国用户规模以千万计的运营商，叠加旗下虚拟网，单日受影响用户以百万计；好在故障发生在工作日午后而非晚高峰，且语音、短信基本正常，未酿成紧急呼叫层面的公共安全事件——但边境闸机停摆那一幕，足以说明“看不见的DNS”出事时，杀伤半径远超通信业。 ## 五、处置与监管质询 这起事故的处置过程，有一个很少见的特征：**认责方不是运营商**。 Exponential-e事后公开发声，承认是其工程师在计划变更中的配置错误引发路由问题，向受影响客户致歉，并表示问题在定位后迅速回退。O2的“第三方供应商”说法由此得到印证。Tata一侧的问题（其任播DNS为何会被第三方路由变更波及、任播节点的路由防护是否到位），据当时报道并未完全对外展开——这也是行业内对这起事故最惋惜的地方：完整的技术复盘报告始终没有公开，多数细节来自各方声明的拼图。 监管侧的反应很快。英国通信管理局Ofcom当天即表示“紧急质询”（making urgent enquiries），要求O2解释故障原因与恢复过程。在英国监管框架下，运营商对网络弹性（resilience）负有一般性义务，第三方依赖不能成为免责理由——这个立场对全球运营商都有参考价值：**你外包了服务，但监管责任和用户感知，外包不出去**。 ## 六、运维的六道护栏 复盘不是目的，落地才是。站在核心网运维的角度，这起事故能提炼出六道护栏，每一条都可以直接变成检查项。 **护栏一：把DNS画进组网拓扑。** 大量运营商的网络拓扑图上，根本不存在“递归解析器”这一层——它隐形到连图纸都懒得画它。第一步就是把每个APN/DNN、每个漫游场景、每类IMS接入的解析路径完整画出来：终端→网内递归→上游递归→权威，一跳不能少，每跳标清归属（自维/外包）。画完你会发现，解析路径上如果有第三方，它就是一级依赖。 **护栏二：上游多元异构，并定期演练。** 上游递归至少两条，且必须“异构”——分属不同供应商、跑在不同底层网络上。两条上游租给同一家、走同一根传输，那不叫备份。有条件的情况下，每季度做一次“拔上游”演练：主动切断主上游，观察缓存还能撑多久、备路多久接管、哪些业务会抖。这次英国事故里，运营商对上游的路由变更是毫不知情的——演练至少能把“毫不知情”变成“分钟级发现”。 **护栏三：把缓存当免费的容灾来管理。** 缓存是解析链路上唯一不花钱的可用性手段。核心网专用记录（网关FQDN、P-CSCF、NRF）的TTL要纳入割接纪律：**变更前调低TTL让旧缓存提前排空，变更完成观察稳定后再调回**——这是DNS运维的经典动作，但在很多核心网割接方案里根本找不到这一条。反过来，要核查解析器有没有对关键记录做了“不缓存”或过短TTL的配置，那是白白扔掉容灾能力。 **护栏四：监控从“ping得通”升级到“解析得对”。** 传统网管盯的是DNS服务器进程和端口，这在12月9日那天什么都报警不出来——服务器活得好好的，是“路”不通。主动拨测必须做全链路：定期发起真实的S-NAPTR/SRV查询（可以构造测试APN），盯解析成功率、端到端时延、超时率三个指标，分级告警。再往上一层是业务拨测：模拟真实终端做附着和数据连接，作为最后一道兜底——解析面和业务面之间还有一层配置，只有业务拨测能覆盖。 **护栏五：第三方依赖登记与合同条款。** 把“解析路径上的第三方”列入一级依赖清单，写进资产台账。合同里要写清楚三件事：重大路由/平台变更的事前通知义务、故障的通报时限、联合演练的频次。没有这三条的合同，等于把自己的可用性押在别人的变更纪律上。 **护栏六：应急静态解析兜底。** 核心网里的关键FQDN（网关、P-CSCF、NRF等数量有限、变更低频），应该在预案里准备好静态解析兜底方案——极端情况下直接下发静态配置绕开解析链路。这不是常态化手段（牺牲灵活性换可用性），但“能打电话不能上网”的午后，它就是最快的止血带。 这六道护栏没有一条涉及黑科技，全是纪律。DNS运维的特点就是：平时存在感为零，出事的时候全场都是它。标准对解析路径允许多种实现与组网方式，具体行为以各厂家官方文档为准——但“路径画没画、上游冗余不冗余、演练做不做”这三问，哪种实现都躲不掉。 ## 七、5G时代，DNS反而更不能挂 最后说说为什么这个问题在2026年不但没过时，反而更尖锐了。 5G SBA架构下，一切网元互访都始于FQDN。NRF虽然承担了服务发现，但NRF自己的地址、NF之间HTTP/2连接的目标地址，仍然要过解析；NRF挂了，规范还有本地缓存和各种兜底设计，可DNS挂了，连“去找NRF”这条路都断了——**DNS是比NRF更底层的那一层**，这是很多团队在建5GC容灾体系时排序错误的地方。 网络云化之后，解析面还在物理上扩大了：UPF下沉到地市、边缘计算节点遍地开花，解析请求的源和目的地都从集团机房扩散到了边缘。过去“一台核心DNS+两条上游”的简单模型，正在变成“多层递归+动态调度”的复杂模型。层数越多，第三方依赖越多，12月9日那种“塌在最底层”的故事，概率不是变小，是变大。 给这篇文章留一个行动项：读完之后，去把你所在网络的拓扑图翻出来，找找递归解析器画在哪一层、上游指向谁。如果答案是“图上没有”——那你已经找到了本轮巡检的第一个工单。 ## 参考来源 1. [Ofcom（英国通信管理局）官网](https://www.ofcom.org.uk) — 2021年12月10日起就本次多运营商断网事件展开紧急质询，监管调查信息入口（原始声明发布于2021年12月） 2. [3GPP TS 29.303: Domain Name System Procedures](https://www.3gpp.org/dynareport/29303.htm) — EPS节点选择的S-NAPTR流程，本文“核心网DNS职责”部分的规范依据 3. [3GPP TS 23.401: GPRS enhancements for E-UTRAN access](https://www.3gpp.org/dynareport/23401.htm) — S-GW/P-GW选择流程的架构定义 4. [IETF RFC 3263: Locating SIP Servers](https://datatracker.ietf.org/doc/html/rfc3263) — SIP服务器定位的NAPTR/SRV机制，IMS P-CSCF发现的技术源头 5. [Exponential-e官网](https://www.exponential-e.com) — 涉事第三方服务商，2021年12月就路由配置错误发布声明致歉（原文发布于2021年12月） > 本文由「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 等场景全覆盖。