3. Domain Name Space and Resource Records (域名空间和资源记录)
本章描述DNS的核心数据结构：域名空间的树形结构和资源记录格式。
3.1. Name space specifications and terminology (名称空间规范和术语)
树形结构 (Tree Structure)
域名空间是一个树形结构 (tree structure)。树上的每个节点和叶对应一个资源集 (可能为空)。
关键特点:
- 域名系统不区分内部节点和叶的使用
- 本备忘录使用术语"节点" (node) 来指代两者
标签 (Labels)
每个节点有一个标签 (label)，长度为0到63个八位字节。
规则:
- ✅ 兄弟节点不能有相同的标签
- ✅ 非兄弟节点可以使用相同的标签
- ⭐ 保留一个标签：空 (零长度) 标签用于根
示例:
. (根，空标签)
|
+---+---+
| |
com org (兄弟，标签不同)
| |
google google (非兄弟，标签可以相同)
域名 (Domain Names)
节点的域名是从节点到树根的路径上的标签列表。
约定:
- 从左到右打印或读取标签
- 从最具体 (最低，离根最远) 到最不具体 (最高，最接近根)
示例:
www.example.com.
│ │ │ └─ 根 (.)
│ │ └───── com
│ └─────────── example
└───────────── www
读取顺序: www → example → com → (根)
内部表示 (Internal Representation)
在内部，操作域名的程序应将它们表示为标签序列：
- 每个标签是一个长度八位字节，后跟一个八位字节字符串
- 因为所有域名都在根结束，根有一个空字符串作为标签
- 这些内部表示可以使用零长度字节来终止域名
编码格式:
www.example.com 的内部表示:
[3]www[7]example[3]com[0]
│ │ │ │ │ └─ 根终止符
│ │ │ │ └───── "com"
│ │ │ └───────── "com"的长度
│ │ └─────────────── "example"
│ └─────────────────── "example"的长度
└────────────────────── "www"的长度
十六进制:
03 77 77 77 07 65 78 61 6D 70 6C 65 03 63 6F 6D 00
大小写不敏感 (Case Insensitivity)
约定:
- 域名可以用任意大小写存储
- 所有域名比较都以大小写不敏感方式进行
- 假设ASCII字符集和高位零位
规则:
- ✅ 可以创建标签"A"或标签"a"的节点
- ❌ 不能两者都作为兄弟
- ✅ 可以使用"a"或"A"引用任一个
- ⭐ 收到域名或标签时，应保留其大小写
理由:
- 将来可能需要为新服务添加完整的二进制域名
- 现有服务不会改变
示例:
Example.COM = example.com = EXAMPLE.COM
www.Example.Com = WWW.EXAMPLE.COM
绝对 vs 相对名称 (Absolute vs Relative Names)
当用户需要键入域名时，省略每个标签的长度，标签用点 (.) 分隔。
绝对名称 (Absolute Names)
完整域名以根标签结束，导致打印形式以点结束。
特征:
- 以
.结尾 - 完全限定域名 (FQDN)
- 无歧义
示例:
poneria.ISI.EDU. (绝对)
www.example.com. (绝对)
相对名称 (Relative Names)
表示域名起始标签的字符串，不完整，应由本地软件使用本地域的知识完成。
特征:
- 不以
.结尾 - 需要上下文解释
- 常见于用户界面和主文件
示例:
poneria (相对于ISI.EDU域)
→ 解析为 poneria.ISI.EDU.
www (相对于example.com域)
→ 解析为 www.example.com.
解释方式:
- 相对于已知原点
- 相对于用作搜索列表的域列表
- 最常见的解释使用根
.作为单一原点或搜索列表成员之一
长度限制 (Length Limits)
为简化实现，表示域名的八位字节总数 (即，所有标签八位字节和标签长度的总和) 限制为255。
组成:
最大域名长度: 255字节
= 标签长度字节 + 标签内容 + ... + 根终止符
示例:
www.example.com.
= 1 + 3 + 1 + 7 + 1 + 3 + 1 = 17字节
域和子域 (Domains and Subdomains)
域 (domain):
- 由域名标识
- 由位于或低于指定域的域名的域名空间部分组成
子域 (subdomain):
- 如果一个域包含在另一个域中，则它是该域的子域
- 可以通过查看子域的名称是否以包含域的名称结尾来测试此关系
示例:
A.B.C.D 是以下的子域:
- B.C.D
- C.D
- D
- "" (根)
测试方法:
A.B.C.D 以 B.C.D 结尾? ✅
A.B.C.D 以 C.D 结尾? ✅
A.B.C.D 以 D 结尾? ✅
3.2. Administrative guidelines on use (使用的管理指南)
设计哲学
作为政策问题，DNS技术规范不强制特定的树结构或选择标签的规则。
目标:
- 尽可能通用
- 可用于构建任意应用程序
- 名称空间不必沿着网络边界、名称服务器等组织
理由:
- 不是说名称空间应该没有隐含的语义
- 而是隐含语义的选择应该保持开放，用于手头的问题
- 树的不同部分可以有不同的隐含语义
特殊域示例
IN-ADDR.ARPA域
组织方式: 按网络和主机地址组织和分发
原因: 其角色是从网络或主机号码转换为名称
结构:
IN-ADDR.ARPA
|
1
|
168
|
192
|
1 → 1.168.192.IN-ADDR.ARPA (反向DNS for 192.168.1.1)
NetBIOS域
组织方式: 平面 (flat)
原因: 适合该应用程序 [RFC-1001, RFC-1002]
一般指南
适用于用于主机、邮箱等的名称空间"正常"部分的一些指南：
目标:
- ✅ 使名称空间更统一
- ✅ 提供增长空间
- ✅ 最小化从旧主机表转换软件时的问题
政策参考:
- 树顶层的政治决策源于RFC-920
- 当前顶层政策在 [RFC-1032] 中讨论
- MILNET转换问题在 [RFC-1031] 中涵盖
设计建议
区域划分:
- 最终将分解为多个区域的较低域应在域顶部提供分支
- 以便最终分解可以在不重命名的情况下完成
标签选择:
- 使用特殊字符、前导数字等的节点标签可能会破坏依赖于更严格选择的旧软件
- 应避免
3.3. Technical guidelines on use (使用的技术指南)
在DNS可用于保存某种对象的命名信息之前，必须满足两个需求：
需求1: 对象名称和域名之间的映射约定
描述如何访问有关对象的信息。
主机映射
现有语法: 主机名是域名通常文本表示的子集
需要:
- 描述主机地址等的RR格式
- 从地址到主机名的可靠反向映射
- IN-ADDR.ARPA域的特殊地址映射
示例:
正向: www.example.com → 93.184.216.34
反向: 34.216.184.93.IN-ADDR.ARPA → www.example.com
邮箱映射
映射规则: <local-part>@<mail-domain> 映射到域名
步骤:
- 将
<local-part>转换为单个标签 (无论它包含多少点) - 使用域名的通常文本格式将
<mail-domain>转换为域名 (点表示标签中断) - 连接两者形成单个域名
示例:
邮箱: [email protected]
域名表示: HOSTMASTER.SRI-NIC.ARPA.
邮箱: [email protected]
域名表示: user\.name.example.com.
(注意: local-part中的点需要转义)
配合: 必须考虑邮件交换方案 [RFC-974]
需求2: 描述对象的RR类型和数据格式
定义资源记录的类型和格式。
设计考虑:
- 现有格式
- 向上兼容性
- 可能需要多个映射或映射级别
3.4. Example name space (示例名称空间)
以下图显示了当前域名空间的一部分，在本RFC的许多示例中使用。
|
|
+-------------------+------------------+
| | |
MIL EDU ARPA
| | |
| | |
+-----+-----+ | +------+-----+-----+
| | | | | | |
BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
|
+--------+----------------+---------------+--------+
| | | | |
UCI MIT | UDEL YALE
| ISI
| |
+---+---+ |
| | |
LCS ACHILLES +--+---+-----+--------+
| | | | | |
XX A C VAXA VENERA Mockapetris
说明:
- 根域有三个直接子域: MIL, EDU, ARPA
- LCS.MIT.EDU域有一个名为XX.LCS.MIT.EDU的直接子域
- 所有叶也是域
注意: 这是实际名称空间的非常小的子集
3.5. Preferred name syntax (首选名称语法)
设计原则
DNS规范尝试在构造域名的规则中尽可能通用。
目标:
- 任何现有对象的名称都可以用最少的更改表示为域名
- 为对象分配域名时，谨慎的用户将选择同时满足域名系统规则和对象任何现有规则的名称
兼容性考虑
示例:
- 命名邮件域时，用户应满足本备忘录和RFC-822中的规则
- 创建新主机名时，应遵循HOSTS.TXT的旧规则
- 避免旧软件转换为使用域名时出现问题
推荐语法 (ABNF)
以下语法将导致使用域名的许多应用程序 (例如，邮件、TELNET) 出现更少的问题：
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= A-Z | a-z (52个字母)
<digit> ::= 0-9 (10个数字)
标签规则
ARPANET主机名规则:
- ✅ 必须以字母开头
- ✅ 必须以字母或数字结尾
- ✅ 内部字符只能是字母、数字和连字符
- ✅ 标签必须是63个字符或更少
大小写:
- 域名中允许大写和小写字母
- 大小写没有意义
- 相同拼写但不同大小写的两个名称应被视为相同
有效域名示例
A.ISI.EDU
XX.LCS.MIT.EDU
SRI-NIC.ARPA
www.example.com
mail-server-01.company.co.uk
无效域名示例
❌ -example.com (以连字符开头)
❌ example-.com (以连字符结尾)
❌ 123.com (纯数字标签，虽然技术上允许)
❌ example..com (连续的点)
❌ .example.com (以点开头，相对名称)
3.6. Resource Records (资源记录)
基本概念
域名标识一个节点。每个节点有一组资源信息，可能为空。
关键特点:
- 与特定名称关联的资源信息集由单独的资源记录 (RRs) 组成
- 集合中RR的顺序不重要
- 不需要由名称服务器、解析器或DNS的其他部分保留
RR结构
当我们谈论特定RR时，我们假设它具有以下内容：
owner (所有者)
RR所在的域名。
type (类型)
编码的16位值，指定此资源记录中资源的类型。
常见类型:
| 类型 | 值 | 说明 |
|---|---|---|
| A | 1 | 主机地址 (IPv4) |
| NS | 2 | 权威名称服务器 |
| CNAME | 5 | 规范名称的别名 |
| SOA | 6 | 授权起始 |
| PTR | 12 | 指向域名空间另一部分的指针 |
| HINFO | 13 | 主机使用的CPU和OS |
| MX | 15 | 域的邮件交换 [RFC-974] |
| TXT | 16 | 文本字符串 |
| AAAA | 28 | IPv6地址 (后来添加) |
class (类)
编码的16位值，标识协议族或协议实例。
常见类:
| 类 | 值 | 说明 |
|---|---|---|
| IN | 1 | 互联网 (Internet) |
| CS | 2 | CSNET (已废弃) |
| CH | 3 | CHAOS |
| HS | 4 | Hesiod |
注意: 实际上，IN类占主导地位。
TTL (Time To Live, 生存时间)
32位有符号整数，指定RR可以缓存的时间间隔，然后应丢弃或从权威源刷新。
单位: 秒
用途:
- 控制缓存行为
- 平衡新鲜度和性能
示例值:
300 - 5分钟 (动态数据)
3600 - 1小时 (常见默认值)
86400 - 1天 (静态数据)
604800 - 1周 (非常静态)
RDATA (Resource Data, 资源数据)
描述资源的数据。格式取决于RR的TYPE和CLASS。
示例:
A记录: 4字节IPv4地址
AAAA记录: 16字节IPv6地址
CNAME记录: 域名
MX记录: 优先级 + 域名
完整RR示例
; owner TTL class type rdata
www.example.com. 3600 IN A 93.184.216.34
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN NS ns1.example.com.
ftp.example.com. 3600 IN CNAME www.example.com.
3.6.1. Textual expression of RRs (RR的文本表达)
RR在主文件中以文本形式表示。
格式:
<owner> [<TTL>] [<class>] <type> <RDATA>
省略规则:
- TTL可以省略 (使用$TTL指令的默认值)
- class可以省略 (默认IN)
- owner可以省略 (使用上一条记录的owner)
示例:
$ORIGIN example.com.
$TTL 3600
@ IN SOA ns1.example.com. admin.example.com. (
2024010101 ; Serial
3600 ; Refresh
1800 ; Retry
604800 ; Expire
86400 ) ; Minimum TTL
IN NS ns1.example.com.
IN NS ns2.example.com.
www IN A 93.184.216.34
mail IN A 93.184.216.35
IN MX 10 mail.example.com.
3.6.2. Aliases and canonical names (别名和规范名称)
CNAME记录
用途: 将别名与规范名称关联
规则:
- CNAME RR标识其所有者名称是另一个"规范"或主名称的别名
- 如果域名是CNAME的别名，则它可能没有其他数据
示例:
www.example.com. IN A 93.184.216.34
ftp.example.com. IN CNAME www.example.com.
web.example.com. IN CNAME www.example.com.
; 查询ftp.example.com → 返回CNAME → 再查询www.example.com → 返回A记录
限制
CNAME链:
- 应避免过长的CNAME链
- 可能导致性能问题
- 增加查询延迟
不允许的配置:
❌ 错误示例:
example.com. IN CNAME www.example.com.
example.com. IN MX 10 mail.example.com.
; CNAME不能与其他记录共存
✅ 正确示例:
example.com. IN A 93.184.216.34
example.com. IN MX 10 mail.example.com.
www.example.com. IN CNAME example.com.
关键概念总结
域名空间特征
- 树形结构: 分层组织，根在顶部
- 标签系统: 0-63字节，兄弟唯一
- 大小写不敏感: 保留但不区分
- 长度限制: 总计255字节
- 绝对vs相对: FQDN以点结尾
资源记录核心
- 五元组: owner, type, class, TTL, RDATA
- 类型多样: A, NS, CNAME, MX, SOA等
- 类系统: 主要使用IN类
- TTL控制: 缓存时间管理
- 文本格式: 人类可读的主文件格式
设计原则
- 通用性: 不强制特定结构
- 可扩展性: 支持新类型和类
- 兼容性: 考虑现有系统
- 分布式: 管理边界对应组织
- 灵活性: 适应不同应用
下一章: 4. Name Servers (名称服务器) - 深入探讨DNS服务器的内部工作原理和算法