概述：2021年12月9日下午，英国三家移动运营商的数据业务同时告急，用户“能打电话、上不了网”，连希思罗机场的护照闸机都瘫了。蹊跷的是，最重的受害者O2自己网内一切正常——根因在一家第三方网络服务商的一次路由配置变更上，它切断了运营商递归DNS通往上游任播解析集群的路径。本文复盘这起“没有当事运营商的断网”，回答两个运维问题：核心网里的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管的是“把公司域名解析成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节点，对一大片目的地变得不可达。
于是三层依赖塌了最底层：
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运维的特点就是：平时存在感为零，出事的时候全场都是它。标准对解析路径允许多种实现与组网方式，具体行为以各厂家官方文档为准——但“路径画没画、上游冗余不冗余、演练做不做”这三问，哪种实现都躲不掉。
最后说说为什么这个问题在2026年不但没过时，反而更尖锐了。
5G SBA架构下，一切网元互访都始于FQDN。NRF虽然承担了服务发现，但NRF自己的地址、NF之间HTTP/2连接的目标地址，仍然要过解析；NRF挂了，规范还有本地缓存和各种兜底设计，可DNS挂了，连“去找NRF”这条路都断了——DNS是比NRF更底层的那一层，这是很多团队在建5GC容灾体系时排序错误的地方。
网络云化之后，解析面还在物理上扩大了：UPF下沉到地市、边缘计算节点遍地开花，解析请求的源和目的地都从集团机房扩散到了边缘。过去“一台核心DNS+两条上游”的简单模型，正在变成“多层递归+动态调度”的复杂模型。层数越多，第三方依赖越多，12月9日那种“塌在最底层”的故事，概率不是变小，是变大。
给这篇文章留一个行动项：读完之后，去把你所在网络的拓扑图翻出来，找找递归解析器画在哪一层、上游指向谁。如果答案是“图上没有”——那你已经找到了本轮巡检的第一个工单。
本文由「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 等场景全覆盖。