摘要

  • RFC 9558 把 DNSSEC 算法 23 分配给 GOST R 34.10-2012，把 DS 摘要类型 5 分配给 GOST R 34.11-2012，并限定了精确的密钥、签名与摘要格式。
  • 它是 Independent Submission 流的 Informational 文档，没有 IETF 共识；文档也明确不为算法适用性、实现价值或部署效果背书。
  • 可信结论必须连接注册、签名器支持、权威发布、父区 DS、验证器能力、链验证、解析器状态与应用观察等独立凭证。

父区的 DS 没错，用户的解析器却没有这条路

设想一个运营者完成了看似完整的上线：子区发布算法 23 的 DNSKEY，RRset 带有格式正确的 GOST R 34.10-2012 RRSIG，父区也发布摘要类型 5 的 DS。实验室里的工具能够从信任锚一路验证下来。

用户使用的另一台递归解析器却不支持这套算法。按照 RFC 6840 对 DNSSEC 的处理规则，它会忽略使用未知或不受支持的密钥算法、摘要算法的已认证 DS。如果没有其他可用路径，子区会被当作未签名，而不是因为某个签名被证明为伪造。

记录都在那里，编号也完全合法，结论仍然不同。差异来自运行代码的能力。这正是 RFC 9558 最值得管理者理解的边界：注册使对象可命名，只有部署才使路径可执行。

RFC 的出版身份本身就是证据字段

RFC 9558 于 2024 年 4 月以 Independent Submission、Informational 身份发布。它不是 Internet Standards Track 规范，没有 IETF 社群共识，也不获 IETF 标准流程背书。RFC Editor 明确表示，出版不等于对实现或部署价值作判断。

文档还写得更窄：GOST R 34.10-2012 与 GOST R 34.11-2012 是俄罗斯国家标准，其密码学性质没有在这里得到独立验证；IETF 与 IRTF 都没有分析它们对任何具体应用是否适用。

这不等于否定任何采用者，而是限定可以说什么。RFC 9558 能让主动选择这套算法的人对同一组字节形成共同理解，不能把“收录于 RFC”改写成“IETF 推荐”。风险批准、采购记录和技术清单都应保留这个出处。

64 个八位字节容不下含糊

RFC 9558 选择 256 位签名变体、256 位摘要变体和参数集 A。椭圆曲线点 Q=(x,y) 在 DNSKEY 中占 64 个八位字节：先是 x 的 32 字节小端表示，再是 y 的 32 字节小端表示。公钥与签名各为 512 位，摘要为 256 位。

字节序不是排版细节。库中的数学点可以正确，写入 DNS 的序列仍可能错误。为连接现有 GOST 感知的 X.509 API，RFC 给出固定 30 字节 ASN.1 SubjectPublicKeyInfo 前缀。它只是格式适配器，不是证书、信任锚或授权书。

RRSIG 对 RFC 4034 规定的签名输入采用 GOST R 34.11-2012 摘要，再用 GOST R 34.10-2012 签名。示例公开伪随机整数 k，只为复现测试向量，并明确禁止用于真实签名。复现成功证明实现与一个样例一致，不证明生产随机数安全。

两个编号连接的是不同边界

IANA 把 DNSSEC 算法 23 记为 ECC-GOST12，把 DS 摘要类型 5 记为 GOST R 34.11-2012，状态为 OPTIONAL。算法编号告诉验证器怎样解释 DNSKEY 与 RRSIG；摘要类型告诉它怎样把父区 DS 与子区 DNSKEY 对上。

一个正确对象不能替代另一个。没有可用 DS 的有效 RRSIG 不能建立父子链；验证器不支持算法时，完全匹配的 DS 也没有可执行路径；即使软件支持，两处缓存观察到不同版本，仍会产生时间窗口中的分歧。

因此审计记录至少要保存精确的 DNSKEY、RRSIG 与 DS RRset，父区和子区观察点，区域 serial，签名生效与过期时间，TTL、信任锚、验证器版本和算法清单。“DNSSEC 已开启”没有足够的信息用于复盘。

不支持与 Bogus 不是同一种失败

RFC 6840 的区别至关重要。若已认证的 DS RRset 里没有任何验证器支持的密钥算法或摘要算法，验证器会把相关记录忽略；路径全部消失后，区域按未签名处理。Bogus 则表示本来应该验证的路径未通过检查。

把二者压成一个红灯，会让事故处置朝错误方向前进。团队可能反复重签名，而真正缺少的是解析器软件中的实现；也可能以为只是兼容性问题，实际却是受支持路径上的签名损坏。

可复核的问题应是：哪一台验证器、哪个版本、哪些已启用算法、哪组 RRset、哪个信任锚、何时返回了什么安全状态。一次成功的命令行测试不能代表整个递归解析器群体。

双 KSK 是迁移桥，不是简化开关

RFC 9558 建议在 GOST 感知软件尚未广泛部署时，让区域使用双 KSK 算法签名，除非运营者明确只采用 GOST。第二条路径可以让不支持算法 23 的验证器仍然完成认证。

代价是更多必须对齐的状态：多把 KSK、多条 DS、多组签名、各自的有效期、父区发布时间、缓存和撤除顺序。RFC 6840 建议只要有一条 RRSIG 验证成功就接受 RRset，全部失败才判 Bogus；更严格的本地策略与不同缓存时间仍可能造成分叉。

迁移计划必须先写退出条件。添加新路径后，要测量关键解析器群体；撤除旧路径前，要从独立网络观察父区 DS、子区发布、签名窗口与 TTL 消退。“两把钥匙同时可见”不是“旧钥匙可以删除”的凭证。

DNSSEC 结论止步于数据认证

一条完整有效的链只证明：在某个信任锚与时间窗口下，相关 RRset 按 DNSSEC 规则得到认证。它不证明运营者的法律身份，不证明算法满足所有组织政策，不证明目标服务在线，更不证明随后的连接成功。

验证器与应用之间还有一道边界。DO 请求 DNSSEC 数据，CD 改变检查行为，AD 在规定条件下表达认证状态。若 stub 到递归解析器的通道不可信，或应用根本不读取安全状态，一个比特不能升级为端到端证明。

最后的凭证属于应用：它信任哪台解析器，经何种通道收到了何种状态，依据哪版策略采取了什么行动，最终观察到了什么结果。RFC 9558 给系统增加了一个精确坐标，没有替系统走完这条路。

来源

来源