Skip to main content

2. Introduction (简介)

本RFC介绍了域名风格的名称 (domain style names)、它们在互联网邮件和主机地址支持中的使用，以及用于实现域名设施的协议和服务器。

2.1. The history of domain names (域名的历史)​

域名系统开发的推动力是互联网的增长：

早期HOSTS.TXT系统的问题​

1. 扩展性问题 (Scalability Issues)​

主机名到地址的映射由网络信息中心 (Network Information Center, NIC) 在单个文件 (HOSTS.TXT) 中维护，所有主机通过FTP获取该文件 [RFC-952, RFC-953]。

问题:

  • 分发新版本所消耗的总网络带宽与网络中主机数量的平方成正比
  • 即使使用多级FTP，NIC主机上的出站FTP负载也相当大
  • 主机数量的爆炸性增长对未来不利

数学模型:

N个主机 → N次下载 × 文件大小 = O(N²) 带宽消耗

示例:
100个主机: 10,000次传输操作
1,000个主机: 1,000,000次传输操作
10,000个主机: 100,000,000次传输操作

2. 管理集中化问题 (Centralized Administration)​

网络人口的特征也在发生变化：

  • 构成原始ARPANET的分时主机被工作站的局域网取代
  • 本地组织管理自己的名称和地址
  • 但必须等待NIC更改HOSTS.TXT才能使更改对整个互联网可见
  • 组织还希望在名称空间上有一些本地结构

问题总结:

  • ❌ 单点故障
  • ❌ 更新延迟
  • ❌ 缺乏层次结构
  • ❌ 无法授权管理

3. 功能限制 (Functional Limitations)​

互联网上的应用程序变得越来越复杂，需要通用的名称服务。

DNS的诞生​

结果是关于名称空间及其管理的几个想法 [IEN-116, RFC-799, RFC-819, RFC-830]。

共同特点:

  • 分层名称空间 (hierarchical name space) 的概念
  • 层次结构大致对应于组织结构
  • 使用.作为标记层次边界的字符

演进过程:

1983: 提出分层DNS概念
  ↓
1984: RFC 882/883 - 初始设计
  ↓
1987: RFC 1034/1035 - 标准化DNS
  ↓
持续演进: DNSSEC, EDNS0等扩展

在 [RFC-882, RFC-883] 中描述了使用分布式数据库和通用资源的设计。基于几个实现的经验，系统演变成本备忘录中描述的方案。

术语澄清​

术语"域" (domain) 或"域名" (domain name) 在DNS之外的许多上下文中使用。通常，术语域名用于指代具有由点指示的结构的名称，但与DNS无关。这在邮件寻址中尤其如此 [Quarterman 86]。

2.2. DNS design goals (DNS设计目标)​

DNS的设计目标影响其结构。

目标1: 一致的名称空间 (Consistent Name Space)​

主要目标是一个一致的名称空间，用于引用资源。

要求:

  • 为避免临时编码引起的问题
  • 名称不应要求包含网络标识符、地址、路由或类似信息作为名称的一部分
  • 名称应该是人类可读和记忆的

反例 (不好的设计):

❌ host-192-168-1-1.network.com  (包含IP地址)
❌ router-path-a-b-c.network.com (包含路由信息)
✅ www.example.com               (清晰的语义名称)

目标2: 分布式维护 (Distributed Maintenance)​

数据库的庞大规模和更新频率表明必须以分布式方式维护，并通过本地缓存提高性能。

原则:

  • 尝试收集整个数据库的一致副本将变得越来越昂贵和困难，因此应该避免
  • 相同的原则适用于名称空间的结构，特别是创建和删除名称的机制；这些也应该是分布式的

分布式设计:

集中式 (HOSTS.TXT)          分布式 (DNS)
      [NIC]                    [根服务器]
       |                      /     |     \
   所有主机               [.com] [.org] [.net]
                           /  |    |  \
                         更多层次结构...

目标3: 数据源控制权衡 (Data Source Controls Tradeoffs)​

在获取数据的成本、更新速度和缓存准确性之间存在权衡的地方，数据源应该控制权衡。

实现机制:

  • TTL (Time To Live) 值由权威服务器设置
  • 数据所有者决定缓存策略
  • 灵活性：从几秒到几天

示例:

; 静态数据 - 长TTL
www  3600  IN  A  93.184.216.34  ; 1小时

; 动态数据 - 短TTL  
api  60    IN  A  93.184.216.35  ; 1分钟

目标4: 通用性 (General Usefulness)​

实施此类设施的成本要求它是通用有用的，而不限于单个应用程序。

多用途支持:

  • 主机地址 (A, AAAA记录)
  • 邮箱数据 (MX记录)
  • 其他尚未确定的信息 (TXT, SRV等)

类型标记:

  • 与名称关联的所有数据都用类型标记
  • 查询可以限制为单一类型
  • 可扩展性：可以定义新类型

目标5: 协议族独立性 (Protocol Family Independence)​

因为我们希望名称空间在不同的网络和应用程序中有用，所以我们提供了使用相同名称空间与不同协议族或管理的能力。

类和类型系统:

  • DNS用类 (class) 和类型 (type) 标记所有数据
  • 允许并行使用不同格式的数据

示例:

类 (Class):
- IN (Internet) - 互联网
- CH (Chaos) - Chaos网络
- HS (Hesiod) - Hesiod系统

类型 (Type):
- A - IPv4地址
- AAAA - IPv6地址
- 可以为不同协议定义不同格式

目标6: 传输独立性 (Transport Independence)​

我们希望名称服务器事务独立于承载它们的通信系统。

灵活性:

  • 一些系统可能希望对查询和响应使用数据报 (UDP)
  • 仅对需要可靠性的事务 (例如，数据库更新、长事务) 建立虚拟电路 (TCP)
  • 其他系统将专门使用虚拟电路

实际实现:

UDP (默认):
- 快速查询/响应
- 512字节限制 (传统)
- 适合大多数查询

TCP (备用):
- 区域传输 (AXFR, IXFR)
- 响应 > 512字节
- 需要可靠性的场景

目标7: 广泛的主机能力 (Wide Host Capability Spectrum)​

系统应该跨广泛的主机能力范围有用。

适应性:

  • 个人计算机和大型分时主机都应该能够使用系统
  • 可能以不同的方式使用

实现级别:

最小实现:
- 存根解析器 (Stub Resolver)
- 依赖递归服务器

标准实现:
- 完整解析器
- 本地缓存

高级实现:
- 权威名称服务器
- 区域管理
- 主/从同步

2.3. Assumptions about usage (使用假设)​

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

假设1: 数据库大小增长模式​

总数据库的大小最初将与使用系统的主机数量成正比，但最终将增长到与这些主机上的用户数量成正比，因为邮箱和其他信息被添加到域名系统中。

增长阶段:

阶段1: 主机记录为主
- 每个主机1-2条记录
- O(hosts)

阶段2: 用户记录增加
- 每个用户可能多条记录
- O(users) >> O(hosts)

阶段3: 物联网时代
- 每个设备可能有记录
- O(devices) >>> O(users)

假设2: 数据变化速率​

系统中的大多数数据将变化非常缓慢 (例如，邮箱绑定、主机地址)，但系统应该能够处理变化更快的子集 (以秒或分钟为单位)。

数据类别:

类别变化频率TTL建议示例
静态很少数天NS记录
半静态偶尔数小时A记录
动态频繁数分钟负载均衡记录
实时持续秒级CDN边缘节点

假设3: 管理边界对应组织​

用于分配数据库责任的管理边界通常对应于拥有一个或多个主机的组织。

责任分配:

  • 每个负责特定域集的组织将提供冗余名称服务器
  • 可以在组织自己的主机上
  • 或组织安排使用的其他主机上

示例架构:

example.com (组织A负责)
├── ns1.example.com (主服务器)
└── ns2.example.com (从服务器)

或使用托管服务:
├── ns1.provider.net (托管)
└── ns2.provider.net (托管)

假设4: 可信名称服务器​

域名系统的客户端应该能够识别他们更喜欢使用的可信名称服务器，然后再接受对此"可信"集之外的名称服务器的引用。

安全考虑:

  • 本地配置首选DNS服务器
  • DNSSEC验证
  • 避免DNS劫持

假设5: 可用性优先于一致性 (Availability > Consistency)​

访问信息比即时更新或一致性保证更重要。

最终一致性模型:

  • 更新过程允许更新通过域名系统的用户渗透出去
  • 而不是保证所有副本同时更新
  • 当由于网络或主机故障而无法更新时，通常做法是相信旧信息，同时继续努力更新它

分发模型:

主服务器
   ↓ (设置TTL)
副本1 (负责刷新)
副本2 (负责刷新)
副本3 (负责刷新)

特殊情况:
- 非常短的间隔
- 禁止副本 (TTL=0)

假设6: 递归 vs 迭代查询​

在任何具有分布式数据库的系统中，特定名称服务器可能会被呈现只能由其他服务器回答的查询。

两种方法:

递归 (Recursive)​

第一个服务器代表客户端在另一个服务器上追踪查询。

客户端 → DNS1 → DNS2 → DNS3 → 答案
           ← ← ← ← ← ← ← ← ← ← ← 
客户端 ← DNS1 (返回最终答案)

优点:

  • 客户端简单
  • 减少客户端网络流量

缺点:

  • 服务器负载高
  • 可能被DDoS利用

迭代 (Iterative)​

服务器将客户端引用到另一个服务器，让客户端追踪查询。

客户端 → DNS1 → 引用到DNS2
客户端 → DNS2 → 引用到DNS3
客户端 → DNS3 → 最终答案

优点:

  • 服务器负载低
  • 更好的故障隔离

缺点:

  • 客户端更复杂
  • 更多网络往返

DNS要求:

  • ✅ 必须实现迭代方法
  • ✅ 允许递归方法作为选项
  • ⭐ 迭代方法对数据报风格的访问更优

2.4. Elements of the DNS (DNS的元素)​

DNS有三个主要组件：

组件1: 域名空间和资源记录 (DOMAIN NAME SPACE and RESOURCE RECORDS)​

树形结构名称空间和与名称关联的数据的规范。

概念:

  • 域名空间树的每个节点和叶命名一组信息
  • 查询操作是从特定集合中提取特定类型信息的尝试
  • 查询命名感兴趣的域名并描述所需的资源信息类型

示例:

查询: www.example.com 的 A 记录
→ 提取该节点的地址资源信息
→ 返回互联网主机地址

组件2: 名称服务器 (NAME SERVERS)​

服务器程序，保存有关域树结构和集合信息的信息。

特征:

  • 可以缓存关于域树任何部分的结构或集合信息
  • 通常，特定名称服务器拥有关于域空间子集的完整信息
  • 有指向其他名称服务器的指针，可用于从域树的任何部分获取信息

权威性 (AUTHORITY):

  • 名称服务器知道它拥有完整信息的域树部分
  • 对这些名称空间部分，名称服务器被称为权威 (AUTHORITY)
  • 权威信息组织成称为区域 (ZONES) 的单元
  • 这些区域可以自动分发到为区域中的数据提供冗余服务的名称服务器

区域架构:

example.com 区域
├── SOA记录 (权威起始)
├── NS记录 (名称服务器)
├── 主机记录 (www, mail等)
└── 子域委派 (sub.example.com)

组件3: 解析器 (RESOLVERS)​

程序，响应客户端请求从名称服务器提取信息。

要求:

  • 必须能够访问至少一个名称服务器
  • 使用该名称服务器的信息直接回答查询
  • 或使用对其他名称服务器的引用来追踪查询

实现形式:

  • 通常是系统例程，可直接被用户程序访问
  • 因此解析器和用户程序之间不需要协议

解析器类型:

存根解析器 (Stub Resolver):
- 最小实现
- 依赖递归服务器
- 常见于客户端

完整解析器 (Full Resolver):
- 可以执行迭代查询
- 本地缓存管理
- 常见于DNS服务器

DNS的三层视图​

视图1: 用户视角 (User's Point of View)​

从用户的角度来看：

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

用户体验:

# 简单的接口
import socket
ip = socket.gethostbyname('www.example.com')
# 用户不关心内部如何解析

视图2: 解析器视角 (Resolver's Point of View)​

从解析器的角度来看：

  • 域名系统由未知数量的名称服务器组成
  • 每个名称服务器都有整个域树数据的一个或多个部分
  • 解析器将每个数据库视为基本静态的

解析器职责:

  • 查询适当的名称服务器
  • 处理引用
  • 管理缓存
  • 处理超时和重试

视图3: 名称服务器视角 (Name Server's Point of View)​

从名称服务器的角度来看：

  • 域名系统由称为区域 (zones) 的独立本地信息集组成
  • 名称服务器具有某些区域的本地副本
  • 必须定期从本地文件或外部名称服务器中的主副本刷新其区域
  • 必须同时处理来自解析器的查询

名称服务器职责:

  • 加载区域数据
  • 响应查询
  • 区域传输 (AXFR/IXFR)
  • 维护缓存
  • 处理更新

功能耦合 (Function Coupling)​

为了性能考虑，实现可以耦合这些功能。

示例:

  • 与名称服务器在同一台机器上的解析器可能共享一个数据库
  • 数据库由名称服务器管理的区域和解析器管理的缓存组成

常见配置:

组合服务器:
- 权威名称服务器 (区域数据)
+ 递归解析器 (缓存数据)
= 完整DNS服务器 (BIND, Unbound等)

系统管理员和域名系统的职责​

系统管理员提供:​

  1. ✅ 区域边界的定义
  2. ✅ 数据的主文件
  3. ✅ 主文件的更新
  4. ✅ 所需刷新策略的声明

域名系统提供:​

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

协作关系:

管理员 → 创建/更新区域文件
   ↓
DNS系统 → 加载/分发/查询
   ↓
用户/应用 ← 获取信息

关键概念总结​

DNS解决的核心问题​

  1. ✅ 扩展性: 从O(N²)到O(log N)
  2. ✅ 分布式管理: 每个组织管理自己的域
  3. ✅ 高可用性: 冗余服务器，缓存机制
  4. ✅ 灵活性: 可扩展的类型和类系统
  5. ✅ 性能: 本地缓存，分层查询

DNS的设计权衡​

特性选择原因
一致性 vs 可用性可用性优先最终一致性模型
递归 vs 迭代两者都支持适应不同场景
集中 vs 分布分布式扩展性和容错
即时 vs 缓存缓存优先性能考虑

下一章: 3. Domain Name Space and Resource Records - 深入探讨域名空间结构和资源记录格式

Last updated on