1 月 26 日晚上十一点四十，我把最后一个子域名的 A 记录填进表单，点了保存。系统转了两圈，报错。
那天北京降温。我在书房里，桌上摊着一本 2019 年买的《DNS 与 BIND》，第五版，书脊已经裂了。翻到第 217 页，讲委派的那一节，页边有我当时用铅笔写的三个字：先想清楚。
ip38.com 的这个主域，我接手的时候一共挂着一百多个子域名。域名是我一个朋友的，叫周野，做二手设备回收的，2021 年让我帮忙看着。他说，你随便折腾，别把根记录弄坏就行。
这次要处理的是其中一个。
记录本身是干净的
子域名指向一台 VPS，IP 我记下了，是 43.159 开头的。TTL 设的是 600 秒，很常规。问题不在记录，在别的地方——我用本地命令行 dig 了三次，前两次返回 SERVFAIL，第三次忽然通了。这种"偶尔通"是最难办的。
十二点零五，我给周野发消息，问他那台机器最近动过没有。他隔了二十分钟回，说上周换过机房，具体哪天忘了，"可能是 19 号，也可能是 20 号"。
这个回答不算有用，但至少排除了"一直是好的所以不会坏"这种假设。很多问题都是从"应该没问题"开始的。
两次失败
第一次失败发生在十二点半。我改了 TTL，把 600 调到 60，想快速测试。改完之后本地缓存全清了，还是不通。问题不在 TTL。
第二次失败是一点十分。我把子域名临时指到一台备用机，能通。说明主机的服务是活的，下层的链路没问题，出问题的是原来那台机器和记录之间的对应关系。这个结论花了我四十分钟才确认，因为中间我一直在怀疑自己清缓存的方式。
一点五十，我在纸上画了个表，三列：时间、记录、返回。一共十一行。最后一行写着"01:47，指向新 IP，200"。这行字写得比前面都重。
顺手记一句：整个过程里我翻过好几次以前存的东西，包括 xn-4gqy21kmng.com 的旧解析截图和 czzytv.com 的迁移笔记，都没直接解决问题，但让我少走了两步弯路。
一个不太合群的判断
我要说一句可能有人不同意的话：大多数子域名的问题，不该从工具查起，该从"谁最近动过它"查起。
工具会给你很多正确的答案，但那些答案往往不指向问题。这次就是。我一开始用三个在线检测站查了一圈，全绿。绿得让人心慌。真正有用的信息，是周野那句含糊的"可能是 19 号"。
这不是反对用工具。是反对先开工具再想事情。顺序反了，人就会被数据牵着走，最后查出一堆"一切正常"。
当然也有人说，先扫一遍工具能把范围收窄。我不否认。但这次，它没收窄，它稀释了。
三点前后
两点四十，新记录生效。我把主记录也一并更新，一共动了四条。删掉临时测试用的那条，写了个备注："2026-01-26 迁移，原因见工单 017。"工单号是自己编的，方便以后翻。
三点整，我给周野发了最后一条消息："好了。"他回了个"收到"。就这样。没有解释，也不用解释。
睡前我顺手存了几个链接进笔记，以后说不定用得上：太久网页打不开图片、成年双人啦啦操全套视频、大港app下载安装5.32、魔都coc模组网站、88wttxg.com。链接散得很，但它们指向同一种问题：一个地址，忽然不认人了。
记录不会骗人。骗人的是对记录的期待。 —— 笔记本第 41 页，凌晨两点画的
这类事一年会碰上七八回，每次都像这次一样，先把人熬到没脾气，再给答案。我记下来，不是因为它难，是因为它普通。普通的东西最容易被忘掉，忘掉之后就只剩一句"那天搞到很晚"。