Summary

  • 伯克利 1984 年的技术报告把 BIND 描述为面向分布式 Unix 环境的名称服务，并未声称伯克利发明了 DNS 或编写了第一台 DNS 服务器。
  • 到 1987 年，运维文档已经说明 BIND 随 4.3BSD 一同分发。两年后，互联网指南称其已集成进 4.3BSD，可替代基于 /etc/hosts 的主机名查询。
  • 变化发生在运行层：规范规定互通行为，软件分发和本地维护的区域数据则让管理员能在自己的网络上提供名称解析。

仅有协议还不够，还要有能运行的服务器

一个名称系统可以在纸面上设计得很漂亮，却仍然无法改变日常运维。有人必须安装服务器、提供数据、持续更新，并让本地程序向它查询。伯克利对早期 DNS 的贡献，是让这套工作可以在 Unix 环境中落地。

1984 年，Douglas Terry、Mark Painter、David Riggle 和 Songnian Zhou 发布了关于 Berkeley Internet Name Domain 服务器的技术报告。摘要提出一种面向分布式 Unix 环境的统一资源命名方式，支持存储和检索信息，并将层级名称空间划分为对应不同管理实体的域。这描述的是软件与运维模型，而非 DNS 的发明权。Paul Mockapetris 更早编写的服务器 Jeeves 已在 USC-ISI 和 SRI-NIC 运行；ISC 后来的历史记载也把 Jeeves 与伯克利项目区分开来。

BIND 要解决的实际问题是：一台 Unix 主机怎样参与一个数据由多个管理域分别维护的名称系统？它把服务器、本地文件和主机已有的解析路径组合在一起。一个域的管理员可以维护名称树中归自己负责的记录；解析器再沿委派关系询问相应服务器，并缓存答复。所谓分布式，指数据和责任分散在不同管理者手中，而不是要求每个用户记住每台机器放在哪里。

正在运行的网络也反过来塑造规范

时间顺序很重要。DNS 的早期描述见于 1983 年的 RFC 882 和 RFC 883。到 1986 年 1 月，Paul Mockapetris 的 RFC 973 已经记录了系统变更、运维建议、已观察到的问题和不足。它明确指出，已经广泛使用的变更应视为规范的一部分。这说明协议文本在系统运行时吸收了实现者和操作人员的经验。

修订后的 RFC 1034 和 RFC 1035 于 1987 年 11 月发布，分别阐述 DNS 概念和实现细节。名称、记录、查询、缓存和委派都需要各方共同遵循的规则。但 RFC 并不是管理员可以安装的软件包；还需要实现程序和运维说明。

伯克利 1984 年的报告把 BIND 定位为分布式 Unix 资源的名称服务。ISC 的 BIND 历史列出最初的伯克利团队，并称 Computer Systems Research Group 维护该软件直至 4.8.3 版。这份回顾可以说明开发脉络，却不能证明每个版本有多少安装量。

BSD 的软件分发让管理员拿得到这项服务

同期的线索见于 RFC 1033，这份 1987 年 11 月发布的域名运维指南。它有一个附录，标题明确写着“随 4.3 BSD UNIX 分发的 BIND”。文档介绍了 BIND 自己的启动文件和缓存文件，包括 named.boot，并列出区域数据示例。它没有说每台 BSD 主机都运行名称服务器；它说明的是，管理员可以从熟悉的 Unix 发行版中获得 BIND，也能找到配置指南。

这种打包降低了尝试成本。管理员不必先自行编写 DNS 服务器才能创建一个域。他可以通过启动文件加载区域数据，让服务器回答本地查询；遇到不属于本域的名称时，再向其他服务器查询。管理员仍须维护准确记录，确保与父域的委派一致，并谨慎处理更新。BIND 提供的是可运行工具，不是正确性保证。

两年后的 RFC 1118给出了更具体的同期描述。Ed Krol 写道，BIND 集成在 4.3BSD 中，用于查询和保存主机名、地址、邮件代理等资料，并取代了基于 /etc/hosts 的名称查询。他以伊利诺伊大学厄巴纳－香槟分校为例说明规模变化：SRI 分发的主机表只列出少数机器，大学域名的大多数记录则由本地 BIND 表保存。其他运行 BIND 或任何 DNS 解析器的主机仍能查询这些名称。

这并不是在“单一数据库”和“完全无协调”之间二选一。SRI 仍然分发主机表；DNS 增加了另一种办法，使机构能维护更大的本地域名空间，并按照共同的查询规则对外提供解析。RFC 1118 还指出，BIND 能提供邮件路由信息，让无法直接通过 IP 到达的内部主机也能参与邮件传递，其中包括通过 UUCP 接入的机器。主机的物理位置或网络位置改变后，服务名称仍可保持稳定。

哪些权力转到本地，哪些规则仍须共享

实际边界比“分布式”一词通常带出的联想更具体。伯克利及后来的维护者负责分发软件；协议文档描述共同的行为；各域管理员控制名称树中属于自己的记录；解析器和服务器执行查询。任何一部分都不能取代其余部分。本地区域数据过时，服务器仍可能给出一致却错误的答案；委派不一致时，即使 BIND 正常运行，名称也可能无法解析。

Heng Lu 后来强调运行代码优先，这里可以作为一个分析问题，而不是对 BIND 作者意图的历史断言：管理员实际拿到了什么，又做了什么？现有材料显示，系统从设计报告开始，在实际运行中不断修订，随后随 4.3BSD 分发，最终由各地操作人员维护本地名称。规范的发布很重要，但它无法自动填充一所大学的区域数据，也不会替用户答复查询。

证据本身也有边界。RFC 1033 证明 BIND 随 4.3BSD 分发，RFC 1118 记录了集成情况和一所大学的案例。它们不能证明所有系统都安装了 BIND、DNS 只因 BIND 才被采用，或所有主机文件都消失了。可以稳妥得出的结论更具体：BIND 帮助 DNS 成为管理员能实际运行的 Unix 服务。各域因此可以维护自己的名称，同时继续与整棵名称树互通。

Sources