云端部署 RPKI-RTR 虽然成本极低（年费 12 美分），适合实验验证，但绝不可用于生产环境的 BGP 路由过滤。核心原因在于信任外包与可用性风险：依赖方必须自行校验 PKI 数据，云端服务一旦中断或被篡改，将直接导致路由策略失效甚至破坏路由。
**信任模型要求本地校验**
RPKI 依赖方的职责是对私钥持有者的断言执行密码学验证，并确认 PKI 系统定义的策略约束得到满足。在 APNIC 场景下，这意味着所有互联网号码资源与签名对象必须一致且符合信息模型。这一验证过程不能外包：没有任何第三方应当告诉你“这是有效的”，因为那会将信任外置给外部机构，而基础模型要求你自己完成验证。BGP 路由决策是本地定义的——你的 BGP、你的路由、你所见与所行，与他人不同，因为它属于你。
**云端依赖带来的可用性隐患**
将验证状态托管在云端存在两重风险。首先，你无法确证云端验证状态未被他人篡改；即便使用私有云节点，云服务商仅提供有限的数据隔离保证，你仍需证明对数据拥有唯一控制权。其次，网络中断会导致 RPKI 信息库不可见：本地路由过滤将如何反应？运维告警能否及时触发？是否会引发路由崩溃？原文未给出具体故障案例数据，但逻辑明确——外部服务不可达等同于验证能力丧失。
**核心架构内部署至少一个实例**
若网络运营中心（NOC）与核心路由资产处于 7×24 小时监控之下，在核心路由架构内部署至少一个 RPKI-RTR 实例，可显著降低风险面：外部服务失效时，内部实例仍能提供验证数据，保证路由决策不被拒绝信息。反之，若云端主机处于错误的 RPKI 状态（例如错误地标记无效路由为有效），并配合“丢弃无效路由”策略，将直接导致合法路由被错误丢弃，后果不可控。
对运维与网络工程师而言，结论明确：云端 RPKI-RTR 仅作实验测试，生产环境必须在自管核心网络内运行验证实例，保持对验证链路的独占控制与不间断可达性，才能确保 BGP 路由过滤的正确性与鲁棒性。
原文: APNIC Blog（2020-05-05）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog