摘要

  • RFC 897 明确区分“名称变成层级形式”与“查询从中央表转向分布式服务器”，因此新名称可以先由旧表承载。
  • RFC 921 没有抹去第一份计划，而是标出哪些按期完成、哪些迟到、哪些仍未完成。
  • 服务器可用、数据装载、应用改造和旧表退役是四种不同证据；不同社区、同一主机上的不同应用也可能处于不同阶段。

DNS 之前的名称服务也不是“中央有一张表”这么简单。RFC 810 规定由 NIC 维护可供机器转换的主机表；接收站点仍要取得它，再转换为本机软件需要的格式。RFC 811 定义 Hostnames Server，既能回答单项查询，也能交付完整表。中央记录正确、文件成功传输、本地安装完成、应用实际使用，本来就是四件事。

RFC 881 把迁移难题写成一个“先有鸡还是先有蛋”的困局。只要少数机构开始发送带点的名称，这些名称就会进入所有人的邮件和通信；但若等所有程序同时准备好，合理期限内几乎不可能启动。它提出的桥接方案有意容许混合状态：先并行提供域式主机表，随后让它成为主表，最后用 resolver 替换原先的主机表库调用，使多数应用不必知道地址来自文件还是服务器。

RFC 882 与 RFC 883 给出名称、类型化数据、区域、服务器、转介、解析器与缓存的分布式设计。它们能证明协议已被写出，却不能证明某个 mailer 已不再打开本地文件。实施时间表填补的正是这段“规范”与“运行”之间的空白。

改名完成，不等于解析迁移完成

1984 年 2 月发布的 RFC 897 把两类变化并排写清。第一类改变主机名本身：从全局平面字符串转为层级名称。第二类改变名称到地址的支持机制：从本地持有中央完整表，转为动态访问分别持有数据库一部分的服务器。

它给出四步路径。先给旧名称加上 .ARPA；再引入少数几个域；然后从中央表切换到名称服务器；最后允许许多域。因此，看到 USC-ISIF.ARPA 只能证明名称形式已经变化，不能证明解析器参与了查询。同一个带点名称完全可以先写进 HOSTS.TXT。

固定后缀降低了最初的改名成本，却没有消除名称在外部复制后的后果。旧名可以暂时保留为别名，帮助仍使用旧标识的请求到达本机。但本机无法改写远端保存的通讯录，无法修复旧邮件中的 From、To、Cc，也不能自动更新由别处维护的邮件列表。标识一旦传播，迁移状态便不再由被改名的一方独占。

分布式数据库还要保留从地址找到主名称的能力。这是一项跨管理边界的一致性要求，不是身份认证。反向结果正确，不代表对端就是所声称的组织，也不代表应用当前可用。

同一天换名，不代表承担同一种义务

RFC 897 给出了具体日期：1984 年 3 月 14 日开始把域式名称作为主名称；5 月 2 日停用旧式名称并允许部分新域；6 月 6 日开放一般多级域；7 月 18 日允许代表机构的域名；9 月 5 日后，NIC 的主机表不必再覆盖 ARPA 研究社区；10 月 3 日应有 DDN 后续方案。

这些日期没有把两个社区变成同一种实施对象。ARPA 研究社区要完成整套迁移。DDN 运行社区按同一日程改名称，却不必同时强制改用服务器；其项目办公室以后另订计划，NIC 继续为它维护中央表。

所以，两台主机可能都显示新式名称，却由不同的数据权威回答查询。共同的命名外观不是共同的运行状态，更不是完成证明。

RFC 921 把延期留在公开记录中

RFC 920 到 1984 年 10 月才正式给出建立新域的要求，并调整顶级域安排。RFC 897 原先为它留下的是 2 月节点。制度设计在实施过程中仍在变化。

RFC 921 修订日程时，没有删除旧表。它明确写出：最初的域式主机表和 3 月改主名称按期完成；ARPA 域服务器终于运行，但到 9 月才做到，而非原定 4 月；顶级域服务器表、新域、多级域、机构名称间接寻址、主机表退役与 DDN 计划都尚未完成。

修订文件又把实施分成三段。machinery 是服务器和解析器本身；database 是相关数据真正装入；user programs 则是邮件、Telnet、FTP 等程序开始调用新机制。1984 年 10 月时，机器层面已经有明显进展，ARPA 数据也已存在，其他顶级域得到初始化，但用户程序改造仍很少。

新节点延伸到 1985 年 10 月。它们仍只是将来目标。RFC 921 最可靠的历史证据不是“又定了一次日期”，而是用“完成、迟到、未完成”把不同层的实际状态保存下来。

混合期最终落到每个应用内部

到了 1987 年 11 月，RFC 1031 仍把 MILNET 迁移描述为同时存在的三个阶段：只用主机表、表与 DNS 混用、只用 DNS。同一主机的 Telnet 与 FTP 可以先迁移，邮件继续查表；顺序也可能反过来。主机是一个管理单元，却不一定只有一个迁移状态。

RFC 1031 当时称多数主机仍在第一阶段。老旧架构或不可修改的软件可能永远无法改造。共享主机表终止后，它们必须通过双边协议、特定社区的仓库或本地维护取得等价数据。原本公共的后备路径由此变成一项新的、需要明确责任人的依赖。

RFC 1034 后来总结 HOSTS.TXT 分发的扩展成本，并让 resolver 接口可以模仿旧的主机名查询函数。这种兼容性让应用无须一次性重写，也意味着只观察界面无法判断答案来自哪条路径。

RFC 1401 收录的 1992 年 IAB 与 DISA 往来信件称 MILNET 的 DNS 迁移仍未完成，并把不同步的表与 DNS 映射同可达性失败联系起来。这是有立场的政策文件，不是中立的采用率普查；但它足以证明，1984 年被分开的迁移支线多年后仍在产生运行后果。

来源与边界

本文依据 RFC 810、811、881、882、883、897、920、921、1031、1034 与 1401。它们能证明规范、政策节点、逐项审计与后续文件记录；不能证明一个全球统一切换日、每个站点都合规、名称完成认证、当前可达或任何现行产品行为。