跳到主要内容

2. 引言

本 RFC 介绍域名风格的名称, 其在互联网邮件和主机地址支持中的用途, 以及用于实现域名功能的协议和服务器.

2.1. 域名的历史​

Domain Name System (域名系统, DNS) 发展的动力来自互联网的增长:

  • 主机名到地址的映射 由 Network Information Center (网络信息中心, NIC) 在单个文件 (HOSTS.TXT) 中维护, 所有主机通过 FTP 获取该文件 [RFC-952, RFC-953]. 通过这种方式分发新版本所消耗的总网络带宽与网络中主机数量的平方成正比, 即使使用多级 FTP, NIC 主机上的出站 FTP 负载也相当可观. 主机数量的爆炸性增长对未来并不乐观.

  • 网络用户群体 的性质也在发生变化. 构成原始 ARPANET 的分时主机正在被工作站局域网所取代. 本地组织自行管理其名称和地址, 但必须等待 NIC 修改 HOSTS.TXT 才能使更改对整个互联网可见. 各组织还希望在名称空间上有一些本地结构.

  • 互联网上的应用程序 变得越来越复杂, 产生了对通用名称服务的需求.

结果是出现了若干关于名称空间及其管理的想法 [IEN-116, RFC-799, RFC-819, RFC-830]. 各提案不尽相同, 但共同点是层次化名称空间的理念, 层次结构大致对应于组织结构, 名称使用 "." 作为标记层次级别边界的字符. [RFC-882, RFC-883] 描述了一种使用分布式数据库和通用资源的设计. 基于多个实现的经验, 该系统演变为本备忘录中描述的方案.

"domain (域)" 或 "domain name (域名)" 这两个术语在 DNS 之外的许多场景中也被使用. 很多时候, 域名一词用于指代带有点号结构的名称, 但与 DNS 无关. 这在邮件地址中尤为常见 [Quarterman 86].

2.2. DNS 设计目标​

DNS 的设计目标影响其结构. 这些目标是:

  • 一致的名称空间: 首要目标是建立一个用于引用资源的一致名称空间. 为避免临时编码带来的问题, 名称不应要求包含网络标识符、地址、路由或类似信息.

  • 分布式维护: 数据库的庞大规模和更新频率表明它必须以分布式方式维护, 并通过本地缓存来提高性能. 试图收集整个数据库一致副本的方法将变得越来越昂贵和困难, 因此应避免. 同样的原则适用于名称空间的结构, 特别是创建和删除名称的机制, 这些也应该是分布式的.

  • 权衡的源头控制: 在获取数据的成本、更新速度和缓存准确性之间存在权衡时, 数据的来源方应控制这种权衡.

  • 通用性: 实现此类功能的成本要求它具有通用性, 而不局限于单一应用. 我们应该能够使用名称来检索主机地址、邮箱数据以及其他尚未确定的信息. 与名称关联的所有数据都带有类型标签, 查询可以限定为单一类型.

  • 协议独立性: 由于我们希望名称空间在不同网络和应用中都能使用, 我们提供了在不同协议族或管理方式下使用相同名称空间的能力. 例如, 主机地址格式因协议而异, 但所有协议都有地址的概念. DNS 为所有数据标记类别 (class) 和类型 (type), 以便允许对地址类型数据使用不同格式的并行使用.

  • 传输独立性: 我们希望名称服务器事务独立于承载它们的通信系统. 某些系统可能希望对查询和响应使用数据报, 仅对需要可靠性的事务 (如数据库更新、长事务) 建立虚电路; 其他系统将专门使用虚电路.

  • 广泛的主机能力范围: 该系统应在广泛的主机能力范围内可用. 个人计算机和大型分时主机都应能使用该系统, 尽管方式可能不同.

2.3. 使用假设​

域名系统的组织源于对其用户社区需求和使用模式的一些假设, 旨在避免通用数据库系统中发现的许多复杂问题.

这些假设是:

  • 数据库规模: 系统总数据库的大小最初将与使用该系统的主机数量成正比, 但随着邮箱和其他信息被添加到域名系统, 最终将增长到与这些主机上的用户数量成正比.

  • 更新频率: 系统中的大多数数据变化非常缓慢 (如邮箱绑定、主机地址), 但系统应能处理变化更快的子集 (以秒或分钟为单位).

  • 管理边界: 用于分配数据库责任的管理边界通常对应于拥有一台或多台主机的组织. 每个负责特定域集合的组织将提供冗余名称服务器, 可以在组织自己的主机上, 也可以在组织安排使用的其他主机上.

  • 可信服务器: 域名系统的客户端应能够在接受此 "可信" 集合之外的名称服务器的引用之前, 识别其首选的可信名称服务器.

  • 可用性与一致性: 访问信息比即时更新或一致性保证更为关键. 因此, 更新过程允许更新通过域名系统的用户逐步传播, 而不是保证所有副本同时更新. 当由于网络或主机故障导致更新不可用时, 通常的做法是相信旧信息, 同时继续努力更新. 一般模型是副本以带有刷新超时的方式分发. 分发者设置超时值, 分发的接收者负责执行刷新. 在特殊情况下, 可以指定非常短的间隔, 或者所有者可以禁止复制.

  • 查询解析方法: 在任何具有分布式数据库的系统中, 特定名称服务器可能会收到只有其他服务器才能回答的查询. 处理此问题的两种通用方法是 "递归 (recursive)" (第一个服务器在另一个服务器上代表客户端追踪查询) 和 "迭代 (iterative)" (服务器将客户端引用到另一个服务器, 让客户端自行追踪查询). 两种方法各有优缺点, 但迭代方法更适合数据报访问方式. 域名系统要求实现迭代方法, 但允许将递归方法作为选项.

数据来源与管理​

域名系统假设所有数据源自分散在使用域名系统的主机上的主文件 (master files). 这些主文件由本地系统管理员更新. 主文件是文本文件, 由本地名称服务器读取, 从而通过名称服务器向域名系统的用户提供. 用户程序通过称为解析器 (resolvers) 的标准程序访问名称服务器.

主文件的标准格式允许它们在主机之间交换 (通过 FTP、邮件或其他机制); 当一个组织想要一个域但不想支持名称服务器时, 此功能非常有用. 该组织可以使用文本编辑器在本地维护主文件, 将其传输到运行名称服务器的外部主机, 然后与名称服务器的系统管理员协商加载这些文件.

每台主机的名称服务器和解析器由本地系统管理员配置 [RFC-1033]. 对于名称服务器, 此配置数据包括本地主文件的标识以及关于从外部服务器加载哪些非本地主文件的指令. 名称服务器使用主文件或副本来加载其区域 (zones). 对于解析器, 配置数据标识应作为主要信息来源的名称服务器.

域名系统定义了访问数据和引用到其他名称服务器的程序. 域名系统还定义了缓存检索数据以及定期刷新系统管理员定义的数据的程序.

职责划分​

系统管理员提供:

  • 区域边界的定义.
  • 数据的主文件.
  • 主文件的更新.
  • 所需刷新策略的声明.

域名系统提供:

  • 资源数据的标准格式.
  • 查询数据库的标准方法.
  • 名称服务器从外部名称服务器刷新本地数据的标准方法.

2.4. DNS 的组成要素​

DNS 有三个主要组成部分:

域名空间和资源记录​

DOMAIN NAME SPACE (域名空间) 和 RESOURCE RECORDS (资源记录) 是树状名称空间及与名称关联的数据的规范. 从概念上讲, 域名空间树的每个节点和叶子都命名一组信息, 查询操作是尝试从特定集合中提取特定类型的信息. 查询指定感兴趣的域名并描述所需的资源信息类型. 例如, 互联网使用其部分域名来标识主机; 对地址资源的查询返回互联网主机地址.

名称服务器​

NAME SERVERS (名称服务器) 是保存有关域树结构和集合信息的服务器程序. 名称服务器可以缓存域树任何部分的结构或集合信息, 但通常特定名称服务器拥有域空间某个子集的完整信息, 以及指向其他名称服务器的指针, 这些指针可用于引导到域树任何部分的信息. 名称服务器知道它们拥有完整信息的域树部分; 名称服务器被称为这些名称空间部分的 AUTHORITY (权威). 权威信息被组织成称为 ZONEs (区域) 的单元, 这些区域可以自动分发到为区域中的数据提供冗余服务的名称服务器.

解析器​

RESOLVERS (解析器) 是响应客户端请求从名称服务器提取信息的程序. 解析器必须能够访问至少一个名称服务器, 并使用该名称服务器的信息直接回答查询, 或通过引用到其他名称服务器来追踪查询. 解析器通常是用户程序可以直接访问的系统例程; 因此解析器和用户程序之间不需要协议.

域名系统的三个视角​

这三个组成部分大致对应于域名系统的三个层次或视角:

  • 从用户的角度来看, 域名系统通过对本地解析器的简单过程或操作系统调用来访问. 域名空间由单个树组成, 用户可以从树的任何部分请求信息.

  • 从解析器的角度来看, 域名系统由未知数量的名称服务器组成. 每个名称服务器拥有整个域树数据的一个或多个片段, 但解析器将这些数据库中的每一个视为基本上是静态的.

  • 从名称服务器的角度来看, 域名系统由称为区域的独立本地信息集合组成. 名称服务器拥有某些区域的本地副本. 名称服务器必须定期从本地文件或外部名称服务器中的主副本刷新其区域. 名称服务器必须并发处理来自解析器的查询.

为了性能考虑, 实现可以将这些功能耦合在一起. 例如, 与名称服务器在同一台机器上的解析器可能共享一个数据库, 该数据库由名称服务器管理的区域和解析器管理的缓存组成.

最后于 更新