4. 特殊类型的考虑事项

4. 特殊类型的考虑事项 (Considerations with Special Types)

本节汇总各种类型的处理行为. 其中大多数规定源于某一类型的 RR 是否可以共存. 也有一些内容只是观察性说明.

4.1 通配符域名处的 SOA RRSet (SOA RRSet at a Wildcard Domain Name)

通配符域名拥有 SOA RRSet 意味着该域位于区域顶点 (apex), 且它是一个通配符域名. 这是对 RFC 1035 中 SOA 定义的细化, 在 RFC 1035 中, SOA RR 位于区域顶点. 这只是澄清, 无意表示规范发生变更.

通配符域名拥有 SOA 记录的效果未定义. 为避免通配符被用于合成 SOA 记录的情况, SOA 记录禁止成为通配符域名处的唯一记录.

该禁止对 AXFR 和 IXFR 有影响, 但本文档不在此讨论.

4.2 通配符域名处的 NS RRSet (NS RRSet at a Wildcard Domain Name)

RFC 1034 第 4.2.2 节对 NS 记录的所有权作出了限制:

# If a CNAME RR is present at a node, no other data should be
# present; this ensures that the data for a canonical name and its
# aliases cannot be different.  This rule also insures that a
# cached CNAME can be used without checking with an authoritative
# server for other RR types.

必须区分委派点名称和出现在委派 RDATA 中的域名, 这一区分非常重要. 前者是拥有 NS RRSet 的名称. 后者是可能拥有 A 或 AAAA RRSet 的名称. 例如, 对于以下委派:

  foo.example. NS ns1.example.
  ns1.example. A 192.0.2.1

名称 "foo.example." 是委派点名称, 而 "ns1.example." 是出现在 RDATA 中的名称. 名称 "foo.example." 拥有 NS RRSet. 名称 "ns1.example." 拥有 A RRSet. 这是非常重要的区别, 因为通配符合成可以应用于后者, 但不能应用于前者.

通配符域名不是委派点. NS RRSet 的合成尚未定义. 早期一些 DNS 工作曾考虑允许合成委派点, 但这种可能性已经被拒绝. RFC 1034 写道:

# A particular subzone and the associated NS RRs are added to the
# zone when the domain administrator decides to delegate the
# subzone, by adding the subzone's NS RRs to the parent zone.

委派决定是在 NS RR 被添加到区域时作出的. 短语 "adding NS RRs to a zone" 被解释为委派点通过显式配置添加. 术语 "wildcard" 没有出现在 RFC 1034 的委派部分 (第 4.2.2 节). 因此, 有意不将通配符用于 NS RR.

由于不允许合成 NS, 执行合成的服务器没有额外工作要做.

4.2.1 已舍弃的概念 (Discarded Notions)

曾经有人区分合成委派点, 合成区域内数据以及合成名称服务器名称. 由于本文档规定不允许合成委派点, 因此没有必要进一步探讨这种区分. 类似地, 也没有必要区分区域内通配符匹配和名称服务器名称匹配.

4.3 通配符域名处的 CNAME RRSet (CNAME RRSet at a Wildcard Domain Name)

CNAME 与通配符之间的交互在本文档第 3.3.3 节中更新. 通配符域名处的 CNAME RRSet 只能用于合成 CNAME RR. 拥有 CNAME RRSet 的通配符域名不能拥有任何其他资源记录.

4.4 通配符域名处的 DNAME RRSet (DNAME RRSet at a Wildcard Domain Name)

通配符域名拥有 DNAME [RFC2672] RRSet 会威胁 DNS 的一致性 (coherency), 应避免或直接拒绝. 这种 DNAME RRSet 表示以非确定方式合成规则并提供给不同缓存. 当缓存以不可预测的方式接收到不同规则时, 这些缓存将不再保持一致. ("As caches are fed" 指递归服务器或迭代服务器将响应中获得的记录存入缓存.)

例如, 假设一个缓存服务器在响应递归请求时获得以下记录:

  "a.b.example. DNAME foo.bar.example.net."

而另一个缓存服务器获得:

  "b.example.  DNAME foo.bar.example.net."

二者都由以下记录生成:

  "*.example. DNAME foo.bar.example.net."

生成者是权威服务器.

DNAME 规范并未明确缓存中的 DNAME 记录是否用于重写查询. 在某些解释中会发生重写, 在另一些解释中则不会. 如果允许发生重写, 对 "sub.a.b.example. A" 的查询可能被前一个缓存服务器重写为 "sub.foo.bar.tld. A", 而被后一个缓存服务器重写为 "sub.a.foo.bar.tld. A". 一致性因此丧失, 并引发运维噩梦.

建议避免使用通配符 DNAME 记录的另一个理由是, 这种记录可能合成由 "sub.foo.bar.example." 和 "foo.bar.example." 拥有的 DNAME. DNAME 定义中有限制: 在拥有 DNAME 的域之下不得存在任何域. 因此, 应避免使用通配符 DNAME.

4.5 通配符域名处的 SRV RRSet (SRV RRSet at a Wildcard Domain Name)

SRV RRSet 的定义见 RFC 2782 [RFC2782]. 在该记录的定义中, 术语 "Name" 存在一些混淆. 定义如下:

# The format of the SRV RR
...
#    _Service._Proto.Name TTL Class SRV Priority Weight Port Target
...
#  Name
#   The domain this RR refers to.  The SRV RR is unique in that the
#   name one searches for is not this name; the example near the end
#   shows this clearly.

不要将定义中的 "Name" 与所有者名称混淆. 也就是说, 从 SRV RRSet 的所有者名称中移除 _Service 和 _Proto 标签后, 剩余部分可能是通配符域名, 但这对 SRV RRSet 并不重要.

例如, 如果 SRV 记录如下:

  _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.

.example 是通配符域名. 虽然它是 SRV RR 的 Name, 但它不是所有者 (域名). 所有者域名是 "_foo._udp..example.", 它并不是通配符域名.

对 "_foo._udp.bar.example." 的 SRV RRSet 查询 (类别 IN) 会导致名称 ".example." 被匹配 (假设不存在 bar.example.), 而不是匹配上面显示的 SRV 记录. 如果 ".example." 处没有 SRV RRSet, 答案部分会反映这一点 (为空或为 CNAME RRSet).

这种混淆很可能源于 SRV RR 规范与 "用例 (use case)" 描述混在了一起.

4. 特殊类型的考虑事项