10. Naming issues (命名问题)

有时从DNS规范[RFC1034, RFC1035]的某些部分推断，主机或主机的接口被允许恰好有一个权威或官方名称，称为规范名称（canonical name）。DNS中没有这样的要求。

10.1. CNAME resource records (CNAME资源记录)

DNS CNAME（"规范名称"，canonical name）记录的存在是为了提供与别名相关联的规范名称。任何一个别名可能只有一个这样的规范名称。该名称通常应该是DNS中其他地方存在的名称，尽管对于具有伴随规范名称在DNS中未定义的别名有一些罕见的应用。别名（CNAME记录的标签）如果使用DNSSEC，可能有SIG、NXT和KEY RR，但不能有其他数据。也就是说，对于DNS中的任何标签（任何域名），以下之一为真：

• 存在一个CNAME记录，可选地伴随SIG、NXT和KEY RR
• 存在一个或多个记录，其中没有一个是CNAME记录
• 该名称存在，但没有任何类型的关联RR
• 该名称根本不存在

10.1.1. CNAME terminology (CNAME术语)

传统上将CNAME记录的标签称为"一个CNAME"。这是不幸的，因为"CNAME"是"规范名称"（canonical name）的缩写，而CNAME记录的标签肯定不是规范名称。然而，这是一种根深蒂固的用法。因此，必须非常小心地明确是指CNAME资源记录的标签还是值（规范名称）。在本文档中，CNAME资源记录的标签将始终称为别名（alias）。

10.2. PTR records (PTR记录)

关于规范名称的混淆导致了一种信念，即PTR记录应该在其RRSet中恰好有一个RR。这是不正确的，RFC1034的相关部分（第3.6.2节）指出PTR记录的值应该是规范名称。也就是说，它不应该是别名。该部分没有暗示一个名称只允许一个PTR记录。不应推断出这样的限制。

请注意，虽然PTR记录的值不得是别名，但解析PTR记录的过程不需要不遇到任何别名。正在为PTR值查找的标签可能有一个CNAME记录。也就是说，它可能是一个别名。该CNAME RR的值（如果不是另一个别名，它不应该是）将给出找到PTR记录的位置。该记录给出PTR类型查找的结果。这个最终结果，即PTR RR的值，是不得是别名的标签。

10.3. MX and NS records (MX和NS记录)

用作NS资源记录值的域名，或作为MX资源记录值的一部分的域名不得是别名。不仅规范在这一点上是明确的，而且在这些位置使用别名既不能如预期的那样工作，也不能很好地实现可能导致这种方法的目标。此域名必须有一个或多个地址记录作为其值。目前这些将是A记录，但在未来可能接受提供地址信息的其他记录类型。它也可以有其他RR，但永远不能是CNAME RR。

搜索NS或MX记录会导致"附加部分处理"（additional section processing），其中与所查找记录的值相关联的地址记录被附加到答案中。这有助于避免在进行第一个查询时容易预期的不必要的额外查询。

附加部分处理不包括CNAME记录，更不用说可能与从别名派生的规范名称相关联的地址记录了。因此，如果将别名用作NS或MX记录的值，则不会随NS或MX值返回地址。这可能导致每次查询时额外的查询和额外的网络负担。DNS管理员通过解析别名并在受影响的记录更新或安装时直接在其中放置规范名称，可以轻易地避免这一点。在某些特定的困难情况下，NS查找结果中缺少附加部分地址记录可能会导致请求失败。

---