摘要

  • RIPE NCC 报告，2026 年 11 月 3 日 20:07 至 22:50 UTC，RFC 8181 发布端点无法识别已登记的受委托 CA 发布者，所有发布请求均收到“Unknown publisher”。
  • 维护重启后，Krill 比配置先就绪。原有 RPKI 仓库内容未受影响；工程师修复后，失败的 CA 自动恢复发布。

开门营业，却不认识老客户

RIPE NCC 的事故说明把这次故障说得很清楚。例行维护期间系统重启，存储变慢，发布者配置未能及时供 Krill 读取。进程已经接收请求，却没有登记过的发布者名单。它因此把合法的受委托证书机构当作陌生人。20:07 UTC 开始拒绝，22:50 UTC 才恢复，整整 2 小时 43 分钟。

这里有两套不同的东西。RIPE NCC 的委托 CA 指南允许运营者自己掌握证书机构和私钥，同时使用 RIPE NCC 的发布服务及仓库。CA 生成已签名的 ROA、清单或证书撤销列表，发布端点接收，仓库再向外提供。签名权留在运营者手里，托管与接收由 RIPE NCC 承担。11 月 3 日断掉的是后一个流程的入口。

旧对象没有被擦掉。RIPE NCC 明确说，RPKI 仓库现有内容未受影响，失败的受委托 CA 在修复后自动恢复发布。这两句话应并排读：验证者仍可取得昨天的文件，运营者却不能把今天签好的改动送进去。涉及路由起源授权或证书材料更新时，读取连续与写入连续不是一回事。事故报告没有列出受影响 CA 数量或具体重试对象；单个更新是否延误，需要看该 CA 的发布回执和仓库里的实际对象。

工单关了，入口还没通过考试

RPKI Dashboard 维护记录显示，维护于当日 21:06 CET 标记完成，即 20:06 UTC；另一个事故记录将发布请求失败的起点写为 20:07 UTC。两张记录对应不同服务，事故说明也没有把 Dashboard 工单直接列为故障原因。但这相邻的一分钟足够提醒值班人员：进程启动、维护结束和已登记发布者成功发布，是三种不同的测试。

这次发现故障的不是一盏内部红灯，而是一名会员的报告。RIPE NCC 说，24 小时值班工程师在接报后让正确配置可用，服务随之恢复。它提出两项修正：Krill 启动前必须已有配置，以及加强对 RFC 8181 发布环节的监控。前者改启动次序，后者改发现方式。一个以已登记发布者身份完成的端到端发布测试，才能检查真正的业务路径。

RIPE NCC 的发布服务条款写明了这条 RFC 8181 服务边界。运营者保管自己的密钥，登记机构保管仓库。登记机构若在入口忘掉登记名单，分工在纸面上仍清楚，新的签名对象却到不了读者手里。