3. 域名空间与资源记录
3.1. 名称空间规范与术语
域名空间是一种树状结构. 树上的每个节点和叶子对应一个资源集合 (可以为空). 域名系统不区分内部节点和叶子的用途, 本备忘录使用 "节点" 一词来指代两者.
每个节点都有一个 label (标签), 长度为 0 到 63 个八位字节. 兄弟节点不能拥有相同的标签, 但非兄弟节点可以使用相同的标签. 有一个标签是保留的, 即用于根节点的空 (即零长度) 标签.
节点的域名是从该节点到树根路径上的标签列表. 按照惯例, 组成域名的标签从左到右打印或读取, 从最具体的 (最低, 距根最远) 到最不具体的 (最高, 距根最近).
内部表示
在内部, 操作域名的程序应将其表示为标签序列, 其中每个标签是一个长度八位字节后跟一个八位字节字符串. 由于所有域名都以根节点结束, 而根节点的标签为空字符串, 这些内部表示可以使用零长度字节来终止域名.
大小写敏感性
按照惯例, 域名可以以任意大小写存储, 但所有当前域名功能的域名比较都以不区分大小写的方式进行, 假设使用 ASCII 字符集和高位零比特. 这意味着你可以自由创建标签为 "A" 的节点或标签为 "a" 的节点, 但不能同时作为兄弟节点; 你可以使用 "a" 或 "A" 来引用其中任何一个. 当你收到域名或标签时, 应保留其大小写. 这种选择的理由是, 我们将来可能需要为新服务添加完整的二进制域名; 现有服务不会改变.
绝对名称与相对名称
当用户需要输入域名时, 每个标签的长度被省略, 标签之间用点号 (".") 分隔. 由于完整域名以根标签结束, 这导致打印形式以点号结尾. 我们使用此属性来区分:
-
Absolute names (绝对名称): 表示完整域名的字符串 (通常称为 "绝对"). 例如, "poneria.ISI.EDU."
-
Relative names (相对名称): 表示域名起始标签的字符串, 该域名不完整, 应由本地软件使用本地域的知识来补全 (通常称为 "相对"). 例如, 在 ISI.EDU 域中使用的 "poneria".
相对名称要么相对于一个已知的起始点, 要么相对于用作搜索列表的域列表. 相对名称主要出现在用户界面中, 其解释因实现而异, 以及在主文件中, 它们相对于单个起始域名. 最常见的解释是使用根 "." 作为单一起始点或搜索列表的成员之一, 因此多标签相对名称通常是省略了尾随点号以节省输入的名称.
长度限制
为简化实现, 表示域名的八位字节总数 (即所有标签八位字节和标签长度之和) 限制为 255.
域与子域关系
域由域名标识, 由指定该域的域名处或以下的域名空间部分组成. 如果一个域包含在另一个域中, 则它是该域的子域. 可以通过查看子域名称是否以包含域的名称结尾来测试此关系. 例如, A.B.C.D 是 B.C.D, C.D, D 和 " " 的子域.
3.2. 使用的管理指南
作为政策问题, DNS 技术规范不强制规定特定的树结构或选择标签的规则; 其目标是尽可能通用, 以便可以用于构建任意应用程序. 特别是, 该系统的设计使得名称空间不必沿网络边界、名称服务器等线路组织. 这样做的理由不是名称空间不应该有隐含的语义, 而是隐含语义的选择应该留给手头的问题, 树的不同部分可以有不同的隐含语义. 例如, IN-ADDR.ARPA 域按网络和主机地址组织和分发, 因为其作用是从网络或主机号转换为名称; NetBIOS 域 [RFC-1001, RFC-1002] 是扁平的, 因为这对该应用程序是合适的.
然而, 有一些指南适用于用于主机、邮箱等的名称空间的 "正常" 部分, 这些指南将使名称空间更加统一, 为增长提供空间, 并在软件从旧主机表转换时最小化问题. 关于树顶层的政治决定源自 RFC-920. 顶层的当前政策在 [RFC-1032] 中讨论. MILNET 转换问题在 [RFC-1031] 中涵盖.
最终将被分解为多个区域的较低域应在域的顶部提供分支, 以便最终分解可以在不重命名的情况下完成. 使用特殊字符、前导数字等的节点标签可能会破坏依赖于更严格选择的旧软件.
3.3. 使用的技术指南
在 DNS 可以用于保存某种对象的命名信息之前, 必须满足两个需求:
-
对象名称和域名之间的映射约定. 这描述了如何访问有关对象的信息.
-
用于描述对象的 RR 类型和数据格式.
这些规则可以非常简单或相当复杂. 设计者通常必须考虑现有格式并为现有用法规划向上兼容性. 可能需要多个映射或多级映射.
主机名映射
对于主机, 映射依赖于主机名的现有语法, 该语法是域名通常文本表示的子集, 以及用于描述主机地址等的 RR 格式. 由于我们需要从地址到主机名的可靠反向映射, 还定义了将地址映射到 IN-ADDR.ARPA 域的特殊映射.
邮箱映射
对于邮箱, 映射稍微复杂一些. 通常的邮件地址 <local-part>@<mail-domain> 通过将 <local-part> 转换为单个标签 (无论其包含多少点号), 将 <mail-domain> 使用域名的通常文本格式转换为域名 (点号表示标签分隔), 并将两者连接形成单个域名, 从而映射到域名. 因此, 邮箱 [email protected] 由域名 HOSTMASTER.SRI-NIC.ARPA 表示. 理解这种设计背后的原因还必须考虑邮件交换方案 [RFC-974].
典型用户不关心定义这些规则, 但应理解它们通常是在对旧用法向上兼容的愿望、不同对象定义之间的交互以及在定义规则时添加新功能的不可避免冲动之间进行大量妥协的结果. DNS 用于支持某个对象的方式通常比 DNS 本身固有的限制更为关键.
3.4. 名称空间示例
下图显示了当前域名空间的一部分, 在本 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. 首选名称语法
DNS 规范在构建域名的规则上尽量通用. 其理念是任何现有对象的名称都可以以最小的更改表示为域名. 然而, 在为对象分配域名时, 谨慎的用户将选择一个既满足域名系统规则又满足对象现有规则的名称, 无论这些规则是已发布的还是现有程序隐含的.
例如, 在命名邮件域时, 用户应同时满足本备忘录和 RFC-822 的规则. 在创建新主机名时, 应遵循 HOSTS.TXT 的旧规则. 这可以避免旧软件转换为使用域名时出现问题.
以下语法将减少许多使用域名的应用程序 (如邮件、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> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
请注意, 虽然域名中允许大写和小写字母, 但大小写不具有意义. 也就是说, 拼写相同但大小写不同的两个名称应被视为相同.
标签必须遵循 ARPANET 主机名的规则. 它们必须以字母开头, 以字母或数字结尾, 内部字符只能是字母、数字和连字符. 长度也有一些限制. 标签必须为 63 个字符或更少.
例如, 以下字符串标识互联网中的主机:
A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
3.6. 资源记录
域名标识一个节点. 每个节点都有一组资源信息, 可以为空. 与特定名称关联的资源信息集合由独立的资源记录 (Resource Records, RRs) 组成. 集合中 RR 的顺序不重要, 名称服务器、解析器或 DNS 的其他部分不需要保留该顺序.
当我们谈论特定的 RR 时, 我们假设它具有以下内容:
owner (所有者)
即找到该 RR 的域名.
type (类型)
即指定此资源记录中资源类型的 16 位编码值. 类型指抽象资源.
本备忘录使用以下类型:
- A: 主机地址
- CNAME: 标识别名的规范名称
- HINFO: 标识主机使用的 CPU 和操作系统
- MX: 标识域的邮件交换. 详见 [RFC-974].
- NS: 域的权威名称服务器
- PTR: 指向域名空间另一部分的指针
- SOA: 标识权威区域的起始
class (类)
即标识协议族或协议实例的 16 位编码值.
本备忘录使用以下类:
- IN: Internet (互联网) 系统
- CH: Chaos 系统
TTL (生存时间)
即 RR 的生存时间. 此字段是以秒为单位的 32 位整数, 主要由解析器在缓存 RR 时使用. TTL 描述 RR 在应被丢弃之前可以缓存多长时间.
RDATA
即描述资源的类型有时也依赖于类的数据:
- A: 对于 IN 类, 是 32 位 IP 地址. 对于 CH 类, 是域名后跟 16 位八进制 Chaos 地址.
- CNAME: 域名.
- MX: 16 位优先级值 (越低越好) 后跟愿意充当所有者域邮件交换的主机名.
- NS: 主机名.
- PTR: 域名.
- SOA: 多个字段.
RR 结构注意事项
所有者名称通常是隐式的, 而不是构成 RR 的组成部分. 例如, 许多名称服务器在内部为名称空间形成树或哈希结构, 并将 RR 链接到节点上. 其余的 RR 部分是固定头部 (类型、类、TTL), 对所有 RR 都一致, 以及适合所描述资源需求的可变部分 (RDATA).
TTL 字段的含义是 RR 可以保留在缓存中的时间限制. 此限制不适用于区域中的权威数据; 它也会超时, 但通过区域的刷新策略. TTL 由数据来源区域的管理员分配. 虽然可以使用短 TTL 来最小化缓存, 零 TTL 禁止缓存, 但互联网性能的现实表明, 对于典型主机, 这些时间应该以天为单位. 如果可以预期更改, 可以在更改之前减少 TTL 以最小化更改期间的不一致性, 然后在更改后将其增加回原来的值.
RR 的 RDATA 部分中的数据以二进制字符串和域名的组合形式携带. 域名经常用作 DNS 中其他数据的 "指针".
3.6.1. RR 的文本表示
RR 在 DNS 协议的数据包中以二进制形式携带, 在名称服务器或解析器中存储时通常以高度编码的形式表示. 在本备忘录中, 我们采用类似于主文件中使用的样式来显示 RR 的内容. 在这种格式中, 大多数 RR 显示在单行上, 尽管可以使用括号进行续行.
行的开头给出 RR 的所有者. 如果行以空白开头, 则所有者假定与前一个 RR 相同. 通常包含空行以提高可读性.
在所有者之后, 我们列出 RR 的 TTL、类型和类. 类和类型使用上面定义的助记符, TTL 是类型字段之前的整数. 为了避免解析中的歧义, 类型和类助记符是不相交的, TTL 是整数, 类型助记符始终在最后. 为了清晰起见, IN 类和 TTL 值通常在示例中省略.
RR 的资源数据或 RDATA 部分使用对数据典型表示的了解给出.
例如, 我们可能将消息中携带的 RR 显示为:
ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.
VENERA.ISI.EDU. A 128.9.0.32
A 10.1.0.52
VAXA.ISI.EDU. A 10.2.0.27
A 128.9.0.33
MX RR 有一个 RDATA 部分, 由 16 位数字后跟域名组成. 地址 RR 使用标准 IP 地址格式包含 32 位互联网地址.
此示例显示了六个 RR, 三个域名各有两个 RR.
类似地, 我们可能会看到:
XX.LCS.MIT.EDU. IN A 10.0.0.44
CH A MIT.EDU. 2420
此示例显示了 XX.LCS.MIT.EDU 的两个地址, 每个地址属于不同的类.
3.6.2. 别名与规范名称
在现有系统中, 主机和其他资源通常有几个标识同一资源的名称. 例如, 名称 C.ISI.EDU 和 USC-ISIC.ARPA 都标识同一主机. 类似地, 在邮箱的情况下, 许多组织提供许多实际上指向同一邮箱的名称; 例如 [email protected], [email protected] 和 [email protected] 都指向同一邮箱 (尽管背后的机制有些复杂).
这些系统大多有一个概念, 即等价名称集合中的一个是规范名称或主名称, 其他都是别名.
CNAME 记录
域名系统使用规范名称 (CNAME) RR 提供此功能. CNAME RR 将其所有者名称标识为别名, 并在 RR 的 RDATA 部分指定相应的规范名称. 如果节点上存在 CNAME RR, 则不应存在其他数据; 这确保规范名称及其别名的数据不能不同. 此规则还确保缓存的 CNAME 可以在不向权威服务器检查其他 RR 类型的情况下使用.
CNAME RR 在 DNS 软件中引起特殊操作. 当名称服务器未能在与域名关联的资源集合中找到所需的 RR 时, 它会检查资源集合是否包含具有匹配类的 CNAME 记录. 如果是, 名称服务器将 CNAME 记录包含在响应中, 并在 CNAME 记录数据字段中指定的域名处重新启动查询. 此规则的一个例外是匹配 CNAME 类型的查询不会重新启动.
例如, 假设名称服务器正在处理对 USC-ISIC.ARPA 的查询, 请求类型 A 信息, 并具有以下资源记录:
USC-ISIC.ARPA IN CNAME C.ISI.EDU
C.ISI.EDU IN A 10.0.0.52
这两个 RR 都将在对类型 A 查询的响应中返回, 而类型 CNAME 或 * 查询应只返回 CNAME.
RR 中指向另一个名称的域名应始终指向主名称而不是别名. 这避免了访问信息时的额外间接. 例如, 上述主机的地址到名称 RR 应为:
52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU
而不是指向 USC-ISIC.ARPA. 当然, 根据健壮性原则, 域名软件在遇到 CNAME 链或循环时不应失败; 应跟踪 CNAME 链, 并将 CNAME 循环作为错误发出信号.
3.7. 查询
查询是可以发送到名称服务器以引发响应的消息. 在互联网中, 查询通过 UDP 数据报或 TCP 连接传输. 名称服务器的响应要么回答查询中提出的问题, 要么将请求者引用到另一组名称服务器, 要么发出某种错误条件信号.
通常, 用户不直接生成查询, 而是向解析器发出请求, 解析器再向名称服务器发送一个或多个查询, 并处理可能产生的错误条件和引用. 当然, 查询中可以提出的可能问题确实影响解析器可以提供的服务类型.
消息格式
DNS 查询和响应以标准消息格式携带. 消息格式有一个包含若干固定字段的头部 (始终存在) 和四个携带查询参数和 RR 的节.
头部中最重要的字段是称为操作码 (opcode) 的四位字段, 用于区分不同的查询. 在可能的 16 个值中, 一个 (标准查询) 是官方协议的一部分, 两个 (反向查询和状态查询) 是选项, 一个 (完成) 已废弃, 其余未分配.
四个节是:
- Question (问题): 携带查询名称和其他查询参数.
- Answer (应答): 携带直接回答查询的 RR.
- Authority (权威): 携带描述其他权威服务器的 RR. 可以选择性地携带应答节中权威数据的 SOA RR.
- Additional (附加): 携带在使用其他节中的 RR 时可能有用的 RR.
请注意, 这些节的内容 (但不是格式) 随头部操作码而变化.
3.7.1. 标准查询
标准查询指定目标域名 (QNAME)、查询类型 (QTYPE) 和查询类 (QCLASS), 并请求匹配的 RR. 这种类型的查询占 DNS 查询的绝大多数, 因此我们使用 "查询" 一词来表示标准查询, 除非另有说明. QTYPE 和 QCLASS 字段各为 16 位长, 是已定义类型和类的超集.
QTYPE 字段可以包含:
<any type>: 仅匹配该类型. (如 A, PTR).- AXFR: 特殊区域传输 QTYPE.
- MAILB: 匹配所有邮箱相关 RR (如 MB 和 MG).
*: 匹配所有 RR 类型.
QCLASS 字段可以包含:
<any class>: 仅匹配该类 (如 IN, CH).*: 匹配所有 RR 类.
使用查询域名、QTYPE 和 QCLASS, 名称服务器查找匹配的 RR. 除相关记录外, 名称服务器还可以返回指向拥有所需信息的名称服务器的 RR, 或预期在解释相关 RR 时有用的 RR. 例如, 没有请求信息的名称服务器可能知道有该信息的名称服务器; 在相关 RR 中返回域名的名称服务器也可能返回将该域名绑定到地址的 RR.
查询和响应示例
例如, 尝试向 [email protected] 发送邮件的邮件程序可能会向解析器请求有关 ISI.EDU 的邮件信息, 从而产生 QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN 的查询. 响应的应答节将是:
ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.
而附加节可能是:
VAXA.ISI.EDU. A 10.2.0.27
A 128.9.0.33
VENERA.ISI.EDU. A 10.1.0.52
A 128.9.0.32
因为服务器假设如果请求者想要邮件交换信息, 它很快就会需要邮件交换的地址.
请注意, QCLASS=* 构造需要关于权威性的特殊解释. 由于特定名称服务器可能不知道域名系统中所有可用的类, 它永远无法知道它是否对所有类都具有权威性. 因此, 对 QCLASS=* 查询的响应永远不能是权威的.
3.7.2. 反向查询 (可选)
名称服务器还可以支持将特定资源映射到具有该资源的域名的反向查询. 例如, 标准查询可能将域名映射到 SOA RR, 而相应的反向查询可能将 SOA RR 映射回域名.
此服务在名称服务器中的实现是可选的, 但所有名称服务器必须至少能够理解反向查询消息并返回未实现错误响应.
域名系统无法保证反向查询的完整性或唯一性, 因为域名系统按域名而不是主机地址或任何其他资源类型组织. 反向查询主要用于调试和数据库维护活动.
反向查询可能不会返回正确的 TTL, 也不会指示所标识的 RR 是集合中的一个 (例如, 具有多个地址的主机的一个地址). 因此, 反向查询中返回的 RR 不应被缓存.
反向查询不是将主机地址映射到主机名的可接受方法; 请改用 IN-ADDR.ARPA 域.
反向查询的详细讨论包含在 [RFC-1035] 中.
3.8. 状态查询 (实验性)
待定义.
3.9. 完成查询 (已废弃)
RFC 882 和 883 中描述的可选完成服务已被删除. 重新设计的服务将来可能会提供, 或者操作码可能会被重新用于其他用途.