DNS故障复盘：一次错误的DNS记录如何导致网站访问失败？

时间：2025-09-19

编辑：tance.cc

《故障复盘：一次由DNS解析变更导致的网站大范围访问失败》

欢迎来到我们第一次正式的“故障复盘”（Incident Debrief）会议。今天我们要复盘的这个案子，档案代号为“迷失的地址”。这是一个非常经典的案例，它讲述了一个小小的、看似无害的配置失误，是如何像多米诺骨牌一样，最终导致一个流量巨大的线上业务，在全球用户面前“人间蒸发”了近一个小时。

这个故事，每一个网站管理员，都应该听一听。

事件背景：一次平平无奇的服务器迁移

我们的故事，发生在一个周五的上午。按照计划，技术团队需要将一个重要业务的网站，从旧的A服务器，迁移到性能更强劲的B服务器。

整个过程本该如丝般顺滑：在B服务器上部署好网站 -> 测试通过 -> 修改DNS解析，将域名指向B服务器的IP -> 任务完成。

这是一个教科书般的操作，我们已经演练过无数次。

警报响起：“休斯顿，我们出问题了！”

[10:00 AM] - DNS变更操作窗口开启。运维工程师在DNS服务商的后台，将www.our-awesome-site.com的解析，从旧IP 1.1.1.1，修改为新IP 2.2.2.2。

[10:05 AM] - 操作完成。工程师在自己的电脑上访问网站，一切正常。他在发布群里打出了一个“OK”的手势。

[10:10 AM] - 灾难开始。 我们的监控系统，突然拉响了第一声警报：HTTP监控任务 “官网首页-新加坡节点”，连续3次失败，失败原因：连接超时。

[10:11 AM] - 未等我们反应过来，告警风暴来临。东京、法兰克福、弗吉尼亚……全球各地的HTTP监控节点，接二连三地转为红色。

[10:13 AM] - 客服团队的Slack频道开始“爆炸”，涌入了大量来自不同国家的用户反馈：“网站打不开了！”

[10:15 AM] - 后台的实时销售数据大盘，那根代表着收入的曲线，从一个陡峭的山峰，瞬间跌落悬崖，变成了一条死寂的、紧贴着0轴的水平线。

那一刻，控制室里每一个人的心，都和那根曲线一样，沉到了谷底。

初步排查：“犯罪现场”的勘查

在重大故障面前，最忌讳的就是像无头苍蝇一样乱撞。我们需要一个清晰的、由表及里的排查思路。

第一步：服务器还“活着”吗？

嫌疑人： 新的B服务器，是不是根本就没启动好，或者直接宕机了？
侦探工具： PING监控 和 手动PING
行动： 我们立刻查看PING监控的历史图表，同时在自己的电脑上 ping 2.2.2.2。
证据： PING监控显示，B服务器的IP在全球范围内的延迟稳定在健康的范围内，丢包率为0%。我们手动PING，也得到了快速、稳定的响应。
初步结论： 服务器本身是健康的。 我们的“飞船”引擎还在正常轰鸣。

第二步：网站服务“清醒”吗？

嫌疑人： 服务器虽然活着，但上面的Web服务软件（Nginx）是不是崩溃了？或者网站代码出错了？
侦探工具： SSH远程连接 和 本地cURL
行动： 运维团队立刻通过SSH，成功登录到了新的B服务器内部。
证据：

systemctl status nginx 命令显示，Nginx服务状态为 active (running)。
在服务器内部，执行 curl localhost 命令，成功地返回了网站首页那熟悉的HTML代码。

初步结论： Web服务和应用程序都是正常的。 飞船内部的“宇航员”们，正在自己的岗位上正常工作。

好了，现在案件变得诡异起来。

飞船本身动力十足，宇航员也一切正常。但是，来自地球的、成千上万的“通信请求”，却都神秘地消失在了太空中。

一个经验丰富的指挥官，此刻会立刻意识到问题的方向：这不是飞船本身的问题，这是“寻址系统”和“通信线路”的问题！

突破口：“全球情报网”发回的关键线索

我们需要立刻知道，全世界的“地面基站”（各地的DNS服务器），到底是如何“看待”我们的新地址的。

侦探工具：观图数据的【DNS查询】

我们立刻打开观图数据的DNS查询功能，输入我们的域名 www.our-awesome-site.com，并选择从“所有运营商”节点进行查询。

几秒钟后，一份来自全球的“情报汇总”呈现在我们眼前。那一刻，我们所有人都倒吸了一口凉气。

正常的预期结果应该是：

所有节点的查询结果，都应该是一条 A记录，指向我们新的服务器IP 2.2.2.2。

但我们看到的实际结果是：

北京电信的节点，返回的是 2.2.2.2。（正确）
上海联通的节点，返回的是 2.2.2.2。（正确）
广东移动的节点，返回的却是我们那个早已下线的旧服务器IP 1.1.1.1！
海外节点的结果，更是五花八门，新旧IP地址的比例大约是一半一半。

真相大白了。

问题，就出在DNS解析上。由于某种原因，我们发布的“迁徙新地址”的指令，并没有被全球所有的“交通枢纽”（DNS服务器）正确接收。一部分用户被引导到了正确的新服务器，而另一部分，则被错误地引导到了那台早已人去楼空、服务关闭的旧服务器上。

这就像你搬家后，去派出所改了地址，但系统出了问题，导致只有一半的快递员收到了新地址，另一半还在往你的旧房子送快递。

追根溯源：致命的那一行“幽灵记录”

为什么会发生这种“部分生效”的诡异情况？

团队立刻重新登录了我们的DNS服务商后台，逐一排查our-awesome-site.com这个域名下的所有解析记录。

很快，我们就找到了那个“魔鬼”：在几十条解析记录中，隐藏着一行我们所有人都忽略了的、由市场部同事在一个月前为了做某个邮件营销活动而添加的、指向旧服务器IP 1.1.1.1 的泛解析记录：*.our-awesome-site.com。

在上午的变更操作中，运维工程师只修改了 www 这条记录，却没有删除这条更宽泛、也可能造成冲突的*泛解析记录。

这导致了不同地区的DNS服务器，在更新缓存时，出现了“解析混乱”。有的服务器优先识别了我们新的www记录，而有的，则依然被那条“幽灵般”的泛解析记录所困扰。

拨乱反正：修复与反思

[10:45 AM] - 紧急修复

行动： 定位到问题后，修复动作快如闪电。我们果断地删除了那条多余的*泛解析记录，并再次确认了www记录的正确性。
煎熬的等待： 但我们知道，战斗还没有结束。我们现在必须等待全球的DNS缓存，慢慢地“遗忘”掉那个错误的记录。幸运的是，我们在执行变更前，已经明智地将TTL值调低到了300秒（5分钟）。

[11:15 AM] - 业务恢复