摘要

  • 一名用户称，RPKI 实验室停机约四天后出现清单证书过期提示，手动发布未改变 Routinator 的结果。
  • 最新回复要求检查日志和机器时间；公开讨论尚未确认原因、修复成功或生产网络影响。

这则求助最值得关注的，不是最初的红色告警，而是尝试恢复之后仍然没有答案。9 月 8 日，NLnet Labs Community 用户回应建议称，已对父级和子级证书颁发机构执行 krillc bulk publish，Routinator 显示的结果依旧。此前系统已经运行了数小时。回复者随后询问 Krill 日志有无异常、机器时间是否准确；截至本次查阅，讨论到此为止。原始讨论。

这是一份实验室自述，不是生产事故通报。用户在 9 月 7 日发帖，称环境曾关闭约四天；附上的日志则标注为 9 月 5 日，报告清单证书过期、没有找到有效清单。发帖日期不能替代日志日期，“四天”也不是通用失效门槛。用户还称，Krill 中父级与仓库相关栏目显示绿色，并有近期交互记录。

因此，能够确认的新闻边界很窄：一个建议的恢复动作被尝试了，但用户没有报告验证恢复。新的对象是否签发、验证器随后取得了哪些内容、时间误差是否相关，公开材料都没有给出答案。询问时钟，不能写成已经查明时钟偏差。

时间为何值得追问，可以从清单规则中理解。RPKI 清单是供验证器检查发布内容的签名文件。RFC 9286 要求在下一次更新时间到来前生成新清单，即使所列对象没有变化；用于验证清单的证书也有有效期。进程重新启动，不会把签名材料中的日期向后推移。RFC 9286。

Krill 当前的 0.16.0 文档说明，批量发布会在需要时创建新对象并同步，通常在启动时及之后每十分钟执行。这说明预期行为，却不能证明实验室使用了该版本，也不能证明有关任务实际完成。仅凭这则求助，无法认定调度器存在缺陷。Krill 命令行文档。

短时重启与跨过凭据有效期的恢复，可能是两种不同的演练。前者可以在所有证书仍然有效时结束；后者才会检验环境能否重新提供当下可接受的签名材料。这是案例提出的验收问题，不是对其根因的判定。

Lu Heng 的 Note 36要求描述现实中的运作结构，而不是替某种立场补齐故事。对这则尚无结论的求助而言，保留未知本身就是报道的一部分。