跳到主要内容

1. 引言

1. 引言 (Introduction)​

在 RFC 1034 [RFC1034] 中, 第 4.3.2 节和第 4.3.3 节描述了如何从称为通配符 (wildcards) 的特殊资源记录 (resource records, RRs) 合成答案. RFC 1034 中的定义并不完整, 且事实证明容易引起混淆. 本文档通过补充讨论并作出有限修改来描述通配符合成. 这些修改用于消除已经导致互操作性问题的不一致之处. 本描述不会扩展原始定义所预期的服务范围.

本文档保持原始文档的精神和风格, 避免为 DNS 实现规定有关通配符的规则. 其意图只是描述互操作性所需的内容, 而不是限制实现选择. 此外, 本文档也考虑尽量减少与符合 RFC 1034 定义的实现之间可能出现的向后兼容性问题.

本文档聚焦于 RFC 1034 所定义的通配符概念. 对于合成资源记录集 (resource record sets, RRSets) 的替代方式, 本文档既不作任何暗示, 也不展开讨论.

1.1 动机 (Motivation)​

许多 DNS 实现以不同方式偏离了通配符的原始定义. 仅凭这一点, 就已经明确需要澄清原始文档. 不过, 推动本文档产生的直接动力来自 DNS 安全扩展 [RFC4033] 的工程设计. 在通配符定义不清晰的情况下, 认证否定 (authenticated denial) 的设计变得纠缠不清.

本文档有意限制变更范围, 只记录基于实现经验被认为必要的内容, 并尽可能贴近原始文档. 为了强调本文档旨在澄清和调整通配符, 而不是重新定义通配符, 文中逐字重复了 RFC 1034 的相关章节, 以便比较新旧文本.

1.2 原始定义 (The Original Definition)​

通配符概念的定义由两部分构成: 一部分是名称服务器准备响应所用算法的说明 (RFC 1034 第 4.3.2 节), 另一部分是将资源记录 (集) 识别为合成数据来源的方式 (第 4.3.3 节).

以下是 RFC 1034 第 4.3.3 节中术语 "wildcard" 的定义.

# In the previous algorithm, special treatment was given to RRs with
# owner names starting with the label "*".  Such RRs are called
# wildcards. Wildcard RRs can be thought of as instructions for
# synthesizing RRs.  When the appropriate conditions are met, the
# name server creates RRs with an owner name equal to the query name
# and contents taken from the wildcard RRs.

这段文字紧接在首次使用术语 wildcard 的算法之后. 在该定义中, wildcard 指资源记录. 在其他用法中, wildcard 曾指域名, 也曾用于描述依赖通配符生成答案的运维实践. 由此可见, 在讨论通配符时需要定义清晰且无歧义的术语.

RFC 1034 第 4.3.2 节标题为 "Algorithm", 其中第 3 步的 'c' 部分提到了在准备响应时使用通配符. 注意, "wildcard" 一词并未出现在该算法中, 算法引用的是 "*" 标签. 本文档第 3 节会详细拆解该算法中与通配符相关的部分. 以下是 "Algorithm" 中相关部分的开头.

#    c. If at some label, a match is impossible (i.e., the
#       corresponding label does not exist), look to see if [...]
#       the "*" label exists.

本文档的范围是 RFC 1034 对通配符的定义, 以及对这些文档的更新所带来的影响, 例如 DNS 安全 (DNS Security, DNSSEC). 本文档不考虑合成答案的替代方案. (注意, 这里没有列出参考文献. 目前不知道有任何文档描述过替代方案, 尽管邮件列表中曾有过相关提及.)

1.3 本文档路线图 (Roadmap to This Document)​

本文档完成以下三项任务.

  • 定义新术语
  • 作出少量修改以避免概念冲突
  • 描述某些资源记录作为通配符时的行为

1.3.1 新术语 (New Terms)​

为了帮助讨论哪些资源记录是通配符, 本文档将定义两个术语: "星号标签 (asterisk label)" 和 "通配符域名 (wildcard domain name)". 这些术语在第 2.1.1 节中定义.

为了帮助澄清通配符在 RFC 1034 第 4.3.2 节名称服务器算法中的角色, 本文档定义了 "合成源 (source of synthesis)" 和 "最近包围者 (closest encloser)". 这些术语在第 3.3.1 节中定义.

1.3.2 变更文本 (Changed Text)​

通过以本文档第 2.1 节的文本替换 RFC 1034 第 4.3.3 节的文本, "wildcards" 是什么这一问题的定义已经被修改. 替换文本将 "通配符域名" 和 "星号标签" 定义为术语. 这样做无意改变含义, 只是希望表达更加清晰.

作出此变更的原因是, 在 RFC 1034 中, 术语 wildcard 以两种方式定义. 在第 4.3.3 节中, "wildcard" 用于命名资源记录. 在第 4.3.2 节的算法中, "wildcards" 是域名和标签, 而不是资源记录. 由于后一种情况并不清楚术语 "wildcard" 是一种用法还是两种用法 (一种用于标签, 另一种用于名称), 因此引入了新术语.

RFC 1034 第 4.3.2 节中第 3 步算法的一部分已经变更, 并在本文档第 3.3.3 节中给出. 这样做的基础是允许特殊类型的合成, 并禁止某些类型成为合成源, 例如 SIG (RRSIG 的旧名称).

1.3.3 特殊类型的考虑事项 (Considerations with Special Types)​

第 4 节考察各种资源记录类型, 并说明应当如何处理以及不应如何处理它们.

RFC 1034 已经阐明, CNAME 是一种不能与其他数据共存的类型. 不过, 鉴于 "wildcard" 文本已经修订, 有必要讨论当合成源中存在 CNAME RRSet 时对合成的禁止.

其他资源记录类型与通配符之间的交互, 按其状态顺序进行讨论: 标准, 实验性, 废弃和弃用.

1.4 标准术语 (Standards Terminology)​

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 和 "OPTIONAL" 应按 RFC 2119 [RFC2119] 中的描述解释.

由于这些关键词只在讨论协议时使用, 唯一相关的内容是第 4 节, 而第 4 节会引用第 3 节. 本文档其余部分仅供参考, 用于阐述和澄清概念.

RFC 1034 使用术语 "authoritative" 来描述拥有 "the complete information for a zone" 的名称服务器. 为避免混淆, 本文档使用术语 "权威名称服务器 (authoritative name server)" 和 "区域 (zone)" 来描述与 RFC 1034 相同的关系, 即名称服务器对某个特定区域的内容具有权威性. 作出这种区分是因为名称服务器通常对多个区域具有权威性, 但并不对整个 DNS 树具有权威性.

最后于 更新