今天上午，多个技术社群不约而同地讨论起网站故障问题，比如有开发者反馈博客园（cnblogs）访问大面积异常。追根溯源，发现问题竟出在阿里云身上。
根据阿里云官方健康状态页显示，北京时间2025年6月6日凌晨02：57，阿里云监控系统发现了异常。官方给出的最新进展是，到早上08：11，解析异常问题已完成修复。
此次事件的“震中”是 aliyuncs.com 这个核心域名。对于所有使用过阿里云服务的用户而言，这个域名都再熟悉不过——阿里云众多核心服务的默认访问端点都构建在其子域名之下。例如，对象存储OSS、容器镜像服务等，都依赖 *.aliyuncs.com 格式的域名进行访问。
因此，aliyuncs.com 的域名解析一旦出现故障，其影响范围之广可想而知。这不仅是单个服务的不可用，而是波及到一系列依赖该根域名的云产品生态。更棘手的是，由于各地DNS缓存的存在，故障的实际影响时长往往远超官方公告的修复时间。有技术人员实测发现，直到故障通报“已修复”数小时后，海外部分地区对 aliyuncs.com 的解析依然异常，被指向了 sinkhole.shadowserver.org，这很可能就是缓存尚未刷新的结果。
一时间，关于故障原因的猜测四起。有网友在微博上爆料，称此次故障是因为域名被“拿走”（劫持），解析指向了SS（Shadowserver）。
这里简单解释一下，Shadowserver Foundation 是一家国际非营利安全组织，它的一项重要职能是协助执法机构和网络监管方处置恶意域名。其手段之一，便是将已被认定为用于恶意活动的域名解析指向其控制的“陷阱服务器”（Sinkhole Server），从而截断恶意流量。这个过程，可以形象地理解为“赛博拖车”——将“违法车辆”（恶意域名）拖入专用停车场。
面对突发故障，一线运维工程师和客户们最先感受到压力。在技术社区 V2EX 上，有用户分享了来自阿里云的官方“止损”建议，而帖子下的讨论也真实反映了当时的紧张与无奈。
讨论中提及的“止血”措施，包括建议用户将本地 LocalDNS 服务器指向 223.5.5.5 或 223.6.6.6（阿里云公共DNS），对于使用负载均衡（ALB/NLB）的服务，建议将域名的 CNAME 记录临时改为指向 VIP 地址的 A/AAAA 记录，或者直接修改客户端 hosts 文件进行强制解析。这些都是在DNS权威解析出现问题时，从递归解析或本地解析层面进行绕过的常见应急手段。
无论最终的根本原因为何，此次 aliyuncs.com 域名解析异常事件，无疑是一次影响深重的云服务故障。它再次提醒所有依赖云服务的企业和开发者，那些被视为基础设施“基石”、理论上最不可能出问题的环节——比如顶级域名的解析——也存在潜在风险。这起事件也为云时代的架构设计和灾难恢复预案敲响了警钟。
对于技术从业者而言，每一次重大故障都是一次宝贵的学习机会。我们可以在云栈社区的运维 & 测试板块，与更多同行交流高可用架构设计和应急响应的实践经验。
References
[1]：阿里云官方事件详情页：https://status.aliyun.com/#/eventDetail?eventId=27 | 
发表于 2 小时前
|
查看: 2|
回复: 0
