摘要

  • RFC 3402 规定，非终止规则的替换结果只能成为下一次数据库查询的键；下一条规则仍然必须作用于流程开始时那条完整、原样的 Application Unique String。
  • 这条不变量把“去哪里继续查”与“究竟在查什么”分开。委派链可以跨越多个权威，但任何中间权威都不能悄悄重定义原始对象。

“重写规则”很容易让人想到一条流水线：第一条规则修改文本，第二条接过修改后的文本继续加工，第三条再处理第二条的结果。这样的实现看似自然，却有一个危险后果。几轮之后，最后一条规则面对的可能已经不是用户最初交给系统的对象，而是前面多次偶然变形的产物。

RFC 3402 拒绝了这条直觉。文件于 2002 年 10 月作为标准轨文件发布，是动态委派发现系统 DDDS 的第二部分。它描述一种延迟绑定算法：应用程序先给出 Application Unique String，简称 AUS；客户端按需取得规则，在不同数据库之间推进，直到一条终止规则产出应用程序约定的结果。

真正关键的不是规则能否产生新字符串，而是新字符串拥有什么身份。非终止规则的替换结果是一把查询键，用来取回下一组有序规则。它不是新的 AUS。到了下一轮，替换表达式仍要重新作用于最初那条 AUS。RFC 3402 不仅用强制性措辞禁止把上一条规则的输出当作下一条规则的输入，还要求每份 DDDS 应用规范再次声明这条边界。

第一步有意采用不同机制。First Well Known Rule 由应用程序定义，不从规则数据库中动态取得。它把 AUS 转成第一把合法查询键，为整个路径提供一个公开锚点。如果客户端仅仅因为某个数据库“恰好能接受”某种字符串就从那里开始，格式上的兼容会被误装成获得授权的委派。

数据库查询返回的是有序规则集。客户端依次把其中的替换表达式作用于原始 AUS，直到得到一个非空结果。匹配只是第一层判断。规则还带有 Services、Flags 与 Priority，分别参与服务是否可用、结果是否终止以及等价选择之间偏好的判断。一个正则表达式匹配成功，并不意味着客户端已经接受了该服务。

如果规则匹配，但 Services 描述的能力不符合客户端需求，流程不会假装这条规则不存在，也不会随意跳到另一座数据库。客户端应当回到刚才取得的同一有序列表，从被拒规则之后继续。这使运行证据可以保留三个不同事实：哪条规则匹配、为什么拒绝、从哪个位置恢复。

如果被接受的规则不是终止规则，它的输出只承担下一把键的角色。客户端还应验证这把键是否符合目标数据库的格式要求，因为错误的正则表达式完全可能生成非法键。即便它在字符层面看起来像某种名称，也不能因此升级为新的原始对象。

RFC 3402 特别批评了类似 sendmail 的串联重写，把它称为脆弱且容易出错。原因不只是工程风格不同。在累积重写中，一个早期输出的细微偏差会改变后面所有规则所处理的材料，审计必须复原每一轮可变状态。DDDS 的不变量让每条规则都可以用同一 AUS 独立重放；中间输出则分别按查询键或终止结果接受检查。

算法并非永远禁止转交给另一个体系。某种 Flags 可以明确暂停当前 DDDS 应用，把处理交给另一种 DDDS 应用或协议专用步骤。RFC 3404 中的 p 标志就是例子。但这是一道公开的上下文切换：旧应用的规则从此不再适用。它不是让旧规则继续运行，同时偷偷把中间键冒充为新的 AUS。

终止规则关闭的是算法循环，而不是现实世界的不确定性。其输出必须符合应用程序定义的预期格式，并连同 Flags 与 Services 返回。走到终点不等于证明后续服务在线，不等于证明发布规则者拥有合法权威，也不等于证明消费方已经采用结果。若只保存最终字符串，算法结束与业务成功就会被错误合并。

Priority 的权限同样受到限制。它表达同类规则之间的偏好，例如某个选择更快、更好或成本更低。文件明确说明它不是负载均衡机制。若具体应用需要分配流量，应在适当层次使用其他机制，例如适用时的 SRV，而不能把优先顺序解释成协议未承诺的流量权重。

时间也是委派链的一部分。客户端可以缓存已经用过的键与规则，减少重复计算，但必须服从数据库的过期语义。一旦先前路径上的某条规则已经过期，应用程序就要从第一步重新开始。把旧路径的前半段与新路径的后半段拼起来，会制造一条从未在同一时刻真实存在过的链。

因此，RFC 3402 不是一份可以单独执行的万能规范。应用规范必须定义 AUS、第一条规则、允许使用的数据库、字符集处理和终止输出。数据库规范必须定义存储、查询、键与规则格式、插入政策以及不同应用之间的冲突避免。RFC 3401 甚至直接警告，只读系列中的某一份文件会造成误解和互操作问题。

抽象算法也承认自己不能决定什么。DDDS 可以依据 AUS 与规则推导委派，却不能自行判断时间、付款、权利或交易状态等外部事实。若结果依赖这些条件，证据必须来自算法之外。把外部政策藏进一个不透明输出，会让委派链显得比它实际拥有的权威更大。

安全问题也只有在应用与数据库配对之后才会具体。RFC 3403 规定 DNS 数据库与 NAPTR 规则，RFC 3404 规定 URI Resolution 应用，早先的 RFC 2916 描述 ENUM。它们展示了同一抽象算法的不同落地方式，却不能证明任意 DDDS 客户端支持所有应用，也不能证明数据库中的每条记录都可信。

IANA 的 ENUM Service Registrations 注册表展示了后来某一 DDDS 应用如何协调服务标识。进入注册表只证明标识已经协调，并不证明解析器执行、规则新鲜、发布者有权、算法正确终止或下游服务成功。RFC Editor 当前为 RFC 3402 列出一条已验证的编辑性勘误 7049：RFC 3404 中 p 标志的讨论应引用 4.3 节，而不是 4.4 节。这项修正不改变本文讨论的不变量。

所以，一份可审计的 DDDS 收据不能只留下终值。它至少要保存原始 AUS、应用及版本、First Well Known Rule、数据库类型、每一把查询键、每组有序规则、规则身份与有效期、替换匹配和输出、服务接受或拒绝、恢复位置、Priority 决定、终止标志、预期输出验证，以及最终消费方究竟做了什么。

Lu Heng 的最小初始规范原则解释了 RFC 3402 的克制：标准只规定独立实现必须共同遵守的最小接口，而把应用语义与数据库机制交给各自规范。运行代码优先则要求把这份抽象合同还原成现场证据。操作者应能用真实规则重放原始 AUS，验证每次查键与恢复位置，并证明任何实现都没有让中间结果篡位。

RFC 3402 的历史意义因此不只在正则表达式或 NAPTR。它为分布式委派保住了对象连续性：每一层都可以决定下一步去哪里询问，却不能决定上一层原本问的是什么。路径可以改变，权威可以迁移，查询键可以一次次重写；被解析的对象必须始终是最初那一个。

来源