摘要

  • ARIN 的公开 Delegation Key 指南把摘要类型 3 标为 MD5，并列出长度 32；IANA 将 DS 摘要类型 3 登记为 GOST R34.11-94，目前标记为已弃用。这不是同一种函数的不同写法。
  • ARIN 未说明长度列的单位。GOST 的 256 位摘要是 32 字节，写成十六进制则需要 64 个字符；这项换算不能证明 API 会拒绝 64 个字符，或接受 32 个字符。
  • 当前 IANA 登记及 RFC 9906 对类型 3 的四项使用、实现建议全部写为 MUST NOT。修正名称不等于恢复使用资格。本篇没有调用配置 API，也没有测试任何区域、签名程序或解析器。

编号后面的名称不能随意换

ARIN 的公开 Reg-RWS 字段参考里，摘要类型表的第三项很短：编号 3，名称 MD5，长度 32。把这一行与 IANA 的 DS 摘要类型登记放在一起，问题就出现了。IANA 给同一个字段中的编号 3 分配的是 GOST R34.11-94，而不是 MD5。两者不是标点、简称或本地表达的差别，而是不同的密码摘要函数。

这里观察的是 2026 年 9 月 14 日抓取到的公开文档。日期说明证据的时间边界，不说明错误何时出现，也不能推导它持续了多久。我们没有找到足以确定这行表格最初引入时间的修订记录。页面上出现较新的其他算法，也不能单独证明整个页面一直被完整更新，或一直未被更新。

这个区分尤其重要，因为标题很容易被扩大成“ARIN 正在使用 MD5”。公开字段名称不等于实际提交数据，不等于服务保存的数据，更不等于公共 DNS 回答。本文没有访问任何私有账户，没有生成或提交 DS，没有用 API 密钥做配置操作。没有证据支持把表格错位改写成一场已经发生的线上事故。

但它也不只是一个无关紧要的拼写问题。DS 记录把摘要类型编号与摘要内容放在一起，编号告诉接收者应当按哪一种函数理解数据。界面名称可以帮助人识别这个编号，却不能为某个服务定义一套私有的协议含义。一个数字只有放回对应字段的命名空间，才具有确定意义。

由此能够提出一个有条件的风险：如果客户端作者照着 MD5 名称计算数据，又把结果配上类型 3，那么编号与内容可能不符合已登记的函数含义。这里的“如果”不能省略。本文没有识别出实际这样做的客户端、用户或委派，也没有验证这种路径在 ARIN 服务中能否走到发布阶段。

先分清是哪一张算法表

ARIN 文档把 Delegation Key 放在 Delegation Payload 内，其中既有 algorithm，也有 digestType。前者对应 DNSKEY 算法，后者对应 DS 摘要函数。这两套编号可以在同一份输入中出现，但不是同一张分配表。把签名算法目录拿来解释摘要编号，会在比较开始之前就选错对象。

公开算法目录列出的值包括 5、7、8、10、13、14、15 和 16，名称涉及 RSA、ECDSA 与 EdDSA。另一张摘要类型表则依次列出 1 对应 SHA1、2 对应 SHA256、3 对应 MD5、4 对应 SHA384；长度分别为 40、64、32、96。这是对公开参考的描述，不是经过测试的线上算法白名单。

RFC 5933 的原始分配使这种区别十分清楚：ECC-GOST 的 DNSKEY 签名算法编号为 12，GOST R34.11-94 的 DS 摘要类型编号为 3。因此，“DS 类型 3”不是“DNSKEY 算法 3”。它也不是 DNSKEY 协议字段里的值 3，更不是某个恰好带有数字 3 的密钥标签。整数相同，不会消除字段语义的差异。

ARIN 的文档还说明，算法名称和摘要类型名称由输入的数字值决定，提交的名称会被丢弃。按照这段接口描述，填写一个不同的名称并不能覆盖编号含义。于是，文档对数字与名称的对应关系，直接影响读者如何理解自己正在选择的字段。但这仍然只是文档所陈述的处理方式。

它不能证明当前服务实际返回什么名称，先进行哪项校验，遇到哪些输入会产生什么错误，或最后保存哪一种表示。要讨论这些问题，需要日期明确、条件可复现、权限合适的执行证据。不能用一段预期行为的说明，替代一次已经观察到的行为；也不能因为公开名称错误，就假定所有实现环节都复制了错误。

摘要不是屏幕上一串公钥的随意哈希

RFC 4034 对 DS 的结构给出了另一条必要边界。摘要类型字段指明构造摘要所用的算法；摘要的输入包含规范形式的 DNSKEY 所有者名称，随后接上 DNSKEY 记录数据。这些记录数据包含标志、协议、算法和公钥。因此，不能简单把它说成“把界面显示的公钥字符串做一次哈希”。

函数选择、输入构成和文本表示，是三个需要分别说明的问题。改正函数标签不会自动证明输入构成正确；输入构成正确，也不会自动解释长度列究竟在数什么。对客户端维护者而言，一张好表格应当降低这些转换中的歧义，而不是要求读者根据邻近字段自行猜出未写明的规则。

IANA 当前登记与 RFC 5933 的原始分配都指向 GOST。现在标为已弃用，并不意味着这个编号被释放出来，可以由 MD5 填补。登记表可以继续解释历史记录里的数字，同时明确不再推荐其使用。保留识别能力与批准新部署不是同一个动作，也不应该被写成同一个意思。

本文的判断只针对 DS 摘要类型 3 的分配，没有宣称 MD5 从未出现在任何 DNS 相关协议或其他技术用途里。后一个问题范围更大，需要别的证据。把结论限于可直接比较的字段，既避免夸大，也让纠正请求有一个明确、可以完成的对象。

长度 32，究竟是哪一种 32

摘要名称错位是直接比较所得；长度需要更谨慎。ARIN 给这一列的标题是 Digest Length，却没有写出单位。相邻的 40、64 和 96，与十六进制字符数相符。这提供了一种合理读法，但不能证明服务按字符数执行了相同限制。公开列标题没有把“说明值”变成“已观察的校验条件”。

RFC 5933 规定 GOST 摘要为 256 位。每字节八位，所以数据长度是 32 字节。十六进制用两个字符表示一个字节，所以同一段数据需要 64 个字符。RFC 4034 的 DS 文本表示正是大小写不敏感的十六进制，并允许空白。这又提醒读者：格式化字符串的长度与底层数据的长度不能直接互换。

如果 ARIN 这一列想表达十六进制字符数，那么 32 不能描述类型 3 所登记的 GOST 摘要。如果这一列想表达字节数，那么 32 能描述 GOST 的大小，但相邻几行就需要另一种解释。文档没有给出足够信息来选择其一。能够提出的是要求补明单位，而不是自行认定线上必须遵循某一种读法。

因此，不能从这张表推导出“提交 64 个字符必定被拒绝”，也不能推导出“提交 32 个字符必定成功”。解码方式、空白处理、校验顺序、错误返回及保存形式，都没有在本文中被实际测试。即使长度列最后被澄清为字符数，这也只是增加了文档证据，不会自动生成一份服务执行记录。

纠正名称与纠正长度说明应该相互协调，却不必合并成一个未经验证的系统缺陷。一个字段可能有错误名称、模糊单位和正确实现，也可能存在别的组合。现有证据没有判定具体实现属于哪一类。准确报告已知问题，会让后续调查针对真正未回答的环节，而不是重复证明那一行确实写错了名称。

改回 GOST，不是让 GOST 回来

名称修复还有一个重要限制：当前并不推荐使用这个类型。RFC 9906 于 2025 年 11 月发布，退出 DNSSEC 使用范围的对象包括 ECC-GOST 和 GOST R34.11-94。当前 IANA 的类型 3 行在四个栏目中全部写为 MUST NOT：用于委派、用于验证、为委派实现、为验证实现。

旧文献容易给这件事带来错误的第二种解释。RFC 5933 最初描述可选实现，有助于说明编号的历史来源，却不能覆盖后来退出使用的要求。把旧版本中的 MAY 当成今天仍然有效的验证建议，会在纠正第一处名称错位时制造另一处时间错位。读者需要同时看到历史含义与当前状态。

一份目录可以说明旧配置中可能出现的标识符，供识别、检查、修改或移除之用。说明这个编号“是什么”，不等于建议生成相应的新材料。本文没有测试 ARIN 是否存在任何特定兼容、编辑或移除路径，也没有把这种概念上的区别认证成实际产品能力。它只是说明目录表达应当怎样避免混淆。

RFC 9906 还区分了验证结果的含义。如果只剩依赖退出算法的路径，且没有其他可接受的认证路径，所规定的处理是 insecure，而不是继续使用这些算法验证并把链条判成 bogus。这些术语都不是“域名无法访问”的同义词。本文没有测量任何 ARIN 区域处于哪种状态，也没有据此断言实际可达性。

因此，本篇不是重新讲述 GOST 退出矩阵的文章。退出要求在这里提供的是修复边界：错误名称应该更正，但更正不能变成新部署建议。调查的中心仍然是一个具体的配置字段，把一个已分配的编号指向了另一种函数。只有保持这个中心，才不会与已有的算法退出报道重复。

父区的一项字段，不是整套 DNS

ARIN 的反向 DNS 指南解释了这项数据的使用位置。操作者在安全配置反向区域后，可以向父区提供 DS，并通过 ARIN Online 或 RESTful 配置服务按委派管理相关数据。被讨论的字段因此处在一个实际接口边界：子区的密钥材料与父区对这些材料的描述之间。

这个边界之所以值得说明，正因为它不是全部系统。父区 DS 管理不等于子区签名，不等于 DNSKEY 的发布，也不等于控制所有可能验证链条的解析器。某个错误名称可能进入本地理解，却未必通过每一道边界成为公共 DNS 数据。公开指南不包含足以重建所有用户操作及最终回答的证据。

也不应把这处配置接口解释成对数字资源的一种新权力。更正摘要名称、说明长度单位、解释已退出类型的当前处理，都可以在既有的文档与服务责任范围内提出。没有理由借此扩大到地址分配惩罚、机构权限转移或其他未涉及的运行服务。薄而明确的接口责任，比笼统宣称注册机构应控制整条链条更有用。

这里的证据支持一个可完成的公开请求：把类型 3 的名称与登记含义对齐，写明长度的计量方式，并把历史识别与当前使用建议分开。如果有人进一步争论实际接受规则，应当另行提供执行证据。它不支持预防性删除现有 DS，不提供安全的密钥轮换程序，也不支持给某个具体委派贴上故障标签。

复核时，不要替换了问题本身

复核这类错位，可以先问证据究竟指向哪个对象。ARIN 表格指向接口字段的公开解释，IANA 登记指向该字段的分配，RFC 5933 解释原始分配，RFC 9906 解释现在的使用状态。它们在论证中承担不同作用，不能因为都有技术术语，就被合并为六次相互独立的系统审计。标准文本之间本来就存在继承关系，IANA 也不是对 ARIN 服务做了一次验收。

接下来，要保留争议行与上下文之间的联系。只摘出 MD5 容易丢掉 digestType 的字段身份；只摘出 3 容易与 DNSKEY 其他字段混淆；只摘出 32 又容易把未说明单位的表格变成确定的校验规则。把名字、编号和单位逐一归回原来的位置，是证据整理，而不是一次新的网络测试。它可以让不同读者复核同一个公开问题。

最后，要分清什么样的更正能够回答什么样的疑问。名称改为 GOST 回答了分配不一致；增加单位回答了表示歧义；补充退出状态回答了推荐使用的时间边界。即使三项都完成，也没有回答某个历史客户端曾经提交什么、某个服务器如何处理、某个解析器最后看到什么。这些不是要求一项修正无限扩展，而是防止完成的文档修复被误当成尚未发生的执行证明。

一份清楚的更正说明还可以把未测问题列为未测，而不暗示已经存在错误数据。这样，维护者知道是否需要进一步检查自己的映射来源，操作者也不会因笼统的安全措辞被迫立即改变配置。公开透明的价值不是制造更多紧迫动作，而是让真正需要动作的人辨别依据、权限和影响范围。对于一行字段解释，能够减少错误确信，已经是实质性的收益。

资料来源

  • ARIN 的 Reg-RWS 字段参考：Delegation Key 字段、名称处理说明及摘要类型与长度表。
  • IANA 的 DS 摘要类型登记：类型 3 的分配及四项当前建议。
  • RFC 5933：原始 GOST 编号及 256 位摘要；其历史使用建议已被后续要求取代。
  • RFC 9906：2025 年 11 月的退出要求及规定的验证处理。
  • ARIN 的反向 DNS 指南：父区 DS 配置背景，不是任何特定区域状态的证明。
  • RFC 4034：DS 字段、摘要输入和十六进制表示，不作为当前算法选择建议。