摘要

  • RFC 5395 为 DNS 的操作码、响应码、头部位、资源记录类型、类别和 AFSDB 子类型规定了不同的分配路径；相同的 16 位宽度并不创造相同的语义空间。
  • “未分配”“保留”和“私用”不是同义词。私用范围允许局部约定，却故意不提供全球唯一性；未分配编号仍须经过适用的授权程序。
  • 有效的上线回执必须把字段上下文、编号状态、授权决定、登记快照、传输保真、应用行为和最终结果逐项保存。

登记完成只证明登记完成

一项 RRTYPE 申请通过专家评审并进入 IANA 表格，证明一个碰撞可控的公共身份已经获得分配。它没有证明权威服务器能够解析展示格式，也没有证明从服务器会正确传送、递归解析器会暴露、SDK 会识别，或者业务程序会依据其内容作出任何决定。

RFC 5395 引入的 DNS 专用专家评审程序，要求申请人提交完整模板，由指定专家判断扩展是否足够清楚、安全并符合 DNS 的基本假设。RFC 6895 后来简化了流程。对普通数据 TYPE，关键条件之一是未知类型能够按 RFC 3597 被处理；对 Meta-TYPE，则必须是可选处理且可安全丢弃。这是分配身份的门槛，不是部署验收。

因此，变更票据不能只附一张 IANA 截图。它还要记录实现版本、配置来源、区文件解析结果、主从传送、查询响应、缓存行为、API 输出、应用解释和用户可见结果。某一段成功不能代替后一段。注册表是权威链的一环，不是整条执行链。

空白行只回答“现在是否已有登记”

工程师在表格里看到一个空位，容易把“无人登记”读成“任何人都可用”。RFC 5395 的结构恰好反驳了这个推论。不同 DNS 字段分别适用 Standards Action、IETF Review、Expert Review 等程序；有的值被保留，有的明确划为 Private Use。可用性描述状态，授权程序决定谁能把该状态改变成公共意义。

随机占用一个未分配值尤其危险。今天它可能在实验室中工作，明天却与正式分配碰撞。既有部署会形成迁移成本，团队也可能把“我们先用了”误当成所有权。私用范围至少明确宣布：IANA 不会替不同站点避免碰撞，使用者必须把约定限制在自己的作用域内。未分配池没有这份局部使用契约。

最小的运行记录应说明采用哪个注册表、哪个字段、哪个数字、何种状态、依据哪份规范、由谁批准、预期边界和退出条件。若这些信息不能随配置一起被找回，所谓“编号可用”只是一次无法审计的观察。

数字 16 必须带着所在位置

DNS 错误码说明为什么单独保存整数会破坏证据。有效 RCODE 可由基础 DNS 头和 OPT 扩展组成，也会出现在 TSIG 或 TKEY 等不同上下文。RFC 5395 记录数字 16 在 OPT 语境中表示 BADVERS，在 TSIG 语境中表示 BADSIG。RFC 6895 还保留了数字 9 的语境差异。

若监控系统只写入 rcode=16，它虽然没有记错数字，却丢掉了决定诊断的字段。协议版本不受支持与签名失败会落入同一个桶，告警路由、责任团队和处置动作可能全部错误。正确主键至少包括注册表名称、字段位置、扩展机制、容器记录、对端和适用规范。

这条纪律也适用于数据库设计。一个通用 code 列不应跨命名空间关联。相同整数在不同注册表中没有天然同一性。若展示层为了简洁只显示数值，原始上下文仍须留在证据层；否则看似整齐的指标会在事故中制造虚假的确定性。

看似空闲的位可能携带旧历史

RFC 5395 对 DNS 头部位的讨论提醒设计者：字段图不是全部已部署状态。一些实现会把查询头复制为响应头，却不清除只应在查询中有意义的位。若标准后来赋予该位一种新的响应含义，复制留下的旧状态就会被误读成新信号。

Z 位还有更早的影子：古老实现曾把查询中的它理解为要求主服务器回答。文档认为当时的实现大多已忽略这种行为，却仍要求 Standards Action 才能重新分配。原因不是迷信历史，而是私人测试无法证明全球安装基础已经无害。

运行代码优先不等于第一份运行代码拥有空位。它要求把真实实现行为带进决策。分配机关提供公共协调，互操作测试提供安装证据，两者缺一不可。没有授权的成功试验不能建立全球意义；没有真实试验的授权也不能证明功能能够运行。

私用范围是一道边界

RRTYPE 的 Private Use 范围是 65280 至 65534。两个实验室都可合法选择 65300：一个把它解释为服务健康声明，另一个把它解释为策略令牌。只要网络隔离，两个约定都可能完全正常。互联、并购或共享解析基础设施出现后，同一个类型号便携带互不相容的 RDATA，而注册表不会替它们裁决。

这并不是禁止私用的理由。它要求团队把碰撞域写清楚：哪些服务器与应用参与、值能否离开边界、日志如何识别其来源、约定何时到期、怎样迁移到正式分配。私用成功证明局部合作，不证明全球所有权。

当产品开始依赖外部伙伴、公共递归或第三方 API 时，边界已经改变。此时应启动适当的分配程序，而不是把既成部署当作优先权。越晚承认这种改变，编号越会渗入固件、数据模型和合同，回收成本也越接近不可逆。

字节存活不代表含义已被执行

RFC 3597 允许不认识某个 RR 的服务器用通用形式保存它：TYPE 加十进制编号，再加 \#、长度和十六进制 RDATA。它还规定压缩与比较规则，使旧基础设施能够在不了解新语义时仍然传送数据。

这是 DNS 可扩展性的关键能力，却也容易制造过早的胜利。主从传送保持字节不变，只证明保管；解析器把字节返回，只证明可取回。只有消费应用验证并依据其内容行动，才证明语义执行。控制台显示一条记录，更不等于用户获得了预期服务。

测试要沿链路分层：展示格式能否输入，线格式是否正确，主从是否保真，缓存是否保留，接口是否暴露，应用是否解释，最终动作是否发生。已知类型即使采用通用表示输入，解析后仍应接受类型专用处理；表示方式不能把已知语义降级成无害的未知字节。

历史 RFC 与实时表格可以同时正确

RFC 5395 于 2008 年发布，后来被 RFC 6195 取代；RFC 6195 又在 2013 年被 RFC 6895 取代。后者调整 RRTYPE 流程，并关闭 AFSDB 子类型注册表。本次研究冻结的 IANA DNS Parameters 页面标注最后更新于 2026 年 8 月 28 日，其中自然包含旧 RFC 当时不存在的分配。

旧文档准确描述它发布时的政策与状态，实时登记表准确描述后来治理动作的累计结果。把两者差异称为“谁错了”会丢失时间维度。审计必须记录引用的注册表、检索时间和继承链，并说明某个决定在当时依据哪份有效规则。

同样，“IANA 如此显示”也不够。网页、XML、文本导出、企业缓存和生成代码可能因同步失败而分叉。应比较这些投影，并把快照散列与部署物关联。注册表内容会演进，证据必须说明自己观察的是哪个时刻。

证据边界

被冻结的来源证明 RFC 5395、RFC 6195 与 RFC 6895 的文本和继承关系，RFC 3597 的未知 RR 规则，RFC 8126 的注册表术语，以及抓取时的 IANA 表格。它们不证明某个当代 DNS 产品已经支持某类型，也不证明某运营商部署、真实碰撞事故或某次中断原因。

最稳固的结论很窄：整数成为公共含义，要经历局部试验、授权、登记、实现保真、应用理解和结果实现。任何一个环节都不能冒充其余环节。看到“registered”时，领导者下一句应问：这是哪一张回执，还有哪些回执尚未出现？