金融电子化 | 对核心服务业务中断事件的思考：金融行业应体系化构建韧性DNS
2025年10月20日，云厂商AWS核心服务业务中断，全球数千个线上平台瘫痪。与6月6日，中国某大型云厂商域名被“停服”不同，此次AWS服务中断原因是自建DNS出现故障且缺乏应急预案，造成长达15个小时服务大面积中断。根据Downdetector数据，跨境电商卖家损失惨重，预计单日全球交易额损失达数十亿美元。
接连发生的故障，为金融行业网络基础设施建设敲响警钟：DNS服务的可靠性直接关系到金融业务的命脉，亟待体系化治理。
互联网域名系统国家工程研究中心（ZDNS）
总经理 邢志杰
事件回顾：DNS解析问题导致业务受影响15个小时
北京时间10月20日15点，AWS发出通告：判断由于DNS解析问题导致美国东部1区（us-east-1）内重要应用系统DynamoDB、EC2、Lambda等核心服务严重受阻，超过上百家全球化企业的核心应用无法正常提供服务。即使在1.5小时内恢复了DNS，但截至北京时间10月21日凌晨3点，事件发生12个小时后仍有绝大部分业务处于中断状态（如图1所示）。
图1 24小时内关于AWS云服务中断的用户报告
（图源“华尔街见闻”）
事件凸显了DNS在现代应用架构中的关键作用，即便底层服务已恢复，若DNS解析未完全正常或及时刷新，业务影响仍会持续蔓延。为清晰还原故障从发生到恢复的全过程，我们将本次AWS服务中断的关键时间节点梳理如下。
北京时间10月20日：
14时48分：所有需要连接到（us-east-1）区域DynamoDB服务的系统无法连接到DynamoDB。
15时38分：确定DynamoDB的DNS状态是此次中断的根源，出现DNS故障。
16点15分：采用临时缓解措施使部分内部服务能够连接到DynamoDB，并修复了关键的内部工具，为进⼀步恢复扫清了障碍。
17点25分：所有DNS信息已恢复，所有全局表副本在凌晨2点32分完全同步。
17点40分：随着缓存的DNS记录过期，能够解析DynamoDB端点并建立成功的连接。
事件分析：DNS运行机制存在风险
AWS的很多大型服务都依赖DNS来实现无缝扩展、故障隔离与恢复、低延迟和本地化。以DynamoDB（AWS核心云计算产品）为例，该服务有几十万个DNS记录，满足大量集群的负载均衡，以自动化机制来保障进行动态更新，这样可以在有新增容量/集群故障时进行弹性伸缩，高效分配流量以优化客户体验。这种自动化设计自身具备韧性，确保服务在各种异常场景下恢复保持服务。
在正常情况下，整个机制可以确保所有DNS服务节点的数据最新且保持一致（如图2所示）。而问题发生的直接原因，在于一个竞争条件和一个潜在漏洞抹除了Dynamodb在us-east-1区域的所有可用端点IP。三个DNS执行器均独立运行，在缺乏有效协调的情况下，多个控制器对数据的更新和清理操作发生冲突：一个控制器延迟，导致两个控制器更新的数据发生冲突，其中一个控制器误将刚刚更新的正确数据当作过期数据删除，最终使整个系统数据丢失，超出了整个机制的设计边界，导致服务崩溃。
图2 AWS DNS运行机制
更为致命的是，DNS系统故障后，管理员并未第一时间发现，直到50分钟后才定位到是DNS故障导致，直接导致了故障进一步升级。此时所有依赖DynamoDB的服务均已无法正常工作。加之确定DNS故障后没有快速应急的手段及关键工具，近2个小时后才完全恢复，故障范围逐渐蔓延，导致其他服务/组件也陆续出现问题。
可见，AWS虽然已经从域名设计、DNS系统设计层面充分考虑可靠性、可扩展性，但仍缺少对异常的快速发现、定位以及应急处置的能力。
事件思考：对金融行业DNS建设运营的借鉴意义
本次事件，清晰地揭示了DNS服务一旦故障可能引发的系统性风险，也为金融行业的关键网络基础设施建设敲响了警钟。深入分析此次事件，有以下三点核心思考。
1. 架构设计：私有云+专业DNS，是金融业务稳定性的基石
云平台自带的DNS的设计往往受公有云高效率运营的理念影响，更偏向高效率，与金融行业风险控制优先的理念并不契合。例如AWS的DNS采用的多活控制器技术，可有效节约运维人力投入，但必然存在极端场景下因不一致导致系统崩溃的情况。
目前金融业务上云场景下，域名化是主流技术路线，整个金融科技系统对DNS服务的深度依赖，DNS服务的韧性对业务连续性至关重要。目前金融行业使用的私有云往往都带有DNS组件，用于满足多Region/AZ间业务多活场景的需求，但这些组件作为支撑组件，往往存在黑盒运维、组件耦合等问题，存在故障传导效应，导致恢复时间漫长。如发生在金融系统，将会造成更为严重的后果。
通过采用在业界已广泛使用多年的专业DNS产品，提供韧性的DNS服务，支撑域名化数据中心的稳定运行，避免关键环节成为隐患，是更好的选择。
目前业界头部的私有云建设中，DNS大多采用独立建设的方式进行解耦，确保云平台控制组件异常的情况下，调度控制服务不受影响，也更符合多云场景下的全局流量调度要求。
2. 应急机制：金融运维应具备故障早发现、早处理的能力
在上述事件中，对DNS这一关键服务故障没能快速发现和定位，即没有快速的应急手段恢复DNS故障，处置时间过长，导致故障范围扩大和影响程度加深。在金融行业环境中，对运维的压力更严峻。
● 故障定位难：DNS作为关键服务与云本身深度融合，存在故障定位难度高、处置效率低等问题。
● 运维压力大：在国内金融行业环境中，没有头部云厂商强大的运维团队支持，类似事故的持续时间可能会更长，金融行业运维压力大。
● 处理复杂度高：在大型故障发生的时候有太多的非技术干扰因素，这一点经常导致故障修复效率远低于预期。
综上，DNS一旦发生故障，对金融业务连续性产生的冲击是不可承受之重。网络故障管理的重点在于“早发现、早处理”，必须对DNS这一关键服务制定涵盖“故障发现、根因锁定、及时处理”的有效应急预案。金融行业更需要“兜底”产品，尤其是对DNS系统运行稳定性、运维质量的可观测，并对DNS系统制定一旦发生灾难的应急逃生策略。
3. 兼顾安全与发展：构建体系化韧性DNS系统
全球性DNS事件，已超越传统的DDoS攻击或技术漏洞范畴，演变成为系统性、架构级风险。域名管理涵盖了从注册商、公共DNS服务商到自建DNS集群的完整链条，任一环节的疏忽都可能导致全线瘫痪。从域名注册到域名解析，全面构建体系化的韧性DNS系统，是把控潜在风险、支撑业务发展的重要保障。
一是掌握基础资源，域名注册管理自主可控。关键核心业务需要减少对国外管辖的域名资源依赖，应优先注册和使用由国家主导管理的顶级域名（如.CN）下的二级域名，能从根本上降低因国际司法管辖冲突而被境外注册局单方面“停服”的风险。同时，建议有条件的机构可以关注2026年4月开放的新通用顶级域名申请，基于自有顶级域名资源建立完全可控的韧性域名注册管理能力。据了解，国际上涉及到电子金融类业务的公司正在积极筹备第二轮顶级域名申请。
二是升级技术架构：打造高可用、抗打击的解析体系，提升服务连续性和风险控制能力。在互联网侧，不仅要构建高可靠、自主可控的解析系统，更要前瞻性地应对域名篡改、劫持等外部安全风险，确保即使遭遇攻击也能快速恢复，保障在线业务的绝对连续；在内网侧，持续优化DNS运行体系与韧性DNS管理体系。包括DNS整体架构规划、服务连续性的设计、流量调度的设计、安全防护的设计，以及完善满足业务需求的域名规范制度、提升面向业务的运维能力、健全完善的DNS应急方案、确保审计合规等。
三是治理体系：运行管理和注册管理需要同步建设。域名系统的稳定可靠，需要从域名资源管理与技术运行管理两个维度出发，构建自主可控、纵深防御的域名治理体系。
● 域名资源管理：在架构层面，对关键业务推进主备域名设计与多顶级域名布局，构建自主可控的域名空间基础；在监测层面，建立覆盖全球的域名注册观测体系，实现对域名篡改、劫持等风险的实时发现与快速处置；在管理层面，对分散在多个注册商的域名资源实施统一纳管，实现域名的集约化运营与全生命周期可视化管理，全面提升域名体系的整体治理水平与业务韧性。
● 技术运行管理：体系化构建域名系统的可观测能力。企业需具备快速识别DNS解析异常、并将其与普通网络问题区分开来的能力，从而大幅缩短故障定位时间，提升整体运营韧性。包括通过探针、拨测等观测手段，对DNS系统运行稳定性的监控、通过DNS数据分析，对DNS系统运维质量的可观测，对DNS系统一旦发生不可逆转的灾难的应急逃生等。
经过十余年的实践应用，ZDNS从网络空间、资源供给及技术系统三个层面，注册和解析两个环节，帮助用户构建起了多层次、纵深化的防护体系。ZDNS提出，在日益复杂严峻的网络空间中，用户构建韧性DNS，要从资源、技术、管理三个维度协同发力，将自主可控的基础资源、分布式高可用的技术架构、体系化的观测能力融为一体，助力用户真正赢得面向未来的数字韧性。
本文转自“金融电子化”公众号