10. 命名问题
有时人们从 DNS 规范 [RFC1034, RFC1035] 的某些章节中推断出, 一台主机, 或者主机的某个接口, 被允许拥有恰好一个权威的, 或者说正式的, 称为规范名称 (canonical name) 的名称. DNS 中并没有这样的要求.
10.1. CNAME 资源记录
DNS CNAME ("canonical name") 记录的存在, 是为了提供与某个别名名称相关联的规范名称. 对任何一个别名而言, 这样的规范名称只能有一个. 该名称通常应当是 DNS 中其他地方已存在的名称, 尽管在某些罕见应用中, 别名的相应规范名称在 DNS 中并未定义. 若 DNSSEC 在使用中, 别名名称 (CNAME 记录的标签) 可以拥有 SIG, NXT 和 KEY RR, 但不得拥有任何其他数据. 也就是说, 对 DNS 中的任何标签 (任何域名), 下列各项中恰好有一项为真:
- 存在一条 CNAME 记录, 可选地伴随 SIG, NXT 和 KEY RR,
- 存在一条或多条记录, 其中没有 CNAME 记录,
- 该名称存在, 但没有任何类型的关联 RR,
- 该名称完全不存在.
10.1.1. CNAME 术语
传统上把 CNAME 记录的标签称为 "a CNAME". 这很不幸, 因为 "CNAME" 是 "canonical name" 的缩写, 而 CNAME 记录的标签肯定不是一个规范名称. 然而, 这是一种根深蒂固的用法. 因此必须小心, 务必非常清楚所要指的是 CNAME 资源记录的标签, 还是它的值 (即规范名称). 在本文档中, CNAME 资源记录的标签将一律称为别名.
10.2. PTR 记录
关于规范名称的混淆导致了一种看法, 即一条 PTR 记录的 RRSet 中应当恰好只有一条 RR. 这是不正确的, RFC1034 的相关章节 (第 3.6.2 节) 指出, PTR 记录的值应当是一个规范名称. 也就是说, 它不应是别名. 该章节中并没有任何含义表明一个名称只允许有一条 PTR 记录. 不应推断出这样的限制.
注意, 虽然 PTR 记录的值不得是别名, 但并没有要求解析 PTR 记录的过程不会遇到任何别名. 为取得 PTR 值而查找的那个标签可能拥有一条 CNAME 记录. 也就是说, 它可能是一个别名. 那条 CNAME RR 的值 (如果不是另一个别名的话 -- 它本不应该是) 将给出找到 PTR 记录的位置. 那条记录给出 PTR 类型查找的结果. 这个最终结果, 即 PTR RR 的值, 才是不得为别名的那个标签.
10.3. MX 和 NS 记录
用作 NS 资源记录值的域名, 或者用作 MX 资源记录值一部分的域名, 都不得是别名. 规范在这一点上不仅说得很清楚, 而且在上述任一位置使用别名, 既不会像人们所期望的那样有效, 也无法很好地实现可能导致这种做法的初衷. 这个域名必须以一条或多条地址记录作为其值. 目前这些将是 A 记录, 但将来给出寻址信息的其他记录类型也可能是可接受的. 它也可以拥有其他 RR, 但绝不能是 CNAME RR.
查找 NS 或 MX 记录都会引发 "附加节处理 (additional section processing)", 即把与所查找记录的值相关联的地址记录附加到答案中. 这有助于避免在发出第一个查询时就能轻易预见到的那些不必要的额外查询.
附加节处理不包括 CNAME 记录, 更不用说那些可能与由别名导出的规范名称相关联的地址记录了. 因此, 如果某个别名被用作 NS 或 MX 记录的值, 那么返回 NS 或 MX 值时将不会附带任何地址. 这会在每次查询时造成额外的查询和额外的网络负担. DNS 管理员要避免这一点是轻而易举的: 在更新或安装受影响的记录时, 只需一次性解析该别名并把规范名称直接写入该记录即可. 在某些特别的困难情形中, NS 查找结果中缺少附加节地址记录可能导致请求失败.