摘要
- RFC 920 不只是列举顶级域名称;它还把类别、管理者、注册代理和准入条件连在一起。
- ARPA 被明确视为临时域名;GOV、EDU、COM、MIL、ORG 构成机构类别。国家代码和跨组织类别当时尚无已建立的域名。
- 顶级域通常要有超过 500 台主机才会获准;二级域超过 50 台只是“非常宽松”的建议,大型机构即使规模更小也可能符合条件。
名单背后是准入权
如果把早期域名空间看成一张名称菜单,容易忽略真正决定谁能出现在最上层的部分:谁能批准菜单上的新项。1984 年 10 月,Jon Postel 和 Joyce Reynolds 发布 RFC 920,将它定位为 Internet Activities Board 与 DARPA 就 ARPA-Internet 及 DARPA 研究社区建立域名所作的正式政策声明。它既讲名称树,也讲哪些类型的域可以建立、由谁管理、申请如何进入授权流程。
RFC 920 承接了更早的方案。RFC 881 讨论域名计划,RFC 882 和 RFC 883 描述域名系统的概念与实现。RFC 920 说明自己是在细化前述要求,并新增了一组有限的顶级域。名称解析的技术架构和顶级域的准入政策彼此相关,却不是同一类决定。
最初的名单由临时名称、机构类别和两类尚未建立的候选项组成:
| 名单中的位置 | 名称或类别 | RFC 920 在 1984 年的说明 |
|---|---|---|
| 临时 | ARPA | 当时 ARPA-Internet 的主机;明确标注为临时 |
| 机构类别 | GOV、EDU、COM、ORG | DARPA 管理,NIC 作为代理 |
| 军事类别 | MIL | DDN-PMO 管理,NIC 作为代理 |
| 国家 | 英文 ISO alpha-2 两字母代码 | 当时尚未建立任何国家域名 |
| 跨组织类别 | 尚无具体名称 | 当时尚未建立;大型国际组织若难以归入既有类别,可以考虑 |
这张表不是所有分支已经投入运行的清单。RFC 920 明确说,国家域名和跨组织域名都还没有建立。它也没有把管理责任平均分配:DARPA 管理 ARPA、GOV、EDU、COM、ORG,NIC 为代理;MIL 的管理者则是 DDN-PMO,NIC 同样担任代理与注册方。顶级域不能因为“名字听起来合理”就自动成立;还需要授权和注册。
主机数量也并非一道简单的硬门槛。顶级域必须特别授权,通常只会为预计拥有 500 台以上主机的域授权。二级域的建议是超过 50 台,但 RFC 920 将其称为“非常宽松”的要求,并举例说明,重要大学或公司即使只有少数主机也可能获准。文件还说,没有人仅仅因为超过这个数字就必须另建域名。规模只是考虑因素之一;域名管理者、稳定的名称服务,以及向上级注册同样重要。
“跨组织”例外说明,为何一张类别表仍需留下余地。一个规模较大、由多家组织组成、具有国际范围且难以归入某一类别的团体,可以申请成为顶级域。RFC 920 用虚构的 CSNET 联盟作例子:多所大学和工业实验室组成一个以邮件交换为中心的社区,使用不同协议与网络,但有共同的负责管理者。这里重要的不是 CSNET 的接入或成本历史,而是它说明了类别边界之外的组织如何进入政策视野。RFC 920 同时指出当时还没有这种顶级域建立,因此该假设例子不能证明 CSNET 曾取得这一地位。
注册权沿着树向下传递。二级域要向对应顶级域的管理者登记;更低层级则向紧邻的上级管理者或其负责人登记。上级必须确认适用要求得到满足,才会授予授权。管理者可以把部分工作交给子域负责人,但顶级域的负责人仍要对整个名称树承担责任。树不只组织名称,也组织故障由谁处理、向谁追责。
这份责任具有实际工作内容。域名需要一位明确的联系人,能协调域内问题,拥有足够技术能力和内部权力来修复故障;若某台主机影响域外通信,这个人还要接收报告并推动问题解决。名称服务也必须可靠。两台互相独立、分属不同机器和电源的服务器是一种降低共同故障的办法,但不是唯一办法;域之间合作或委托第三方也可以。RFC 920 关心的是管理员能否维持名称数据和服务,不是要求所有域采用同一种服务器部署。
ARPA 的临时性质最明确。RFC 920 解释说,这个顶级名称源自系统发展史,预计最终会停止使用。它建议当时属于 ARPA 域的主机安排加入其他域。没有参加新命名服务的 DDN 主机,可以继续使用 NIC 维护的 HOSTS.TXT 文件,虽然文件也预期它们以后改名。这些是 1984 年政策中的计划和建议,不是所有主机都已迁移、也不是 ARPA 在某个日期消失的证据。
三年后的 RFC 1032 展示了注册工作的后续形态。它介绍 NIC 管理根区并承担注册职责,也提到 CSNET 和 UUCP 的管理团队先行处理各自组织的申请,再把相关信息交给 NIC。它列出的顶级域状态已包括 NET 和一些国家域。那是 1987 年的快照,不能倒推成 RFC 920 在 1984 年的名单,更不能证明当时所有预计事项都按原文发生。
因此,RFC 920 的首批顶级域名单不只是几个熟悉的标签。它划分类别、指定管理者,为跨类别团体留下例外,并明确谁可以授权新增分支。名单虽短,准入流程已经决定了名称能否到达顶层。
来源
- RFC 920 — Domain Requirements
- RFC 881 — The Domain Names Plan and Schedule
- RFC 882 — Domain Names: Concepts and Facilities
- RFC 883 — Domain Names: Implementation and Specification
- RFC 1032 — Domain Administrators Guide
以下相邻文献仅用于限定本文范围;它们记载的后续状态不会被倒推到 1984 年。
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance

