NTT 通过夜ly 自动化流程将 RPKI ROA 转换为 IRR route 对象并通过 rr.ntt.net 发布，使现有工具链无需修改即可使用经加密验证的路由源数据，这是向路由生态安全演进的过渡步骤。
转换机制与发布方式：
NTT 运行每夜自动化任务，从 RPKI 仓库获取 ROA，按 RPSL 格式生成 route/route6 对象，经由公开可查询的 IRRd 实例 rr.ntt.net 对外服务。运维人员只需将 bgpq3 或 peval 指向该主机，即可像查询传统 IRR 一样获取带有加密签名来源的路由信息。示例显示，同一前缀 193.0.0.0/21 同时存在 RIPE NCC 原始 IRR 对象与 NTT 转换后的 RPKI 衍生对象，后者在 remarks 中标注来源 URL、maxLength 与 Trust Anchor 等元数据，mnt-by 字段指向 MAINT-JOB，source 标记为 RPKI。
历史背景与先行者：
该思路并非首创。Dragon Research Labs 于 2015 年率先探索，同年 RIPE NCC RPKI Validator 增加 RPSL 导出功能；2017 年 A routeserver 原生支持该方法。原文指出 NTT 可能是首个通过公开 IRRd 实例以 RADB 协议重新发布 RPKI 派生对象的运营商，使下游无需改动流水线即可受益。
数据质量与正确性的区别：
原文强调 RPKI 数据具备“良好质量”——难以被伪造或篡改，但“不等于正确”。质量指授权链的密码学完整性，正确性取决于资源持有者是否准确创建 ROA。转换过程保留原始 ROA 的 maxLength 与 origin AS，若源 ROA 配置错误，衍生的 IRR 对象将继承该错误，工具链仍需配合路由策略做二次校验。
对运维工程师而言，rr.ntt.net 提供了一个零改造成本的切入点：既能沿用成熟的 IRR 查询工具，又能引入 RPKI 的密码学保障。在全面部署 ROV 之前，这种混合模式可作为过渡期的实用补强，前提是明确“可验证来源”不等于“路由合法”，仍需配合前缀长度限制与策略审核。
原文: APNIC Blog（2018-08-01）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog