问题根源来自大量隐藏依赖项，大多来自第三方和影子IT，这也凸显了运营可见性、韧性和治理的重要性。

图片来源：Rob Schultz / Shutterstock

预测服务中断本就棘手，但CIO（首席信息官）最好在日历上圈出2026年10月11日至2027年1月11日这段DNSSEC密钥双阶段过渡期，这一区间很可能发生范围广泛、原因不明的故障。

原因在于10月11日对DNSSEC（域名系统安全扩展）进行的一次看似微不足道的更新，该更新将在1月11日完全生效，很可能引发一系列看似互不关联的系统中断。问题来自海量的依赖项：第三方服务、影子IT、智能体、gen AI（生成式人工智能）、SaaS（软件即服务）、自研应用、遗留系统，以及许多其他隐蔽的可执行文件藏身之处，包括虚拟环境和容器。

支付卡巨头Visa的高级站点可靠性工程师Sai Joshitha Kathari（赛·乔西塔·卡塔里）表示，由于这些大量依赖项的存在，大多数企业面临的DNS（域名系统）相关风险远比他们认知的要高。

Kathari（卡塔里）指出：“如果底层DNS验证未修复的缺陷潜伏在核心业务功能之下，有可能对下游业务造成实质性破坏。”

风险在于这类问题大多要么不被IT部门知晓，要么由第三方供应商负责，IT部门没有人会想到去询问供应商关于DNS更新的问题。

Kathari（卡塔里）解释道：“风险领域通常不是那些显而易见的托管DNS服务。真正的风险来自老旧内部应用、硬编码DNS解析器、容器化工作负载、Sidecar边车容器配置、自定义脚本、合作伙伴集成、虚拟机镜像、过时基础镜像，以及长期无人维护的服务间依赖项。这些系统可以稳定运行多年，却会在DNS或证书相关变更时发生故障，因为它们绕过了常规平台标准。”

独立技术分析师Carmi Levy（卡米·莱维）表示，CIO必须高度重视这次事件。

Levy（莱维）说：“这个分为两个阶段的最后期限——2026年10月11日新KSK（密钥签名密钥）开始签名根区域，2027年1月11日旧密钥正式停用——所有人都应该在日历上用红笔标注出来，就像当年对待1999年12月31日的千年虫问题一样。如果没有做好合规准备，在过渡完成后，网站、核心业务应用和相关资源都可能从网络上彻底消失。”

Levy（莱维）补充道：“当DNS变更生效后，脱离常规支持机制的自定义代码大概率会出现DNS验证失败、无法正常工作。”

这次DNSSEC更新本身流程很简单，却是自2018年以来DNSSEC首次发生重大变更——具体而言是DNSSEC根区KSK信任锚点变更。

其官方推广声明指出：“信任锚点的正式名称是DNSSEC根区域KSK。KSK是位于DNSSEC信任锚点核心的加密密钥，用于验证DNS响应的合法性，确认其在传输过程中未被篡改。”

一、几乎所有企业都会受到影响

ICANN（互联网名称与数字地址分配机构）负责IANA（互联网编号分配机构）服务的副总裁、公共技术标识符总裁Kim Davies（金·戴维斯）表示，考虑到影子IT和其他边缘场景的特性，企业受到的影响程度无法提前预测。

但基于典型全球性企业中存在大量已知和未知依赖项，Davies（戴维斯）估计，几乎所有企业都会受到不同程度的影响。

“在结构高度复杂的组织中，组织的边角、边缘地带很可能会受到一些影响，” Davies（戴维斯）告诉CIO，“DNS是支撑一切业务的核心技术。”

Davies（戴维斯）指出，随着更新的扩散，各类异常故障将随密钥更新全网扩散逐步暴露。“当系统无法验证[DNS]信息时，它会将其视为可疑信息，DNS查询就会失败。”

Visa的Kathari（卡塔里）表示：“当发生与DNSSEC相关的重大变更时，企业应当预期会出现一些次要的DNS相关故障，这不一定是因为核心基础设施团队忽视了更新，而是因为大型环境存在许多隐藏的依赖路径。”

Kathari（卡塔里）指出，这些故障最初很可能看起来根本不是DNS故障，这会让问题严重恶化。这将迫使IT团队浪费大量时间排查那些最终证明和事件无关的原因。

“对CIO而言，DNS相关故障几乎不会直接呈现域名解析报错，会伪装成各类上层业务异常。它们会表现为应用超时、登录失败、失败的API（应用程序编程接口）调用、队列延迟、支付失败、合作伙伴连接问题或随机的区域性不稳定，”Kathari（卡塔里）解释道，“这会让故障排查变慢，因为团队可能会花数小时检查应用、数据库、网络或云服务商，之后才意识到域名解析是故障路径的一部分。”

Greyhound Research首席分析师Sanchit Vir Gogia（桑奇特·维尔·戈吉亚）同意，IT团队很可能会白费力气，找错方向。

“验证失败很少会局限在自身范围内。它会表现为应用错误、API超时或可达性问题，这会将解析器故障转变成协作故障，”Gogia（戈吉亚）说道，“应用团队怪罪网络，网络团队怪罪云，用户只能眼睁睁看着工作停摆。”

“镜像和模板是大多数团队会遗漏的盲区，”Gogia（戈吉亚）补充道，“夏季修复好的解析器，到10月可能会在旧的基准镜像重新部署时再次故障，因为自动化不再允许配置缓慢偏移，它会以机器速度恢复过去的配置假设。”

目前普遍预期企业执行这项变更不会有任何问题，或者更有可能的是，企业会依赖超大规模公有云服务商妥善处理这项变更。而这正是隐患所在。

咨询公司Acceligence的CEO（首席执行官）Justin Greis（贾斯汀·格赖斯）告诉CIO：“CIO目前注意力都被AI（人工智能）吸引走了，而这是一个非常深入基础设施的细节问题，它会让企业IT团队猝不及防。我认为我们会看到相当多的企业因DNSSEC信任锚轮换出现业务中断。这不是因为更新本身特别难，而是因为它会暴露许多企业内部早已存在的薄弱点。”

大多数企业IT运维部门此前没有理由整理一份所有DNS依赖项的完整清单，但很多依赖项会在1月份立刻暴露出来。

二、潜在的广泛影响

例如，一家大型零售商可能突然无法连接FedEx安排配送，或者医院可能发现检测结果无法再共享到患者门户。故障可能表现为装配线停产，因为IIoT（工业物联网）组件无法再和供应商系统共享文件，或者卡车车队无法再被跟踪。

Greis（格赖斯）说：“几乎肯定会有系统被漏掉。其中一些是依赖多年未更新的过时DNS配置的遗留应用。另一些则是业务部门开发的工具、承包商构建的解决方案、嵌入式系统、制造和工业系统，或是在常规IT监管之外运行的高度定制化工作负载。这些就是这类基础设施事件中经常暴露出来的系统类型。”

Greis（格赖斯）补充道，很多企业会在1月份发现自身自动化带来的问题。

Greis（格赖斯）指出：“随着时间推移，企业会构建多层流程、模板和部署机制，供跨团队、跨环境复用。即使DNS基础设施已经正确更新，旧配置仍可能在常规更新和系统变更中被意外重新引入，造成间歇性、难以诊断的故障。”

这种情况好的一面是，如果发生这些故障，企业不太可能完全失去DNS访问。但这可能也没什么安慰作用，因为即使中断只发生在小的边缘场景，仍然会造成大规模的运营中断。

Infoblox执行副总裁兼首席技术布道官Cricket Liu（克里克特·刘）举了一个响应工厂车间系统查询的DNS服务器的例子。

“或者说，这会扰乱一家企业的关键SaaS（软件即服务）应用。所有域名解析都会停滞，系统会显示服务器故障。无论你查询任何内容，都不会得到响应。这种影响绝非不易察觉，”Liu（刘）表示，“企业几乎必然会受到一定影响。”

回到2017年，上一次密钥轮换相对平稳，这让不少CIO抱有希望，认为2027年1月的这次轮换也会平安无事。但结合过去十年的技术发展，以及由此催生的企业对新兴技术的依赖浪潮，几乎没有人真的认为这次不会出现任何问题。

三、无法预判最终结果

研究企业DNS影响的顶级网络专家之一，是Geoff Huston（杰夫·休斯顿），他担任APNIC（亚太网络信息中心）首席科学家。

Huston（休斯顿）指出，在事件实际发生前，很难预判2027年1月会出现什么情况。

他表示：“就像上一次轮换一样，这次密钥更换我们完全是完全处于不可观测、无法提前预判的状态。因为上一次没有发生严重事故，所以大家有信心这次也不会出大事，但我们事先无法确定结果——目前没有可靠的测量方法能够让我们窥探递归解析器内部的信任锚状态。”

针对潜在的极端边缘故障，Huston（休斯顿）认为这种情况是有可能发生的；但如果第三方供应商没有正确处理此次更新，还会衍生出其他问题，因为DNSSEC中使用的KSK，会对保护DNS记录的密钥完成签名与验证流程。

Huston（休斯顿）说：“如果系统不符合标准，那你面临的问题远不只是KSK轮换这么简单，因为这会引出一个明确的问题：‘我现在运行的这台DNS解析器，还有哪些功能没有正确实现？’”

而这件事也有积极的一面：Acceligence的Greis（格赖斯）认为，DNS KSK更新引发的任何小故障，对CIO来说都可能是因祸得福的契机。

Greis（格赖斯）表示：“讽刺的是，技术栈中很多对业务最关键的组件往往最不显眼，因为它们一直运行在后台。”1月的这次事件“可能会让人们意识到，现代业务韧性对基础设施的依赖程度——而很多组织直到故障发生才会去检查这些基础设施。对CIO来说，这才是真正的教训。这件事本质上不是一次简单的DNS更新，它关乎运营可见性、业务韧性和治理能力。将此次轮换当作常规基础设施任务的组织，大概率会完成更新后继续推进业务；而将此次事件作为契机，梳理加固自身技术环境基础的组织，收获的价值会远不止于避免一次服务宕机。”