故障点
以下是来自 Uptime Robot 的遥测记录, 其反映了本站服务在全球范围内的大致存活情况.
| start date-time | end date-time | reason | duration | duration (seconds) | monitor URL | monitor name |
|---|---|---|---|---|---|---|
| 2025/12/20 22:04 | 2025/12/20 22:20 | DNS Resolving problem | 15m 25s | 925 | https://ai.itedev.com | AI Platform |
| 2025/12/20 21:43 | 2025/12/20 21:53 | DNS Resolving problem | 10m 18s | 618 | https://ai.itedev.com | AI Platform |
| 2025/12/20 21:22 | 2025/12/20 21:27 | DNS Resolving problem | 5m 8s | 308 | https://www.itedev.com | Blog |
| 2025/12/20 21:06 | 2025/12/20 21:11 | DNS Resolving problem | 5m 8s | 308 | https://www.itedev.com | Blog |
| 2025/12/20 20:46 | 2025/12/20 20:56 | DNS Resolving problem | 10m 30s | 630 | https://sso.itedev.com/ | SSO |
| 2025/12/20 20:23 | 2025/12/20 20:28 | DNS Resolving problem | 5m 14s | 314 | https://sso.itedev.com/ | SSO |
| 2025/12/20 20:19 | 2025/12/20 20:44 | DNS Resolving problem | 25m 37s | 1537 | https://download.docker.com.mirror.itedev.com/ | Mirror(download.docker.com) |
| 2025/12/20 20:18 | 2025/12/20 20:34 | DNS Resolving problem | 15m 21s | 921 | https://ai.itedev.com | AI Platform |
| 2025/12/20 20:00 | 2025/12/20 20:15 | DNS Resolving problem | 15m 19s | 919 | https://memos.itedev.com/ | Memos |
| 2025/12/20 19:56 | 2025/12/20 20:01 | DNS Resolving problem | 5m 8s | 308 | https://download.docker.com.mirror.itedev.com/ | Mirror(download.docker.com) |
| 2025/12/20 19:17 | 2025/12/20 19:23 | DNS Resolving problem | 5m 10s | 310 | https://memos.itedev.com/ | Memos |
| 2025/12/20 19:14 | 2025/12/20 19:19 | DNS Resolving problem | 5m 7s | 307 | https://download.docker.com.mirror.itedev.com/ | Mirror(download.docker.com) |
| 2025/12/20 18:56 | 2025/12/20 19:01 | DNS Resolving problem | 5m 10s | 310 | https://memos.itedev.com/ | Memos |
| 2025/12/20 18:24 | 2025/12/20 18:35 | DNS Resolving problem | 10m 28s | 628 | https://sso.itedev.com/ | SSO |
| 2025/12/20 17:59 | 2025/12/20 18:04 | DNS Resolving problem | 5m 10s | 310 | https://www.itedev.com | Blog |
| 2025/12/20 17:56 | 2025/12/20 18:01 | DNS Resolving problem | 5m 11s | 311 | https://memos.itedev.com/ | Memos |
| 2025/12/20 17:53 | 2025/12/20 17:58 | DNS Resolving problem | 5m 6s | 306 | https://download.docker.com.mirror.itedev.com/ | Mirror(download.docker.com) |
| 2025/12/20 17:46 | 2025/12/20 17:56 | DNS Resolving problem | 10m 25s | 625 | https://sso.itedev.com/ | SSO |
以下是 L1nSn0w 同志在 Ech0 开发群给出的直接反馈.
以及故障期间用于 CNAME 接入的域名的 itdog 遥测记录.
根据这三点, 可以判断是本站的服务出现故障了.
起因
我因不满原第二 DNS 提供商 DNSPod 提供的免费 DNS 解析服务, 拟迁移到华为云解析, 并于 2025/12/20 16:50:20 GMT+08:00 开始这一计划, 具体的考虑如下.
| DNSPod | 华为云 DNS |
|---|---|
| TTL 最低值: 600 秒 | TTL 最低值: 1 秒 |
| 不支持免费启用 DNSSEC | 支持免费启用 DNSSEC |
| 不支持免费自定义线路 | 支持免费自定义线路 |
| 无免费反解 | 免费反解 |
| 不能免费设置国内各大区的解析记录 | 可以设置国内主要区域的解析记录 |
在从 DNSPod 迁移前, 我已经在华为云配置好所有记录, 并且准备了 DNSSEC(很讽刺的一点是, 本次迁移计划为无停机迁移). 在 Cloudflare 替换 NS 记录, 并添加 DS 记录后, 故障出现. 主要表现在境外的机器无法解析 CNAME 到 official.platform.cname.itedev.com 及 epitaph-api.platform.cname.itedev.com 的所有域名, 境内一切正常.
经过
最开始, 我以为这只是缓存的问题, 还在思考为何这次的事情如此诡异, 并打算给它几小时.
发现这真是个故障后, 我根据华为云官网给出的内容:
DNS服务器地址设置建议
由于中国大陆的国际出口带宽有限，用户在中国大陆和中国大陆之外国家或地区之间跨地区访问时，会出现网络时延增大的现象。
因此，对于公网域名的NS记录集设置，建议您：
- 如果您的网站用户主要集中在中国大陆，设置DNS服务器地址为：ns1.huaweicloud-dns.com、ns1.huaweicloud-dns.cn。
- 如果您的网站用户主要集中在中国大陆之外国家或地区，设置DNS服务器地址为：ns1.huaweicloud-dns.net、ns1.huaweicloud-dns.org。
- 如果您的网站用户遍布全球，同时设置上述四个DNS服务器地址。
怀疑这是受晚高峰或者华为云自身问题的影响, 且 Uptime Robot 提供的时活时死的反馈, 更佐证了我的判定. 于是我向华为云方面提交了工单, 并很快收到电话辅助处理(这点我表示赞赏, 且 7*24 的处理特别适合我这种夜猫子的工作).
此时的我, 并未意识到事情的严重性, 于是将 Cloudflare 的 NS 改回 DNSPod, 并暗自祈祷服务可以恢复.
然天不随人意, 事情并未向我预想的方向发展, DNS 解析仍然是炸掉的状态.
于是, 我开始怀疑起一个最不起眼的小按钮(至少在华为云, Cloudflare 都是小按钮): DNSSEC, 并尝试删除 Cloudflare 的 DS 记录.
在删除了一条 DS 记录后, 对应域名的境外解析恢复, 于是我对其他的域名执行了相同的操作, 并在确定服务稳定后以关闭 DNSSEC 的状态回迁华为云.
结果
皆大欢喜, 用 AI 的话来说就是:
🎉 任务完成！
享受下班时间！系统运行稳定优化。🚀
故障解决了, 一切重回正轨, 待有问题的缓存过期, 一切恢复如初.
分析
关于工作流的反思
这一次, 最主要的问题是对自己技术能力的过度自信. 在未经测试的前提下, 就使用了全新的配置与内容. 有句话说得好:
Stay Hungry, Stay Foolish.(中翻: 求知若饥, 虚心若愚.)
即使假设我是最天才的运维, 我能保证我的行为不出差错吗? 不可以! 这正是我们生而为人的特点, 我们是人不是机器. 而工作流程的设计, 则旨在把人的不确定性降到最低. 我是个人开发者, 我的工作流程, 很大程度上, 需要”慎独”.
慎独, 这是一个初中课本提出过的概念, 通俗来说, 就是在没有人监督的情况下, 仍守住规矩. 使用一个极端的假设, 你性欲大发, 而恰好此时世界上的人都消失了, 只剩下你和你想泄欲那个人. 此时, 泄欲即为逾矩, 克制既是慎独. 而作用在工作流里, 即自己能否长久的坚持这一套规矩.
很明显, 我没有, 我直接略去测试.
对于受影响的各方, 包括我自己, 我致以诚挚的道歉. 这件事, 在我内心的影响也不小.
辩证一直是我的传统, 如果说要对这件事情辩证看待的话, 仍引用一句话, 即使它用在这里可能不怎么恰当.
If I try my best and fail, well, I tried my best.(机翻: 如果我尽力而为却失败了, 好吧, 我尽力了.)
对于我本人, 我能没有”深度思考”的做一个决定, 也是一个可喜可贺的进步. 具体详见 About 中的小插曲, 关于这点, 我不想过多赘述, 因为这是一篇故障报告.
我没有了解清楚 DNSSEC 配置错误造成的影响, 算是”涉世未深”.
技术层面的分析
关于这一点, 我们要扯一些标准:
RFC 4035 Section 4.3：存在 DS 但无法验证 DNSKEY → 返回 SERVFAIL。
RFC 4035 Section 5：如果 DS 存在但子 zone 未正确签名 → Bogus。
RFC 6840：澄清了早期实现中的 DS/DNSKEY 匹配问题，要求严格哈希验证。
关键原因是这个 SERVFAIL .
由于特别的需要, 我需要在子域名的 @ 使用 CNAME 记录. 再扯一些标准:
RFC 1034 Section 3.6.2（CNAME 独占规则）： “If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.” （如果节点存在 CNAME RR，则不应存在其他数据，以确保规范名与别名的数据一致。）
RFC 1912 Section 2.4（CNAME 共存强调）： “A CNAME record is not allowed to coexist with any other data.” （CNAME 记录不允许与其他任何数据共存。）
华为云严格遵守 RFC(我欣赏他们的行为), 所以不会为我设置了 CNAME 的 @ 设置 DNSSEC 有关条目. 但是:
RFC 2181 Section 10.1（早期澄清，DNSSEC 初步例外）： “An alias name (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no other data.” （如果使用 DNSSEC，别名可伴随 SIG、NXT 和 KEY RR，但不得有其他数据。）
RFC 4034 Section 2.3 & 4（DNSSEC 资源记录定义）： “This is a change to the traditional DNS specification [RFC1034], which stated that if a CNAME is present for a name, it is the only type allowed at that name. A RRSIG and NSEC MUST exist for the same name as a CNAME resource record in a signed zone.” （这是对传统 DNS 规范的修改；在签名区域中，CNAME 必须伴随 RRSIG 和 NSEC。）
RFC 4035 Section 2.5（CNAME 定义修改）： “This is a modification to the original CNAME definition given in [RFC1034]. […] To resolve this conflict, this specification modifies the definition of the CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.” （修改 CNAME 定义，以允许其与 NSEC 和 RRSIG 共存，因为签名区域要求每个权威名称都有这些记录。）
NSEC3 支持（RFC 5155）： 对于使用 NSEC3 的签名区域，CNAME 同样必须伴随 RRSIG 和 NSEC3（而非 NSEC），规则相同。
这仍是我在推敲的问题.
后记
如果各路高人有何高见, 欢迎勘误并与我交流. 2025 年末我事情很杂很多, 可能不会及时回复.