摘要

  • RFC 1480 为 .US 列出三种登记情形：委派一个分支、用 A 记录直接登记 IP 主机、用 MX 和转发主机直接登记非 IP 主机。名字可见，不能说明背后是哪一种安排。
  • 委派把分支控制权交给指定管理者，同时附上公平服务、技术胜任、数据准确、服务器冗余、社区责任和协商转移等持续义务；由上级把一条记录写进总库并不会自动产生这些权力。

同一棵树里有三种“存在”

RFC 1480 于 1993 年 6 月发布。它把 .US 按州、地方和 K12、LIB、FED、GEN 等用途组织起来。对查询者而言，这套层级把学校、图书馆、小企业和政府机构放在同一种点分语法中。

登记环节却没有把它们压成一种对象。文档先区分“委派”与“直接登记”，又把直接登记分成 IP 主机和非 IP 主机。一个名称可以由 .US 总库直接维护，也可以落在别人运行的子区中；它可以指向自身的 IP 地址，也可以只为邮件指向一台联网的转发机。

名字末尾相同，只证明它们能在同一命名体系中被找到。谁能修改、哪台机器联网、谁承诺服务，仍需另找记录。

A 记录没有把子树交给申请者

IP 主机的直接登记对应 A 记录。上级管理员受理申请，把地址写进自己维护的数据库。RFC 1035 规定 A 的数据是一个 32 位互联网地址；这个响应没有声明申请者可以在名字下面继续创建区。

控制权来自另一道动作。RFC 1034 把委派描述为找到适当的上级区，并得到它同意移交一部分树的控制。NS 记录标出应当为该区提供权威数据的主机。A 和 NS 可以同时出现，但它们回答的不是同一个问题。

这一区别在修改时最清楚。直接记录需要由仍掌握总库的一方修正；被委派的管理者则在自己的区里操作。一次成功解析不会随响应附上完整的行政授权链。

MX 统一了地址，没有让 UUCP 主机变成 IP 主机

RFC 1480 特意为非 IP 主机留下位置。许多申请者处在 UUCP 网络，有的直接连接互联网转发机，有的还要经过一两台中间主机。它们仍可获得 DNS 风格名称，让外部发送者使用普通的互联网邮件地址。

做法是由 MX 指向愿意代收的 IP 主机。RFC 1035 给出 MX 的交换机语义，RFC 974 说明邮件路由选择。两者都没有把 MX 的所有者名称解释为可直接进行 IP 通信的终点。

DNS 界面后面还要补齐协议外事实：转发机愿意承担工作，双方有行政约定和技术流程，转发机保存通往 UUCP 主机的本地规则；若路径中还有一台 UUCP 主机，它也必须知道下一跳。.US 管理员可以添加 MX，却不能替申请者取得这些同意。

因此，MX 响应能证明某个时刻公开了邮件入口，不能证明电话链路接通、转发规则仍在、队列已处理或收件人收到邮件。抽象让用户不必看见边界，运维证据却不能把边界删掉。

委派交付的是一项受约束的职责

随着登记增长，中央管理者不可能长期处理全部 .US 名称。RFC 1480 举出 K12.TX.US、berkeley.ca.us 和 LIB.MN.US 等可委派分支。分工既转移工作，也转移了在该分支内作决定的权限。

文档没有把“能跑两台 DNS”当成充分资格。指定管理者应公平、诚实并具备技术能力；不得偏袒关联网络服务商的客户，也不得强迫申请者采用某个邮件系统、协议或产品。与该域密切相关的各方应认可管理者合适。

上级管理员通常要求争议各方先达成一致，只在指定管理者严重失责时介入。与此同时，数据库必须准确、稳健，申请必须及时处理。主、备服务器都要有 IP 连通性并可检查状态与数据；不同物理地点可防止一次本地灾害同时消灭服务。

NS 只指明预期的权威主机。它没有证明两个故障域独立，也没有证明管理者公平、胜任或获得社区认可。

名字不变，托管责任仍可能易手

指定管理者的 trusteeship 转移需要新旧两家机构分别来函，让上级确认双方同意，而且继任者理解职责。受影响各方的意见也构成有用证据。

这不是更换机器后自动完成的产权交割。机构同意、上级确认、服务器切换和实际数据健康可能发生在不同时间。若只保存最终 NS 集合，就无法回答争议发生时谁拥有决策权。

RFC 1591 随后把原则扩展为通用表述：国家域管理者代表互联网社区提供公共服务，指定管理者同时为本国和全球互联网社区承担托管责任。它解释制度逻辑，却不能替任何具体分支出具履职证明。

这是一份 1993 年的方案，不是现状截图

RFC 1480 取代了仅早六个月发布的 RFC 1386。快速修订说明命名政策在增长中被维护，并不能统计多少分支真正完成了委派。

地理层级优先解决唯一性和管理规模，而不是保证每个机构都得到最短、最直观的名字。RFC 920 和 DNS 基础 RFC 提供了此前框架；RFC 1480 记录的是当时对美国域管理工作的具体切分。

RFC Editor 信息页 将它列为 Informational。文档还明确说没有讨论安全问题。冗余与公平义务有价值，但不是身份认证、授权或安全结论。

多年后核验的勘误为附录 BNF 补上一条遗漏的选择符。它修复文本语法，不会追认历史上任何区的状态。

查一个名字之前，先问是谁在作证

可靠账本要分别保存所有者名称、记录类型、发布它的权威区、委派切点、指定管理者、服务器集合和观察时间。若主张邮件可达，还要保存转发同意、UUCP 路径规则、尝试、队列和收件回执；若主张控制权，还要保存管理者选择与转移文件。

DNS 的成功在于让差异很大的系统共享一种名称接口。历史记录的责任，是不让这层便利把权限、连通和交付重新揉成一个模糊的“存在”。

资料来源