摘要

  • RFC 3403 把 DDDS 规则存入 DNS NAPTR 记录，但响应中的物理排列不构成规则顺序。客户端必须先按 ORDER 排出权威层，再在同一层内使用 PREFERENCE。
  • 一旦规则匹配，客户端不能因为后面出现熟悉服务就越过另一个 ORDER。Additional 区、DNSSEC 验证与下游服务成功分别属于不同证据。

DNS 工具把记录逐行显示，很容易让人把第一行理解为第一项选择。抓包也会给每个资源记录一个物理位置。RFC 3403 要求 DDDS 客户端抵抗这种视觉直觉：响应交付的是候选规则集合，执行顺序藏在记录字段中，而不在数据包排列中。

文件于 2002 年 10 月作为标准轨规范发布，把 DNS 定义为 DDDS 规则数据库。合法查询键是域名，客户端对它查询类型代码 35 的 NAPTR 记录，并获得一组规则。RFC 3403 同时取代 RFC 2915 与 RFC 2168，成为 NAPTR 的正式规范。

ORDER 负责恢复委派顺序，数值较小者先处理。拥有相同 ORDER 的记录，在权威意义上被视为同一条规则，即使它们提供不同服务或协议。一旦找到匹配项，客户端不得继续考虑另一个 ORDER；只有 DDDS 算法明确说明的复杂服务选择例外可以跨出这条普通路径。

因此，响应中最先出现的记录没有先天优先权。服务器、缓存、解析库或传输过程都可能重排 RRset，而语义保持不变。如果客户端拿到第一条能识别 Services 的记录就使用，它其实用传输偶然替换了区域管理员发布的权威结构。

PREFERENCE 位于更低一层。它对应 DDDS 的 Priority，只对相同 ORDER 的候选排序，数值较小者优先。若客户端对首选协议支持不佳，可以考虑同层中较低偏好的选项；它不能借此越到另一个权威层。

RFC 3403 还明确否认 PREFERENCE 是负载均衡权重。它表达同等权威规则之间的质量与偏好。需要流量分配时，应使用 SRV 或多个 A 记录等 DNS 机制。把偏好解释成随机权重，会给记录添加从未承诺的行为。

NAPTR 还包含 Flags、Services、REGEXP 与 REPLACEMENT。Flags 和 Services 不具备数据库层面的通用含义，必须由配套应用规范定义，包括哪些标志代表终止。客户端认识某个字符，不等于它理解正在使用的应用。

REGEXP 与 REPLACEMENT 是替换表达式的两种互斥形态。REGEXP 作用于应用原始字符串；REPLACEMENT 用一个完全限定域名完成简单替换，并禁止名称压缩。如果一条记录同时填写两者，它就是错误记录，应被忽略或产生错误。

区域文件到网络响应之间还存在一次解释。反斜线在主文件中是转义符；为了让客户端最终看到一个反斜线，管理员往往需要写入两个。只审区域源文本或只审网络表达式，都可能漏掉发生在中间的变化。

文本字段使用 UTF-8。遇到超出 ASCII 等价范围的字符时，表达式必须按码点而非字节处理；同时不得依赖某一 POSIX locale。若同一规则随客户端区域设置改变含义，它就无法在全球范围保持一致。

同一 DNS 数据库可能承载多个 DDDS 应用并发生碰撞。RFC 给出三种隔离：为应用划分不同区域；让正则表达式锚定应用独有的输入特征；或用应用专属 Flags 与 Services 排除无关规则。记录共享域名，不代表应用合同已经合并。

Additional 区只是优化。服务器可以附上与答案具有同等真实性的相关 A 或 SRV RRset，应用也可以利用。但所有应用都必须在权威服务器从不填写 Additional 时正常工作。缺少旁路数据意味着再发查询，而不是 NAPTR 答案不完整。

TTL 约束缓存拼接。如果客户端在错误委派或服务器失败后回退到先前取得的规则，它必须确认所有依赖仍未过期。只要一条规则失效，就要从 DDDS 第一步重新开始。旧链前半段与新链后半段拼出的顺序，可能从未在同一时刻存在。

规范对后退也保持谨慎：若某次重写后的查询失败，强烈建议客户端报告失败，而不是退回去试另一条重写路径。机会主义回溯会把有序委派变成开放搜索，并掩盖真正失败的权威层。

DNSSEC 可以像保护其他 DNS 记录一样签名并验证 NAPTR。它证明 DNS 数据在信任链下的真实性，却不证明正则表达式安全、客户端排序正确、Services 属于预期应用或下游服务成功。RFC 因而另行警告，不要把表达式盲目交给可能执行任意代码的环境。

IANA DNS Parameters 注册表仍把 NAPTR 列为类型 35，这证明编号协调，不证明实现正确。RFC Editor 当前列出一条 Held for Document Update 的编辑性勘误 2868，只删除 Services 描述里重复的 this this，不改变任何排序规则。

完整运行收据应保存查询键、完整 RRset、DNSSEC 状态、TTL、收到时的排列、排序后的 ORDER 组、组内 PREFERENCE、Flags、Services、REGEXP 或 REPLACEMENT 合法性、UTF-8 解释、区域文件与网络表达式对照、拒绝理由、选中记录、实际使用的 Additional 数据、下一次查询和终端消费结果。

Lu Heng 的最小初始规范原则解释了这种分工：只标准化应用之间必须共享的 DNS 表达与处理边界，让应用规范定义自己的服务语义。运行代码优先给出验证方法：打乱 RRset、删除 Additional、改变 locale、让一条依赖过期，再比较选中规则。结果应追随权威字段，而不是显示顺序。

RFC 3403 把一个无序 DNS 集合恢复为有序行动，却从未假装传输已经替客户端排好。数据包里第一条 NAPTR 只是最先被看见；真正的第一条规则由合同决定。

来源