摘要

  • draft-levine-dnsextlang-14 设想用 TXT 记录描述 DNS RRTYPE，让许多新类型通过配置数据而非逐个修改软件得到支持；它目前只是个人互联网草案，不是 RFC，也不是已经投入服务的 IANA 设施。
  • 草案用 X 标记需要特殊处理的类型。这个标记能提示服务器在能力不足时报错，却不会安装处理代码，更不能证明某个产品已经实现了该行为。
  • DNSSEC 可以在验证器的信任策略下证明 RRset 的来源与完整性；它不证明模式语义正确。上线仍需核对双名记录、披露本地覆盖、测试解析器、验证线格式、隔离试装并从权威服务器回读。

想象一次看似完整的变更：运维系统从 DNS 取回一个 TXT RRset，DNSSEC 验证成功，配置页面随即出现五个输入框，区域文件也顺利通过语法检查。此时最危险的词是“成功”。成功的是取回、认证、渲染，还是生产服务器已经把这份描述转换成预期字节，并能在重载、签名、区域传送和查询链路中保持一致？

这正是扩展语言提案带来的价值与风险。新增 RRTYPE 往往要求权威 DNS 软件和供应系统同时发版。第 14 版草案把其中一部分工作改造成表驱动：一个 stanza 声明类型名称、数字编号、选项和字段顺序；软件可以从 DNS 或可选的本地文件读取它，把易读的主文件文本转换为二进制 RDATA，也能从 AXFR 数据恢复文本。供应系统还可据此生成表单与输入校验。

变化不是“无需实现”，而是“把一部分实现从编译代码移入解析器所消费的数据”。一旦数据能够改变解析与输出行为，它就进入了执行边界。

两条查找路径并不会自动成为一个事实

草案要求每个 DNS 模式保存两份相同 TXT 记录：一份以数字类型命名，位于 RRTYPE.ARPA；另一份以符号名称命名，位于 RRNAME.ARPA。也可以让其中一项通过 CNAME 指向另一项。带 BCP 47 前缀的记录承载不同语言的人类描述，无前缀记录作为默认入口。

这种设计便于从名称或编号双向发现，却没有定义两份独立 RRset 不一致时由谁胜出。更新期间，数字入口可能已经刷新，符号入口仍留在另一个缓存世代；语言版本可能先于默认别名变化；本地文件还可能覆盖中央记录。草案写明“两者相同”，但没有给客户端一个冲突仲裁算法。

连目录文字也留下待修订痕迹：正文写 _LIST.RRTYPE.ARPA，示例却是 _LIST.RRNAME.ARPA。这不应被读成两种等价部署选择，而应被准确标记为当前草案的不一致。实施者若悄悄各选一个，原本要减少的软件差异反而会产生新的分叉。

DNS 的时间语义也不能省略。TTL 规定刷新时机，却不保证所有缓存同时切换。RFC 8767 还允许解析器在权威刷新失败等受限条件下保留并返回过期数据。这不是说草案要求使用 stale 数据，而是说明“来自 DNS”必须继续拆分为当前权威回答、TTL 内缓存和显式 stale 回退。上线记录若没有观察时间与缓存状态，就无法说明机器实际看见了哪一代模式。

DNSSEC 证明发布者，不替发布者证明正确

草案的安全章节担心攻击者通过 DNS 欺骗修改导入记录，并把 DNSSEC 列为防御方式之一。RFC 4033 对能力的定义更精确：DNSSEC 为 RRset 提供来源认证和数据完整性，验证依赖信任锚与认证链。

因此，验证成功支持的是“被认证区域发布了这些字节，且传输中没有被无痕修改”。它不回答字段组合是否合理、数字与符号记录是否一致、解析器是否支持所有 token、数据库适配器是否保序，或者运维人员是否同意激活。即使签名完全有效，一份有错误的模式仍可能忠实地被认证。

把 DNSSEC 结果称作“可信可执行配置”，会把三个权力动作混在一起：发布者作出声明，验证器确认来源，运营者授予对运行服务的影响。三者必须分别留下证据。

X 是拒绝条件，不是远程插件

草案把需要服务器额外处理的类型标上 X，DNAME 和 DNSSEC 是其例子。服务器如果没有相应处理，应在区域包含该记录时报告错误。I、A、O、E 分别表达类别适用范围、废弃或实验状态。

这些字母是声明，不是能力本身。X 没有携带模块、版本或一致性测试；服务器或许认识记录在线格式中的字段，却不会执行该类型特有的附加行为。最诚实的结果是有界拒绝，而不是把“模式已加载”显示成绿色。

RFC 3597 给这条边界提供了重要基线。未知类型早已可以用 TYPEnn \# 长度 十六进制数据 表示，服务器与解析器应透明传递；未知类型不会触发附加区处理。扩展语言真正增加的是可读语法、表单、校验与表驱动转换，并不是第一次让 DNS 容纳未知 RRTYPE。若友好语法无法安全启用，通用表示仍可成为保守退路。

一份模式需要一条执行收据

草案自己警告：恶意或意外的字段定义可能在未充分校验的软件中触发异常错误；能表示任意记录的语言也可能绕过供应系统原有的类型限制。这要求运维把解析当作代码入口对待，但不必把所有控制都中央化。

可执行的上线链条应当是：发现、认证、对账、校验、试装、观察、激活、证明。

首先保存草案版本、Datatracker 状态和查询时间。随后分别记录数字名、符号名、语言版本与默认别名的 RRset 字节哈希，并证明它们指向同一 stanza。记录 DNSSEC 状态、验证策略、TTL、缓存年龄和是否使用 stale 回答。若存在本地文件，保存路径、哈希和优先级；若不存在，也要明确写出“无覆盖”。

接着把责任落到具体实现：服务器构建号、解析器版本、字段类型词汇表、存储后端，以及每个 X 要求对应的实际处理模块。测试既要包含合法样例，也要包含超长、越界、顺序错误、非法名称、类别冲突和资源消耗样例。主文件文本转线格式后再反向转换，保留两端字节。最后在隔离区域加载，向权威服务器查询并比对回包，之后才允许在明确范围内激活。

任何一步失败都应回到自己的修复位置。双名不一致是对账问题，未知字段是能力准入问题，往返变化是转换问题，试装成功但生产重载失败是部署问题。若统统叫作“RRTYPE 支持失败”，系统只会得到一次大回滚，而不是可解释的修复。

这份十二项收据是本文提出的运维模型，不是草案的规范要求。它的目的，是阻止前一步借用后一步的权威：签名不能替代解析测试，解析测试不能替代区域加载，加载不能替代权威回读，单台回读也不能替代全网激活。

共同层越薄，创新空间反而越大

中央发布的合理范围，是可移植语法、名称与编号绑定、字段语义、语言选择规则、注册流程和必须一致的互操作约束。具体数据库结构、上线节奏、资源上限、特殊处理和回滚，由承担结果的产品与运营者决定。

这符合 Heng Lu 的“最小初始规范、未来本地决策、自愿采用”：只把互操作不可缺少的内容放进共同层，把后续选择留在本地；是否采用，要由运行系统的可观察结果决定，而不是由注册表的存在倒推出义务。

本地覆盖并非天然危险。它能让实施者先做原型，也能在中央定义出错时迅速隔离。真正危险的是不可见的覆盖。两台同版本服务器若执行不同文件，却共享一盏“DNS 模式已同步”的绿灯，事故发生后便没有可重建的事实。