摘要
- 早期主机表通过一条有限链获得了实际权威：ARPA 为 ARPANET 采购了网络信息中心，SRI 维护了公共记录，参与站点提供和使用主机信息，DCA 随后将该服务纳入了国防部运营环境。
- RFC 810 为与国防部主机传输流量相关的名称和地址公布了注册前提条件，但现存规范并未展示监控、数据包拒绝、制裁、合规率或任何具体的被阻止通信。
- 公开记录并未提供完整的早期合同、主机表请求文件、争议决定、更正结果、覆盖记录、执行报告或补救措施，用以确立不受限制的 NIC 自由裁量权或扩展到每个外部网络的公共授权。
1974 年 3 月 8 日，网络信息中心要求所有 ARPANET 站点更改本地主机表。该指令出现在RFC 620，《请求更新监视器主机表》中，由 SRI 增强研究中心的 Bill Ferguson 发布。NIC 服务已迁移至OFFICE-1，网络站点为八进制 53。站点 2 仍为SRI-ARC，但其昵称将变为ARC；熟悉的昵称NIC将改为指向站点 53。该通知为 TENEX 监视器表提供了确切的条目，并要求运行其他操作系统的站点进行等效更改。
RFC 620 记录了一项指令，而非观察到的合规案例。它未指明任何执行该工作的个人操作者，未指明未执行的站点，也未指明由此导致的任何中断。然而，该文档隐含了操作者这一必要角色：每个站点必须有人以适合其操作系统的方式更改本地使用的映射。如果某个表保持陈旧，它会继续将NIC与站点 2 关联，并可能将基于名称的尝试引离预期的 NIC 服务。这一后果源于映射更改，但该 RFC 并未报告实际失败的查询或错误导向的连接。
该通知揭示了看似简单的名称背后的管理结构。SRI 可以宣布新的关联，但该公告不会重写每台远程机器。站点必须接收指令、解释并修改自己的系统。当维护的记录、分发渠道和本地实现汇聚时，共享命名才能发挥作用。
1974 年 3 月 25 日，RFC 627宣布了一种更定期的分发机制。官方主机名的在线 ASCII 文件可在OFFICE-1获取，其地址以十进制表示为 43，相当于 RFC 620 中使用的八进制 53。NIC 将维护该文件，并每周纳入添加或更改。每个网络主机负责通过文件传输协议检索新信息。更改、添加、更正和意见可通过网络邮件、电话或 NIC 身份识别系统发送给 Elizabeth “Jake” Feinler。
这两份三月份的文档并未保留完整的请求至决策的交易记录。然而，它们可以与更早和更晚的记录结合，以建立最低限度的复合重建，只要其日期保持分离即可。
1971 年，主机通过其联络人根据RFC 273中提出的程序选择了首选正式名称。联络人转达了该选择；该文档并未确立技术联络人个人拥有为站点做出每项组织决策的权威。提议的命名方案期望昵称在网络社区内唯一，并考虑了如果选择了重复或过长名称时的讨论。它未指定 NIC 否决、拒绝测试、最终决策规则、覆盖或申诉。
1974 年 1 月，RFC 608将官方主机名描述为通过主机与 NIC 之间协商获得的字符串。它建立了字符和格式限制，标识了 Feinler 的 NLS 源文件，并提议定期生成机器可读的 ASCII 版本。它未解释争议协商如何结束，或当讨论失败时谁获胜。
1974 年 3 月，RFC 627 确立了可用的文件、每周更新纳入、更正渠道以及每个主机获取新信息的责任。直到 1982 年，RFC 810才明确声明，国防部主机表的用户负责将其转换为所需的任何本地格式。将这些 1971 年、1974 年和 1982 年的陈述压缩为一个观察到的常规，或将每个步骤都分配给同一官员，是不准确的。
因此，可辩护的组合是适度的。主机通过联络人传达其首选名称。已发布的约定规管了该名称的形式，期望昵称唯一，重复或过长的选择可能引发讨论。SRI 维护了一个源，从中生成公共文件。站点检索该文件并将其内容纳入本地系统。到 1982 年，用户进行本地转换的责任被明确声明。当提议的名称仍存在争议、当更正受到质疑或当站点拒绝指令时会发生什么，仅从程序性 RFC 中无法恢复。
这是主机表权威的第一个边界。公共记录可以确定参与系统识别的名称，而无需决定底层计算机是否存在、物理线路是否已安装或组织是否已被网络接纳。其影响是操作性的，有时对于基于名称的使用来说是严重的，但它们并不等同于对所有连接的控制。
四个不同的表与公共文件的理由
在线主机文件解决了一个观察到的协调问题。1973 年 12 月，RFC 606描述了四个可访问的 TENEX 系统——SRI-ARC、BBN-TENEX、USC-ISI和PARC-MAXC——它们的主机名与地址之间的映射各不相同。没有一个是完整的，并且作者认为每个都某种程度上偏离了官方列表。
该证据不应被夸大为声称每个 ARPANET 站点都有不准确的表。它确立了四个指定系统存在分歧。即使这一有限的发现也足以证明单独维护的成本。一个人在这些机器之间移动时可能遇到不同的答案。针对一个本地集合编写的程序在移动到另一个时可能失败。新添加或重命名的主机可能在一个站点被识别，而在另一个站点仍未知。
RFC 606 提议了一个由 NIC 维护的、集中生成的、机器可读的文件。它将条目中的两个核心事实——主机名和主机地址——与可选属性（如主机状态、协议行为和昵称）区分开来。其作者警告说，属性不必完整，不应取代协议协商、口头相传或其他发现主机属性的方式。该提议有意地具体：它旨在解决不兼容的本地列表，而不是为网络参与制定全面的章程。
RFC 608 接受了集中文件的想法，并报告说它得到了 ARPA 信息处理技术办公室的支持。Feinler 以 SRI 的 NLS 格式维护源文件，同时一个程序将定期生成 ASCII 分发文件。最初，生成的条目将包含正式名称、十进制主机地址和状态。其他信息可在数据可用时添加。该文档还允许为 ARPANET 之外的主机使用网络前缀，表明作者已经考虑了一个比 ARPANET 主机群体更广泛的比较集。它并未标识实际包含的每个外部主机。
源与分发之间的区别很重要。NLS 是一个 SRI 系统，用于维护结构化信息。ASCII 版本是为异构主机的检索和处理而设计的。SRI-ARC 是发布这些通知的组织和计算背景，而OFFICE-1在 1974 年 3 月成为服务于 NIC 用户和已发布主机文件的机器。后来的文档使用SRI-NIC表示提供国防部表和名称服务的主机。这些标签标志着技术和组织上的变化；不应将它们视为同一台不变机器的可互换名称。
RFC 627 将提议转化为一项已宣布的服务。它鼓励主机在其监视器中使用官方名称，并使每个主机负责检索该文件。昵称是可选的，提供名称到地址转换的系统被鼓励而非要求使用它们。该文档提供了添加和更正的渠道，但渠道的存在并不证明所花时间、所需证据或在请求被拒绝时可用的补救措施。
该架构在使用点上仍保持分布式。SRI 维护了参考文件，但远程站点决定何时获取以及如何安装。最近更正的主文件可能与陈旧的本地副本共存。操作者可以用本地别名补充官方文件。知道数字地址的人可能绕过缺失的名称。该表减少了不一致性，而不成为分组交换子网本身。
错误的条目仍可能产生实质性影响。基于名称的程序可能将流量导向记录的地址而非预期的机器。缺少条目可能导致软件无法转换请求的名称。延迟的本地更新可能保留过时的结果。确切行为取决于本地操作系统和应用程序。RFCs 不能证明一种普遍说法，即每个遗漏都导致断开连接，或每个不准确的条目都产生相同的错误。
三月的迁移说明了一个更狭窄的命题。在NIC迁移到OFFICE-1后，实施了 RFC 620 更改的站点会将昵称与站点 53 关联。陈旧的站点可能继续将其与站点 2 关联。SRI 的服务迁移独立于远程表发生，而共享昵称的有用性取决于远程采用。该记录具有后果性，因为其他机器根据它行动。
名称始于主机，而非不受限制的 NIC 否决
公共文件并非源于一项允许 NIC 随意分配任何名称的既定规则。1971 年的 RFC 讨论记录了对命名的重大分歧。
RFC 226分发了一套提议的助记符并征求反对意见。随后出现了竞争建议。一些参与者青睐简短的呼号；另一些则希望保留机构和项目身份的名称。这场辩论不仅仅是表面上的。名称出现在命令、文档和用户习惯中。因此，命名规则分配的不仅是字符，还有不便和识别度。
在RFC 237中，NIC 论证说它是维护命名标准的合理机构，并提议一旦网络工作组确定语法和当前列表，就为新主机分配名称。这是服务运营商的一项机构提议。它证明了 NIC 希望自己的角色是什么，而不是证明每个连接的组织或上级公共机构接受了全部主张。
RFC 273 回应了先前提议未能获得接受的情况。它说主机应通过其联络人选择自己的正式名称，如果选择了重复或过长的名称，可能会进行讨论。同一机构的主机应使用相同的机构助记符。昵称应在网络社区内唯一。
该措辞确立了本地选择和集中讨论的可能性。它没有定义谁可以发出最终拒绝。重复会破坏共享昵称的目的，但仅凭技术不兼容并不能揭示行政补救措施。NIC 可能说服站点选择另一个名称；赞助者可能介入；站点可能接受了非正式惯例；或者某些分歧可能仍未解决。需要完整的案例档案才能区分这些可能性。
1971 年 12 月发布的RFC 289报告说，几乎所有站点都已回复了期望的名称。其标题“What We Hope Is An Official List of Host Names”保留了该工作的试探性质。新兴的列表反映了在有限的 ARPANET 社区内的征求和站点回应。它既不是单方面的私人发明，也不是全球公共授权的结果。
联络人的角色也需要谨慎对待。RFC 273 将联络人用作主机选择和传达名称的渠道。后来的计算机历史博物馆对 SRI ARC/NIC 记录的指南说，技术联络人通常无权代表站点管理层发言。该档案指南描述了后来创建的主机管理员角色，其持有者可以授权站点行动。由于该指南涵盖的时间跨度更长，不能简单地将其向后投射到 1971 年的每次交流中。然而，它确实警告不要将“联络人”视为与机构行政长官同义。
可以可靠地说，主机是 1971 年已发布程序中的初始选择者，联络人是沟通渠道，NIC 维护了共享结果。语法和预期的唯一性约束了在公共命名空间中可用的内容。这些文档并未揭示全面的裁决系统。
这种有限的自由裁量权仍然是有意义的。一旦名称出现在文档和机器可读文件中，其他地方的用户就可以依赖它。主机可以更改其名称，但这样做会给软件、文档和本地知识带来成本。稳定性成为了实际权威的来源。中心不需要广泛的法定权力就能使其维护的答案难以被忽视。
ARPA 的服务合同与 DCA 移交
制度链始于一项联邦研究计划，而非更广泛的互联网。
ARPANET 是一个特定的分组交换网络，由美国国防部内的 Advanced Research Projects Agency 建立。ARPA 资助了该研究计划，选择了承包商，并支持了参与的研究中心。该机构于 1972 年更名为 Defense Advanced Research Projects Agency。因此，“ARPA”适用于该网络的建立和早期的命名辩论，而“DARPA”出现在后期的记录中。
1978 年编写的ARPANET 完成报告称，Stanford Research Institute 获得了一份为 ARPANET 开发和运营网络信息中心的合同。工作于 1969 年与网络实施同时开始。该报告描述了一项服务，维护参与者和分发列表、存档技术文档、提供关于主机资源的信息、提供对 SRI 的 NLS 系统的访问，并维护 ARPANET 协议规范。
这确立了赞助者-承包商关系。ARPA 为其支持的网络和研究社区采购了一项信息服务。SRI 有义务履行合同所要求的任何内容，ARPA 拥有相应的合同履行权利。该公开报告未复制早期的工作说明书、修正案、验收标准、制裁、数据条款或主机名决策规则。因此，它无法确定该义务的全部法律内容。
连接到 ARPANET 的站点在制度上是多样化的。它们包括大学、研究机构、政府实验室、军事设施和私人承包商。法律形式的多样性并不使每个站点成为无关联的公共运营商。许多站点通过联邦赞助、合同或批准的任务关系参与。同时，由于缺乏基础站点文书，无法声称每个连接的组织都有相同的合同条款要求遵守主机表。
从 ARPA 到 Defense Communications Agency 的移交最有力的直接描述是分阶段且注明日期的。完成报告描述了一份 ARPA-DCA 备忘录，根据该备忘录，ARPANET 的管理权于 1975 年 7 月 1 日移交给 DCA。它还记录了一个为期六个月的逐步过渡期，持续到 1975 年 12 月 31 日，在此期间 ARPA 继续协助 DCA，同时 DCA 承担管理角色。详细的过渡计划已于 6 月完成。
该报告称，移交的网络将作为一个国防部设施运行，用于政府业务。DCA 将通过涉及 ARPANET 赞助者的成本分摊安排为运营和维护提供资金。DCA 最初将与 BBN 和 SRI 签订合同，负责网络运营、维护和 NIC 职能。报告称，显然暗示 DCA 以后可以保留其他承包商，当然是在第一年之后。
这是在承包商选择层面机构可替换性的证据。它并不证明 DCA 拥有每项 NIC 记录的完整可移植副本、对承包商创建数据的无限权利、经过测试的过渡方案或对每次服务故障的可执行补救措施。客户原则上可以选择另一个提供商，但在转移人员知识、软件、档案、当前记录和站点关系方面面临巨大的实际障碍。
一份 1978 年的 DCA 出版物，索引为ARPANET 信息手册，也将 1975 年 7 月 1 日作为管理移交日期。后来的计算机历史博物馆查找工具提供了一份相互矛盾的回顾性陈述：它说 ARPANET 运营于 1973 年移交给 DCA，并且 DCA 合同资金从 1974 年后支持了 SRI NIC。
这一冲突应保持可见。完成报告中的正式备忘录年表提供了精确的移交日期和逐步过渡期。查找工具提供了不同的摘要日期，但未提供能协调这些日期的基础文书。它还称 NIC 在 1973 年成为一个单独项目，这是与 ARPANET 管理移交不同的机构变化。没有相关合同和行政记录，1973 年的运营声明和 1974 年后的资金声明无法转化为一个无缝的年表。
在正式移交后，DARPA 可以继续赞助使用 ARPANET 的研究，而 DCA 管理该运营网络。国防部是上级政府环境；DARPA 和 DCA 在其中具有不同的职能。SRI 仍然是执行 NIC 服务的承包商，而不是成为政府本身。参与站点运营主机。主机联络人和后来的联系角色传递信息和指令。保持这些角色分明，可以防止将采购权威误认为是普遍权威。
加入 ARPANET 并非主机表决定
主机表记录了操作环境中的机器，但 SRI 对该记录的维护并未使 SRI 成为决定谁能加入 ARPANET 的唯一权威。
1978 年 12 月的 ARPANET 目录描述了订户类别和获取服务的过程。其框架将准入和赞助置于 DCA 的网络管理结构中。潜在订户需要可接受的政府目的、赞助和可用设施。这些决定涉及对特定管理网络的访问。
这一区别是根本性的。DCA 可以管理 ARPANET 订户资格。SRI 可以维护在准入后或准入前后使用的目录和主机信息。主机表条目对于方便的共享使用可能是必要的，但记录主机与批准组织连接、安装接口消息处理器、提供电路或授权任务是不同的机构行为。
ARPANET 的群体也不应与国防部互联网等同。ARPANET 是一个网络。国防部互联网是一个网络互联环境，其中 ARPANET、分组无线系统、卫星系统和其他网络可以使用互联网协议和通用协调信息。更广泛的新兴互联网更加广阔：一组不断变化的网络、实验和运营商，其法律、合同和技术关系并不统一。
到 1981 年 9 月，RFC 790列出了众多命名网络的已分配互联网网络号，包括 ARPANET、UCLNET、CYCLADES、TELENET、英国邮政局 EPSS、DATAPAC、TRANSPAC、LCSNET、TYMNET 以及各种分组无线、卫星、本地和实验系统。它指明了南加州大学信息科学研究所的 Jon Postel 为网络号分配的联系人。
该列表证明，已分配号码的环境超出了 ARPANET 主机的列表。它本身并未确立每个命名网络在那时都已操作上互联，独立于政府赞助、商业、非国防部或受 SRI 主机表流程管辖。出现在分配文档中的号码并不是对网络合同状态或实际流量的完整说明。
它还分离了后来历史有时模糊的功能。Postel 在南加州大学信息科学研究所的分配号码角色涉及网络和协议参数。SRI 维护主机表和名称服务。DCA 管理 ARPANET 并委托 NIC 服务。DARPA 继续研究赞助。这些事实中没有一项使一个参与者成为整个新兴互联网的唯一作者。
因此，“第一个互联网账本”这一短语需要一个明确的比较。主机表不是计算机组织维护的第一个目录，1974 年的文件也不是全球公共互联网的注册机构。它是 ARPANET 到互联网谱系中一个早期的共享、机器可读的名称和地址参考。到 1982 年，其后续格式纳入了网络、网关和互联网地址，并被其运营商描述为一个全球主机名和地址数据库。其历史意义在于该参考范围的扩大和跨组织的依赖性，而非对每个网络的已证授权。
1982 年国防部规则：公布的先决条件，而非经证明的强制执行
RFC 810 标志着范围和组织语言的变化。它于 1982 年 3 月 1 日由 SRI International 网络信息中心的 Feinler、Ken Harrenstien、Zaw-Sing Su 和 Vic White 发布，称早期的 ARPANET 主机表不再满足国防部社区或网络互联的需求。新格式包括网络、网关和主机条目、互联网地址、操作系统和协议信息。
该表可通过 FTP 和主机名服务器从SRI-NIC主机获取。该 RFC 将该服务器标识为由 ARPANET NIC 代表 DCA 维护的服务。它还明确将转换责任分配给用户：谁使用该表，就必须将其转换为本地所需的格式。
其第七项假设包含了主机表记录中最强硬的运营措辞。国防部网络、网关和主机的名称和地址在使用之前以及在国防部主机传递流量之前，须与 NIC 协商并注册。这是一项约束国防部主机行为的已公布先决条件。它比 1974 年鼓励使用官方主机名更直接地将注册与运营联系起来。
该句子并未记录强制执行。RFC 810 未指明检查注册的监视器、拒绝未注册流量的路由器规则、对不合规的制裁、合规率或任何被阻止的具体通信。这一区别很重要。规范可以定义要求的行为，而不证明操作者执行得有多一致。
该文档对非国防部信息的处理方式不同。在一个过渡期内，NIC 将尝试为非国防部网络和主机维护类似信息，前提是提供了这些信息，并且只要需要就维护，直到有相互通信的名称服务器。它既未标识实际包含的每个非国防部条目，也未对所有外部运营商施加相同的明确先决条件。
新格式还实行了分阶段引入。RFC 810 指定 1982 年 5 月 1 日为切换日期。在 5 月期间，现有HOSTS.TXT路径仍保留旧版本，而新格式测试文件可单独获取。在 6 月和 7 月期间，主路径提供新格式，而旧格式材料仍可通过另一路径访问。8 月 1 日之后，RFC 608 规定的旧HOSTS.TXT格式将不再支持。
该重叠区分了已公布的设计与立即的普遍实施。程序有时间适应。在过渡期间，本地系统可以保持在不同版本上。该时间表显示了对兼容性风险的积极管理，但它并未证明每个主机都按时完成了转换。
同日发布的RFC 811规定了在线主机名服务器。程序可以查询主机名或地址，或请求整个表。服务器可以返回主机、网关或网络记录。如果请求的名称不存在，定义的错误格式为ERR: NAMNFD: Name not found:。其他错误也可能发生，包括TMPSYS，表示临时系统故障，请求稍后重试。
这些语义属于 SRI-NIC 服务器协议。它们不应投射到使用下载副本的每个本地解析器上。针对缺少条目的表进行的本地查询可能失败、使用补充映射、提示用户或以其他系统依赖的方式运行。本地副本中名称的缺失与来自服务器的NAMNFD响应是相关条件，不一定是相同的事件。
RFC 811 将其数据库描述为旧 ARPANETHOSTS.TXT文件的扩展，并称集中管理是通往分散式、分布式名称地址转换服务过程中的临时解决方案。这一机构声明因两个原因而重要。它表明 SRI 将服务理解为一种过渡机制而非永久架构，并确认该表的人口和目的已超出最初的 ARPANET 列表。它并未独立证明普遍覆盖。
到 20 世纪 80 年代初，NIC 越来越与 Defense Data Network 环境相关联，后来的历史收藏使用 DDN-NIC 这一名称来指代该服务。该后来的标签不应被回溯到 1969 年的合同或 1971 年的主机名辩论中。SRI-ARC、SRI NIC、SRI-NIC 和 DDN-NIC 描述了相互关联但在时间上有所区别的组织和主机背景。
档案能展示什么——以及仍然缺失什么
RFC 系列在提议、规范和公告方面异常丰富。但作为个别行政案例的记录，它薄弱得多。
计算机历史博物馆的查找工具标识了相关收藏：NIC 提案和合同、进展报告、命名和寻址记录、主机表、参考服务资料、通信和有关官方网络联系人的记录。它称早期的 NIC 合同没有分解为任务，后来的合同变得更加详细。它还描述了技术联络人、主机管理员、节点站点协调员以及其他信息或行动消息通过其传递的联系人。
查找工具确立了记录的存在、大致主题和排列。它并未披露每份合同、信件或决定的内容。其描述不能证明主机名请求以特定方式被批准、拒绝或升级。底层文件需要被打开和比较。
这里没有提供完整的请求文件，显示主机提议的名称、NIC 的问题、站点的回应和最终处置。没有任何保存的案例展示 NIC 因重复而拒绝、成功的上诉、赞助者覆盖或纠正补救。没有任何全面的登记册提供处理时间或错误率。RFC 627 的联系方式证明存在纠正渠道；它们并不证明通过该渠道交付的结果。
缺失的合同因另一个原因而重要。联邦合同可以赋予履行权利，而不赋予每项记录的所有权、技术系统的所有权或对承包商创建数据的不受限制的权利。它可以规定交付物、数据许可、过渡援助和补救措施，但这些后果取决于其实际条款。
很久之后的政府问责办公室对联邦互联网职能安排的分析仔细区分了履行权、数据使用权、所有权和所有权。该 2016 年的意见涉及后来的 DNS 和 IANA 安排，并不提供 SRI 20 世纪 70 年代合同缺失的条款。它在这里的价值是方法论的。仅凭联邦资助不能用于推断每项财产或过渡权利。
完成报告确实支持一个更狭窄的结论：DCA 最初打算保留 SRI 履行 NIC 职能，稍后可以使用其他承包商。这显示了设想的提供商可替换性。它并未确立替换可以在没有延迟、数据争议、软件转换、机构记忆丧失或服务中断的情况下发生。
RFC 810 的流量条件也缺乏实施记录。要从公布的规则转向经证明的执行，人们会想要 DCA 指令、主机软件、审计日志、事件报告、制裁或记录在案的被阻止流量。没有这些材料，文章可以确定规则声明的范围，但不能确定其观察到的效力。
沉默必须在两个方向上都起作用。缺乏公布的申诉程序并不证明不存在非正式的升级途径。电话、网络邮件、NLS 交流和赞助者干预可能在没有 RFC 的情况下解决了争议。相反，缺乏公布的投诉并不证明每个参与者都认为过程合法或每次更新都是及时的。
由此产生的不确定性是制度性的，而不仅仅是古董倾向。如果请求通常通过透明的站点确认得到纠正，该服务看起来会更行政化和合作性。如果 NIC 可以在没有解释的情况下拒绝条目，并且没有赞助者审查存在，那么相同的文件将承载不同的治理意义。公开证据不支持任何一种极端作为一般性描述。
本地列表替代方案及其真实成本
公共文件在历史上可行的替代方案不是现代域名系统。而是在 RFC 606 之前已经可见的做法：每个站点维护自己的映射，通过个人沟通获取更改，并将远程信息转换到自己的操作系统中。
在四个站点，这可能是可管理的。管理员彼此认识，协议设计者定期会面，更正可以通过电话、文件或网络邮件传递。站点可以在不等待中央发布的情况下采用本地别名。如果两个组织频繁通信，即使中央机器不可用，他们也可以保持共享信息的最新。
维护负担迅速增长。有十个站点，每个站点为其他九个站点维护条目，最多可能有 90 个定向本地映射。有一百个站点，最多可能有 9900 个。这些数字描述的是站点上保存的定向副本，而非 90 或 9900 个不同的双边关系。实际需要的映射数量取决于通信模式，但每个新目的地都会产生更多信息可能过时的地方。
主机添加或地址更改必须通知多个管理员。每个人都会在单独的时间表和本地格式中应用它。更正可能被一个站点确认，被另一个站点遗漏，被第三个站点错误转换。操作员需要识别他们拥有哪个版本，比较冲突的报告，并确定明显的服务故障是来自网络、远程主机还是过时的映射。
RFC 606 提供了观察到的警告：四个指定的 TENEX 系统已经拥有不完整、有分歧的表。它并未量化由这些差异造成的失败。分歧本身证明了重复维护和不一致的答案。
一个公共来源减少了这种负担。受影响的主机可以通过一个公认的渠道传达信息。SRI 可以生成一个版本。站点可以获取相同的文件，并将其本地状态与带日期的参考进行比较。调查差异的支持操作员有了一个可以开始的焦点。
公共文件并未消除所有分发成本。每个站点仍需要存储、检索软件、本地转换和更新程序。每周发布在报告变更与其在下一版本中出现之间引入了延迟。当服务主机或网络路径不可用时，获取可能失败。本地安装可能在成功检索后滞后。该架构集中了编纂，而非每项操作任务。
一个公共来源也不能保证真实性。SRI 依赖于主机和联系人来提供准确信息。一个站点提供的错误地址可能进入主文件。正确的中央更新可能被过时的本地部署破坏。如果决定冲突的程序不明确，冲突可能持续存在。该参考使分歧可见并减少了重复，但它并未消除验证的需要。
本地列表替代方案解释了为什么组织遵从 NIC 文件，而无需要求一种无限命令的理论。一个维护的答案比许多独立重建的答案更便宜地消费。当软件和文档使用公共名称时，它们变得更可靠。由此产生的依赖赋予了维护的记录以操作力量。
拥有多个分发者的公共账本
第二种时期可行的替代方案本可以保留一个规范文件，同时更广泛地分布存储和检索。
该想法出现在当代文档中。RFC 623提议 NIC 保留主文件，而另一台主机维护一个频繁更新的辅助副本。其作者自愿提出 UCSB 并建议每日同步。目的是可用性：如果 NIC 主机无法提供文件，用户可以尝试辅助主机。
RFC 625接受了多个主机应维护副本的原则，并欢迎 UCSB 作为预期的辅助主机。它不同意用专用检索协议替换 FTP。3 月晚些时候发布的 RFC 627 仍邀请任何希望维护辅助副本的主机联系 NIC。
这些记录确立了一个提议并被接受的复制设计。它们并不证明 UCSB 或其他主机运行了一个正常工作的镜像。确认需要运营通知、服务器日志、存档的辅助文件、主机手册或后续报告。该提议不应被重写为部署。
如果这样一个辅助主机运营了，它将需要时期合适的资源。站点需要存储该文件的空间、检索更新的员工或自动化程序，以及足够频繁的时间表以保持其版本有用。用户需要知道联系哪台主机以及如何识别最新的规范版本。辅助主机需要一个规则，规定当其本地副本与 SRI 的不同时该做什么。
一次中断可能会使协调变得困难。假设辅助主机错过了两次更新，而 SRI 仍然可用，然后带着旧版本重新上线。将需要时间戳或序列约定，以防止用户将可用性误认为最新性。如果在有争议的更正到来时 SRI 不可用，辅助主机需要知道它是否可以发布该更改，或者仅仅是继续提供最后确认的主文件。
复制还使得修订权限未解决。镜像可以分发规范文件而不决定条目。赋予它独立的编辑权力将产生竞争主文件的可能性。避免这个问题需要在证明其事实的组织、协调共享命名空间的中心、提供副本的分发者以及处理争议的任何审查者之间进行明确分工。
站点确认本可以在没有现代基础设施的情况下得到加强。在每周发布之前，NIC 本可以将提议的更改发送给受影响的联络人或授权的站点联系人。带日期的更改通知本可以附随生成的文件。辅助保管者可以将宣布的更改与他们收到的文件进行比较。站点可以根据特定版本而不是无日期的本地副本来报告差异。
这些程序会带来成本。联系人必须回应。更正可能需要等待确认。员工必须维护日志并协调未答复的请求。变化迅速的主机可能会觉得每周周期太慢，而更频繁的分发增加了计算、网络使用和操作员工作负载。正式审查可以提高问责制，同时也会延迟紧急更正。
承包商过渡带来了一个更大的问题。DCA 选择另一提供商的能力并不能保证无缝替换 SRI。继任者需要当前的规范文件、生成它的软件、格式和发布计划的文档、待处理的请求、更正历史、联系人列表、员工知识和访问服务环境。如果合同未规定交付或数据使用权，转移可能在法律上和操作上都变得困难。
现存的公开文件并未确立这些过渡材料是否作为可执行的交付物存在。它们表明设想了不同的承包商，而非存在经过测试的转移机制。纸面上的可替换性与运营中的连续性是不同的成就。
这一替代方案澄清了治理选择。一个单一的逻辑答案不需要一个单一的物理分发者。规范版本可以与镜像、站点确认、保留的更改和替代服务提供商共存。每项添加都会转移成本和责任，而不会消除最终协调的需要。
标有日期的权威链，而非普遍授权
在 1969 年至 1983 年间，主机表的权威通过一系列不同的关系积累起来。
1969 年，ARPA 为 ARPANET 采购了一个网络信息中心。这确立了一位联邦客户、一个 SRI 承包商和一个明确的服务群体。它并未使 SRI 成为每个计算机网络的代表。
1971 年，主机被邀请通过联络人在已发布的约定中选择名称。ARPANET 参与者之间的辩论和回应提供了有限的对等接受。NIC 提议的角色被本地选择缩小，而共享命名空间仍需要兼容的结果。
1973 年和 1974 年初，不同的本地表促使了机器可读的公共文件。RFC 606 和 608 记录了提议和源设计。RFC 620 和 627 记录了一项具体的站点范围更改指令、可用的 ASCII 文件、每周更新、本地检索责任和更正渠道。它们并未记录一般的 NIC 否决或完整的争议系统。
1975 年 7 月 1 日，根据完成报告中描述的 ARPA-DCA 备忘录，ARPANET 的管理权移交给 DCA，随后逐步过渡到 12 月 31 日。DCA 最初保留了 SRI 履行 NIC 职能，并可能考虑另一承包商。查找工具相互矛盾的 1973 年运营移交声明和 1974 年后资金说明仍未解决。
到 1978 年，DCA 的订户框架将 ARPANET 准入置于政府网络管理内，而非 SRI 主机表维护内。这将准入订户的权威与记录和分发主机信息的服务分离开来。
到 1981 年，已分配号码环境列出了 ARPANET 之外的许多网络，而网络号分配被标识为与南加州大学信息科学研究所的 Postel 相关。出现在该列表中并未确立每个网络都与 DCA 或 NIC 共享一种法律或运营关系。
1982 年 3 月，RFC 810 规定了一个更广泛的国防部互联网主机表，并将事先注册作为与国防部主机传输流量相关的名称和地址的条件。其对非国防部信息的单独临时处理标志着一个边界。该规则是明确的；其执行仍未得到证明。5 月至 8 月的切换进一步表明，规范、过渡和完成的本地实施是不同的阶段。
RFC 811 的服务器通过在线查询使维护的答案可用，并将中央数据库描述为通往分布式命名的临时桥梁。该服务增加了对 SRI-NIC 的依赖，同时承认该架构并非旨在保持永久集中。
因此，主机表现在三个地方行使了其最强已证明的权威。SRI 在其条款不完整的合同范围内对其联邦客户负有履行义务。DCA 可以为其管理的国防部环境发布运营要求。参与的机器和用户依赖公共记录进行一致的基于名称的通信。
在这些关系之外，该表的覆盖范围源于互操作性和采用。外部网络可能提供信息或使用公共文件，因为这样做使通信更容易。这种依赖是后果性的，但 RFC 810 并未将其描述为等同于国防部先决条件。没有任何审查过的记录显示一个全球范围内的支持者将一般性权威委托给 SRI。
该表也没有创造它所记录的一切。赞助者批准了网络参与；承包商和站点提供了机器和软件；电路和分组交换机承载了流量；其他机构处理了网络号码；本地系统消费了已发布的映射。NIC 的记录有助于使名称普遍可识别，但它并未创造底层组织、物理连接或每个数字分配。
然而，其实际权威是实质性的。一个被许多机器消费的共享记录可以约束行为，即使没有立法机构或公共成员机构创建它。希望获得可预测识别的主机有理由遵循命名约定。希望获得最新答案的站点有理由检索公共文件。国防部主机受到已公布的注册先决条件的约束。非国防部运营商可能会发现偏离代价高昂，因为其他系统期望维护的答案。
同样重要的是仍未得到证明的内容。现存的公开证据并未显示 NIC 拥有其列出的地址、可以随意排除任何外部网络、对每个不合规站点实施制裁、或将每个缺失条目转化为物理断开连接。它并未揭示完整的申诉结构、纠正补救措施或覆盖层级。它并未确立对所有 NIC 数据的可移植政府所有权。
早期的主机表在采购、网络管理和机器依赖交汇之处具有权威性。它解决了一个具体问题：不兼容的本地映射使共享名称不可靠。集中编纂使一个答案更易于分发、比较和使用。这一成就解释了为什么该记录在名称和地址成为市场资产之前就获得了力量。
它并未证明该记录的运营者获得了对记录所能描述的每个网络的权威。历史链支持一个更狭窄的结论：SRI 为一个受赞助网络维护了一个联邦委托的参考，该参考嵌入了国防部互联网运营中，更广泛的依赖扩大了其实际覆盖范围。该账本的实用性使其强大。其公共授权仍未确立。