阿里云域名解析被转移，让我穿越回了 15 年前

2025 年 6 月 6 日早上 6 点 10 分醒来，习惯性瞄了下手机，看到同事给我的留言，大概是说 aliyuncs.com 被别的国家注册了

作为一名曾经的域名管理员，我对域名类的故障是比较 敏（害）感（怕） 的，因此基本上我是短时间就清醒了的，抛出了我的第一个疑问：在用的域名忽然被别人注册了？

同事反馈是过期没续费被抢，但是 域名过期是有保护期 的，所以我并没有接受这个说法，在手机上通过 who.is 查了一下信息，发现过期时间是 2026-04-01，既然都还没有过期，那被别人注册了这个说法自然是不成立的。

继续追问了下目前可能对我们公司业务的影响，了解到如果负载均衡 LB Load Balance 有可能直接用了阿里的域名，这下我就不太淡定了，继续用 itdog 试了一下，发现有个别缓存开始失效了。结合可能对我们的影响，这下真的无法淡定了，立马起床开电脑干活！！

考虑到 whois 也会有缓存，赶紧登录自己在欧洲的一台机器重新查了一下，果然发现阿里 aliyuncs.com 的域名被人更新了（而不是被别人注册了），可以看到更新时间是 2025-06-05T21:32:38Z ，考虑到时区，和阿里通告故障的时间是基本对的上，域名、whois 都会有缓存，有一定时间差是符合常理的。

这个时候肾上腺激素开始飙升了，立马让在线的同事开工干活，主要几个动作：

  1. 第一时间把涉 aliyuncs.com 的域名捞出来，并整理成共享文档，供接下来使用；
  2. 唤醒公司域名管理员，对于我们自建 DNS 这个服务本身，如果使用了阿里 LB 的且评估是对其他业务提供服务的，马上切走。（如果我们的 DNS Server 受这个 LB 影响不可用了，这个时候爆炸半径会直接无限扩大）
  3. 域名管理员，发起紧急变更，将缓存 DNS 服务器上关乎 aliyuncs.com 这个域名的解析全部转发劫持到阿里云的权威，确保内部业务能正常解析，尽可能缩小爆炸半径；
  4. 根据服务等级，除了在相关工作群通告外，根据服务重要等级唤醒相应运维（或相应域名对应的管理员），并让他们安排将 aliyuncs.com 的业务先切到 VIP 地址；

中间还是会有一些小插曲，比如可能指引不够详细，有运维同学对于域名没有概念或者有同学所涉业务较多，有点手忙脚乱之外，整体还算快速、稳步的推进，更多的细节就不展开了。

当然，这里最终还是要给阿里云的团队点个赞，原以为这个故障时间会远超预期，然后我们在北京时间 08:14 收到反馈说经过阿里云团队的处理，域名解析开始恢复正常了，故障持续的时间大约为 6 小时左右。再加上故障发生在凌晨，另外域名解析的失效也有一个缓存的过程，不幸中的万幸就是我们基本没有受到影响（但是对不起，炸了一群人起来干活 :p

基本没有，也不是完全没有，但都在可控范围内 :-)

15 年前的鬼故事

在响应这个故障的过程中，就有同事问我是不是我们曾经也出现过这个问题，很肯定的说“是”，但也不是，情况不太一样。在这个时间点，我对于阿里云为什么 NS namesever 被改了还是不清楚的，只是猜测大概率是管理不善，帐号被黑客拿走改了 NS 之类~~ 而我们当年（约 15 年前）碰到的一个情况是被注册商（比如万网、NetworkSolutions）以涉敏感内容为由停止了解析，但阿里云 aliyuncs.com 的症状对不上。

说明一下，涉敏感内容肯定和公司没有直接相关，不展开，避免被有心之人用来作为攻击手段，也不确认该方式是否还有效

当时也是发生在凌晨（时差，美国佬刚好上班之类），年轻睡的晚，本来也想睡觉了，鬼始神差的觉得好像不太对劲，开电脑查了一下发现解析被停掉了，多次用我鳖脚的英文和 NetworkSolutions 对线（感谢那时候有 Skype 等软件可以打国际电话），辗转折腾，在多路大佬的帮助下也是差不多在白天业务高峰前才恢复解析，但毕竟是我们的核心域名，加上时间也是大几个小时，不少地方的缓存失效了，影响还是很大的（最后被某位大佬点赞了 hhhh

说说我的害怕

前面说到作为一名曾经的域名管理名，我对域名类的故障是比较敏（害）感（怕）的，这是为什么呢：

  1. DNS 是互联网最基础的业务之一，但凡在互联网上能提供的业务大概都离不开这个基础。越是基础的东西伤害就越大；
  2. 基础的服务受关注程度低，大家都默认你正常，所以确实出问题的概率也极低，因为你不敢经常出问题。但带来的问题是所有上层业务都默认你正常，在设计的时候就不会去做过度容灾，一出问题短时间就是解决不了（但确实有时候为了一个极低概率出问题的系统做过度的容灾，不考虑 ROI 也是有毛病的表现 。。。
  3. 因为 1 和 2 的情况，业务和业务，经年累月下来，你根本改不了。就像现在，你不可能拿出一套系统取代 TCP/IP、取代 DNS，哪怕 IPv4 要进化到 IPv6，这个我从读大学就被这么画大饼了，20 多年过去了，也没见 IPv6 就把 IPv4 干掉了
  4. （价值论）通常在大多数公司里，基础服务的价值讲不清楚，上层建筑容易画大饼讲故事，也有快速创造收益的可能。像我这种做基础设施的，都要经常停下来反思我这点收入真是得之不易，劳心劳命的，然后给自己找到自洽的逻辑，继续努力~
  5. 域名的爆炸半径不可控，一方面是因为我们不可能去刷新世界上所有的缓存（运营商大多数情况下也不会鸟你），同时我们也没有办法让用户在出现故障时，让他们切换到另一个域名（如 HttpDNS 等方案这些都只能解决特定场景下的特定问题），另外 缓存是个双刃剑，它能延缓故障的爆炸，却也会让你在宣告解析恢复后要经受不停的挑战，为什么我的服务一直没有恢复？就像这次我们 直到北京时间 13:57 才收到业务反馈说运营商的缓存基本都过期不再报错了，大概是阿里云宣告恢复后的又一个 6 小时

当然，你也可以认为我过度紧张 :-)

小结

  • 阿里云此次 aliyuncs.com 的故障真实原因是什么？这个我也不知道，但从网络上的蛛丝马迹上看是被 VeriSign（不是注册商，是 .com 顶级域的管理）改了域名解析，不考虑更深层次更腹黑的原因，只能猜测是因为阿里云有不合规的内容被投诉了之类。如下一些公众号的猜想：

  • 作为域名的拥有者，有没有可能完全杜绝这个问题？我认为不可能， 这次看起来是 VeriSign 操刀的，也就是直接绕开注册局（商）了。包括有些朋友可能会认为加一些注册局锁（类似 serverUpdateProhibited 这些）可能可以缓解，我可以很肯定的说这 只能解决到注册局层面的问题，覆盖不了本次的情况 。当然阿里云做为一家国际云商， 注册局锁这点钱你们就不要省啦 （事后也看到阿里云加上了）：

  • 技术上能不能解决：能，但成本不知几何。鼓励大家在业务上线的时候通过多入口容灾、引入 HttpDNS 等技术解决类似问题，但是当类似问题出现时，影响还是不可避免，手忙脚乱也还是不可避免，毕竟 N 年等一回，但最好一回也不要有，害怕
  • 可能有其他非技术非常规手段，可以从根服务器、顶级域名运营商开始实施保护，但想像不了了，请了解规则的朋友指点哈

您可能还喜欢以下文章


关于我

热爱开源、分享。目前主要从事混合云、数据库 SaaS 等运维开发及相关团队管理工作。