摘要

  • RFC 3405 要求 URI scheme 或 URN 命名空间先完成注册、拥有稳定规范与获认可的权威，之后才能在 uri.arpa. 或 urn.arpa. 发布 NAPTR。能写出合法 DNS 语法，不等于拥有委派权。
  • 共享区域的记录预计采用极长 TTL，甚至以年计算。可能变化的规则应放到短 TTL 的下游区域，由一条稳定首提示委派过去，让全球稳定与本地敏捷并存。

长 TTL 往往被视为妨碍更新的缺点。RFC 3405 却把它当作架构材料：如果一条全球入口会在缓存里停留数年，就不应把最容易变化的政策直接写进去。入口应稳定地说明，谁负责维护下一层的变化。

规范于 2002 年 10 月以 BCP 65 发布，是五部 DDDS 文档的结尾。RFC 3401 介绍体系，RFC 3402 定义算法，RFC 3403 用 DNS NAPTR 承载规则，RFC 3404 规定 URI/URN 解析服务，RFC 3405 管理 uri.arpa. 与 urn.arpa. 的赋值。

最后一部并非附加的登记手续。它决定谁能在全球共享 DNS 空间写入第一条规则、权威怎样得到证明、哪一层可以快速变化。这些行政安排会直接改变代码走向。

URI scheme 提供 uri.arpa. 下的首键。URN 则先经过 uri.arpa. 中的 urn 规则，提取 Namespace Identifier，再转入 urn.arpa. 的相应键。入口记录很小，却能改变一整类标识符的委派路径。

RFC 3405 不允许 NAPTR 反过来创造自己声称代表的权威。URI scheme 必须先注册并发表稳定规范；URN NID 也要先走完自己的注册流程。解析提示跟在标识符空间合法性之后，不能用它绕过前置审查。

这个顺序阻断两种捷径：一是借 urn.arpa. 记录逃避新命名空间审核；二是把基于 DNS 的 URI 委派给嵌入域名持有人之外的主体。一条正则表达式即使语法完全正确，也可能造成权威劫持。

审查因此包含技术正确性、与已发布规范的一致性，以及 DNS 名称的持有边界。如果 scheme 或 NID 规范由 IETF 之外的主体控制，之后新增或修改 NAPTR 还必须获得所有者或维护者批准。专家技术审查不能替代这份授权，两者回答不同问题。

对 URN NID 而言，维护者权威覆盖该 NID 的全部 NAPTR，即使某条规则只影响空间的一小部分。表达式匹配范围较窄，不会消除命名空间所有者的控制权。

注册模板把来源链写得很清楚：Key、Authority 与 Records。Key 决定全球槽位，Authority 指明有资格的申请者，Records 才是可执行委派。它不是孤立的区域文件片段，而是一份权威收据。

原始流程通过公开邮件列表审议，并留出两周异议期。但异议范围只限于对共享区域或 DNS 的影响；已获认可的 scheme/NID 是否值得存在，应在它自己的注册论坛提出。每一层只重审自己掌握的决定。

IANA 运行区域与列表，却不因此成为所有解析规则的作者。scheme 和命名空间权威提供资格与规范，评审者检查公共 DNS 风险，IANA 发布已接受条目，下游运营者再维护易变规则。

最关键的规则涉及时间。为了降低公共区域查询负载，RFC 3405 预计其中记录的 TTL 极长，甚至以年为单位。频繁调整的政策不适合直接置于这种缓存表面。

答案是时间尺度委派：在共享区域只保留稳定 NAPTR，用它指向 TTL 更短的另一个 DNS 区域。上层追求全球稳定与低负载，下层承担运行变化。同一条解析路径因此拥有两个时钟。

递归缓存可以继续保留第一指针，同时独立刷新下游规则。改变下游不能撤回已经缓存的旧首提示；改变首提示又可能需要很久才能普遍生效。因此审计必须记录哪一层改变、观察时适用哪个 TTL、每一步由谁控制。

并非所有 scheme 都需要动态区域。HTTP URI 已经在语法里带有主机，稳定规则可以直接提取它作为下一键；其他命名空间允许更灵活的委派，适合用稳定入口指向短 TTL 区域。下一键出现在哪里，本身就是控制结构。

urn 规则展示嵌套治理：URN 作为 URI scheme 先走 uri.arpa.，稳定规则提取 NID，然后在 urn.arpa. 下进入命名空间专属决策。共同入口没有把各命名空间政策抹平。

两条已验证技术勘误直接影响运行。Errata 2687 与 2688 把两个示例里的反向引用从 \2 改为 \1，因为每个表达式都只有一个捕获组。印刷版本的表达式无效，不能复制进生产配置。历史规范的权威性不会让错误示例自动可执行。

资格门槛后来也过时。RFC 3405 最初要求 URI.ARPA 条目来自 RFC 2717 的 “IETF tree”，但 scheme 名称树随后被取消。2011 年有人试图通过 erratum 改写要求，验证者正确拒绝：规范性资格改变需要新 RFC，不能伪装成编辑修正。

RFC 8958 在 2020 年正式完成更新：删除 IETF tree 条件，改为要求 scheme 在 BCP 35（现为 RFC 7595）下拥有永久注册。门的形状改变，基本次序保留：先建立获授权的标识符空间，再取得共享解析提示。

当前 IANA URI Schemes 注册表区分 permanent、provisional 与 historical；出现在注册表不等于符合 URI.ARPA 资格。当前 URN Namespaces 注册表则依 RFC 8141 评审。名称注册与共享区域发布仍是两项独立事件。

IANA 今天的 .arpa 页面仍把 uri.arpa 列为依据 RFC 3405、8958 的 DDDS URI 解析空间，把 urn.arpa 列在 RFC 3405 下。这证明基础设施用途被保留，不证明每个条目都部署 NAPTR，更不证明解析服务成功。

集中入口也集中风险。两个区域都是拒绝服务与伪造记录以重定向路径的目标。DNSSEC 可以认证已发布 DNS 数据，却不能证明申请者获得维护者批准、下游继续遵循规范，或最终资源真实。

完整收据应保存 scheme/NID 状态、稳定规范、获认可权威、所有者批准、提交记录、审议时间、可接受异议、IANA 接受、发布 NAPTR、DNSSEC、长 TTL、委派键、下游权威与短 TTL、规则变更、缓存观察、选中规则和消费结果。

Lu Heng 的最小初始规范原则解释两速结构：全球层只标准化最小且耐久的交接，把未来选择留到本地边界之后。运行代码优先则要求查看真实记录、应用勘误、只改下游区域、从独立缓存观察两个 TTL，并确认权威随注册维护者而不是随会写 NAPTR 的人转移。

RFC 3405 把稳定变成位置选择。第一条提示可以缓慢变化，因为它没有冒充当前规则；系统仍能适应，因为改变被局部化、可归属，并拥有自己的时钟。

来源