域名系统技术指南
本指南是对 RFC 1034 和 RFC 1035 所述域名系统（DNS）的理论与技术规范的补充。它从实践角度出发，讲解协议各组成部分如何协同工作，以及实现者在构建名称服务器、解析器及区域文件时应遵循的约定。
1. 概述
域名系统是一种分布式数据库，用于将域名（人类可读名称）映射到资源记录（RR），例如 IP 地址、邮件交换器、名称服务器等。其核心设计目标包括：
- 分布式：没有单一的中心节点保存全部数据，数据分布在世界各地的名称服务器上。
- 层次化：域名空间被组织为树状结构，每一层由不同的机构管理。
- 缓存：响应可被缓存，以减轻上游服务器负载并提升解析速度。
- 健壮性：即便部分服务器不可用，系统整体仍应可用。
DNS 通过两种主要角色运作：
- 名称服务器（Name Server）：存储一个或多个区域（zone）的数据，并响应查询。
- 解析器（Resolver）：代表应用程序向名称服务器发起查询，并将结果返回给应用程序。
2. 域名空间
域名空间是一个从根（.）开始的树。每个节点都有一个标签，完整域名是从节点到根的标签序列，以点分隔。
例如：www.example.com. 由标签 www、example、com 和根标签（空）组成。
2.1 域名规范
- 域名不区分大小写（比较时应视为小写）。
- 标签长度上限为 63 个八位组，完整域名（含分隔点）上限为 255 个八位组。
- 域名中的字符建议使用字母（A–Z）、数字（0–9）和连字符（
-）。
2.2 区域与委派
一个**区域（zone）是域名空间中由单个管理机构负责管理的连续部分。区域的边界由委派（delegation）**决定：父区域中的 NS 记录指向子区域的名称服务器，从而将子树的权威职责移交出去。
3. 资源记录（RR）
DNS 数据以资源记录为单位存储。每条 RR 具有相同的顶层格式：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3.1 常用 RR 类型
| TYPE | 值 | 含义 |
|---|---|---|
| A | 1 | 主机地址（IPv4） |
| NS | 2 | 权威名称服务器 |
| CNAME | 5 | 别名的规范名称 |
| SOA | 6 | 授权区域起点 |
| PTR | 12 | 域名指针（常用于反向查询） |
| MX | 15 | 邮件交换器 |
| TXT | 16 | 文本字符串 |
3.2 关于 CNAME 的注意事项
若某节点存在 CNAME RR，则不应在该节点上存放其他数据。CNAME 将别名指向规范名称；解析器在解析别名时，应跟随 CNAME 找到规范名称，再对规范名称查询实际数据（如 A 记录）。
4. 消息格式
DNS 消息由以下部分组成：
- 头部（Header）：包含 ID、标志位、问题数、回答数等计数。
- 问题段（Question）：包含待查询的 QNAME、QTYPE、QCLASS。
- 回答段（Answer）：包含针对问题的 RR。
- 授权段（Authority）：包含指向权威名称服务器的 RR。
- 附加段（Additional）：包含解析器可能有用的额外 RR。
4.1 压缩
DNS 消息中的域名可通过指针（指向消息中此前出现的域名）进行压缩，以节省空间。压缩仅可用于格式已知的域名出现位置（如 NAME 字段、已知 RR 类型的 RDATA 中的域名）。
5. 传输
5.1 UDP
UDP 是 DNS 查询和响应的默认传输。通过 UDP 发送的 DNS 消息不应超过 512 个八位组；若响应超出该限制，应设置 TC（截断）位，客户端应改用 TCP 重试。
5.2 TCP
TCP 用于区域传送以及 UDP 响应被截断后的重试。通过 TCP 传输时，每条 DNS 消息前带有一个 16 位长度字段，指定后续消息的字节数（不包含长度字段本身）。
6. 名称服务器实现
名称服务器可以是：
- 主（Primary/Master）服务器：从区域文件（master file）加载数据。
- 从（Secondary/Slave）服务器：通过区域传送从主服务器获取数据。
6.1 区域传送
从服务器定期向主服务器查询 SOA 记录的 SERIAL 字段；若发现主服务器序列号更大，则发起区域传送（AXFR）以获取完整区域数据。
6.2 响应算法
名称服务器收到查询后：
- 在区域中搜索匹配 QNAME 的节点。
- 若找到且为本服务器权威，则返回 authoritative 回答。
- 若未找到但存在委派点，则返回指向子区域名称服务器的 NS 记录（可能在授权段）。
- 若查询设置了 RD（期望递归）位且服务器支持递归，则作为解析器处理查询。
7. 解析器实现
解析器负责将应用程序的请求转换为 DNS 查询并获取答案。典型流程：
- 向本地配置的一个或多个名称服务器发送查询（通常设 RD=1）。
- 若响应包含完整答案，则返回给应用程序。
- 若响应指向其他名称服务器（如根服务器、TLD 服务器），则解析器需自行向其发起后续查询（迭代解析），直至获得答案。
7.1 缓存
解析器应缓存响应中的 RR，并遵循其 TTL 值。缓存项过期后不应再使用。
7.2 错误处理
- 若查询超时，应尝试备用名称服务器。
- 若收到 SERVFAIL 或 NXDOMAIN，应如实返回相应状态。
8. 主文件（区域文件）格式
主文件使用文本格式描述区域内容，每行通常包含一个 RR，语法为：
<owner> <TTL> <CLASS> <TYPE> <RDATA>
其中 owner 与 TTL 可省略（从上一行继承）。常见约定：
$ORIGIN指令设置相对名称的基准域。$TTL指令设置默认 TTL。@表示当前$ORIGIN。
示例：
$ORIGIN example.com.
@ IN SOA ns1.example.com. admin.example.com. (
2024010101 ; 序列号
7200 ; 刷新
3600 ; 重试
1209600 ; 过期
3600 ) ; 最小 TTL
@ IN NS ns1.example.com.
www IN A 93.184.216.34
mail IN MX 10 mail.example.com.
9. 反向查询与 IN-ADDR.ARPA
为将 IP 地址映射回域名，定义了特殊域 IN-ADDR.ARPA。IPv4 地址以反向点分十进制形式表示，并附加后缀。例如：
123.0.0.10.IN-ADDR.ARPA
对应网络 10 上地址 10.0.0.123 的主机。反向查询通过 PTR 记录实现。
注意：RFC 1035 中描述的可选"完成（completion）"服务已被删除，重新设计的服务可能在将来可用。
10. 实现建议小结
- 始终正确设置并尊重 TTL，避免缓存污染。
- 对区域传送使用 TCP，对普通查询优先使用 UDP。
- 实施解析器缓存与超时重试，提升可靠性。
- 在区域文件中保持 SOA 序列号单调递增，确保从服务器能正确检测更新。
- 若需扩展 DNS，应通过定义新类型并在软件中实现来支持，并保持向后兼容。
相关文档：