跳到主要内容

2. 通配符语法

2. 通配符语法 (Wildcard Syntax)​

本节描述与通配符相关的语法, 包括如何将记录解释为通配符, 以及如何从通配符创建记录. 第 2.1 节和第 2.2 节是规范性的, 它们更新了 RFC 1034 第 4.3.3 节.

2.1 识别通配符 (Identifying a Wildcard)​

RFC 1034 第 4.3.3 节中对 "wildcard" 的定义实际上是通配符域名 (wildcard domain name) 的定义, 但它把术语本身与术语的使用混在了一起. 通配符域名的定义是, 其初始标签 (即最左侧或最低有效的标签) 在二进制格式中为:

0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)

第一个八位字节是长度为 1 个八位字节的普通标签类型和长度, 第二个八位字节是 '*' 字符的 ASCII 表示 [RFC20].

等于该值的标签可描述性地称为 "星号标签 (asterisk label)".

本节通过区分标签和域名来细化该定义.

本节更新 RFC 1034 第 4.3.3 节.

2.1.1 通配符域名和星号标签 (Wildcard Domain Name and Asterisk Label)​

第一个定义是 "星号标签", 即等于以下值的标签:

0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)

"通配符域名" 定义为以星号标签作为最低有效标签的域名.

如果一个域名只在最低有效标签中包含星号标签, 则可描述性地称为 "通配符域名".

这个定义因在本单独小节中重复而被突出强调.

2.1.2 星号和其他字符 (Asterisks and Other Characters)​

除第 2.1.1 节中的值之外, 其他任何标签值都不是星号标签. 因此, 如果一个名称中等于该值的标签不是最左侧标签, 该名称就不是通配符域名. 等于以下值的标签:

0000 0011 0111 1110 0010 1010 0010 1010 (binary)
= 0x03 0x7e 0x2a 0x2a (hexadecimal) = '~**'

在表示形式中可能看起来包含星号, 但由于该标签不是 * (** 是 2 个字符), 且它不是最低有效标签, 因此不会发生特殊处理.

如果名称包含的星号标签不在最低有效标签位置, 该名称就不是通配符域名. 例如, 如果域名 '.example.com' 是通配符域名, 那么 'a..example.com' 就不是通配符域名, 而是一个包含四个标签的普通域名.

2.1.3 非终端通配符域名 (Non-terminal Wildcard Domain Names)​

通配符域名可以拥有子域. 没有必要区分拥有子域的通配符域名和没有子域的通配符域名. 请看以下两个示例:

  *.example. 3600 IN MX 10 host1.example.
  host3.*.example. 3600 IN MX 10 host1.example.

通配符域名的定义是: a) 该名称以星号标签作为最低有效标签, 并且 b) 该名称处至少存在一个 RRSet. 术语 "非终端通配符域名 (non-terminal wildcard domain name)" 用于描述这样一种通配符域名: 它因为被显式配置了数据而存在, 同时又拥有子域. 上面的后一个示例表明, host3..example. 是通配符域名 (.example.) 的一个子域.

2.2 存在性规则 (Existence Rules)​

RFC 1034 没有定义域名 "存在 (existence)" 的概念. 虽然所有域名显然都以标签序列的形式在某处 "存在", 但 RFC 1034 中的存在性概念具有较窄含义. 在那里, "存在" 基于域名要么是一个或多个资源记录的所有者 (即 "RR 所有者名称 (RR owner name)"), 要么是委派点 (delegation point). 后来, "存在" 的定义被细化, 以纳入 [RFC2672] 所作的变更. [RFC2672] 定义了 DNAME 资源记录类型, 并引入了 "非终端 (non-terminal)" 域名的概念 (即既不是 RRSet 所有者, 也不是委派点的域名). 本次修订使用 RFC 2672 第 8 节中描述的术语 "非终端", 但增加了非终端可以为空非终端的可能性. 空非终端情形在第 2.2.2 节中说明.

在本文档中, 域名的存在性按以下规则确定:

  • 如果该域名是一个或多个资源记录的所有者名称, 则称其存在, 无论这些资源记录的内容或类型如何. 否则,
  • 如果该域名是委派点, 则它存在. 否则,
  • 如果该域名位于某个现有域名 "之下" (即它是某个现有域名的子域), 则它存在. 否则,
  • 该域名不存在.

需要考虑这种情况, 是为了覆盖域名被从树中完全移除的情形. 过去没有考虑这类情形, 因为当时并不认为其后果具有重要意义. 在大多数情况下, 术语 "存在" 缺少定义并未造成问题, 因为名称服务器的设计并不会要求它们记住自己曾经知道某个域名存在, 而该域名随后已被移除. 仅仅没有某个名称的信息, 并不能说明它是否存在, 只能反映未知. 通常, 能够区分一个域名曾经存在但现在不再存在, 与一个域名从未存在过, 并没有实际意义.

当使用 DNSSEC 时, 可以断言某个域名存在或不存在. DNSSEC 提供了一种认证否定机制. 就本文档而言, 认证否定定义为域名不存在的证明. 认证否定通过提供 "最近包围者 (closest encloser)" 存在的证明来建立, 该概念在第 3.3.1 节中说明. 这一证明需要存在性的定义, 该定义已在上文给出.

2.2.1 示例 (An Example)​

在包含以下 RR 的区域中:

  example. 3600 IN SOA <SOA RDATA>
  example. 3600 IN NS ns.example.
  *.example. 3600 IN TXT "this is a wildcard"
  host.example. 3600 IN A 192.0.2.1
  _telnet._tcp.host.example. 3600 IN SRV <SRV RDATA>

域名 "example.", ".example.", "host.example." 和 "_telnet._tcp.host.example." 存在. 对 "_smtp._tcp.host.example." 的查询会匹配 ".example." 通配符, 这表明 "_smtp._tcp.host.example." 不存在 (根据第 2.2 节前三条规则). 对 "host..example." 的查询可用于证明 "host..example." 按同样三条规则并不存在. 对 "_telnet._tcp..example." 的查询会表明 "_telnet._tcp..example." 位于现有域名之下, 因而确实存在.

2.2.2 空非终端 (Empty Non-terminals)​

空非终端 (empty non-terminals) 是不拥有资源记录, 但拥有子域且这些子域拥有资源记录的域名. 在第 2.2.1 节中, host.example. 和 _telnet._tcp.host.example. 存在. 域名 _tcp.host.example. 也存在, 但没有 RR. _tcp.host.example. 的存在可以从 _telnet._tcp.host.example. 的存在推断出来. 因此, _tcp.host.example. 是一个 "空非终端".

该术语用于描述这样一种情况: 某个域名本身不是权威数据, 也不是委派点. 空非终端可能作为另一个域名存在的结果而存在, 因而其存在是隐含的. 如果某个域名的存在由其他数据隐含, 就没有理由枚举它. 不过在 DNSSEC 中, 有时必须显式枚举空非终端的存在.

根据第 3.3.1 节, 通配符能够匹配某个域名的唯一方式是该域名不存在. 存在性包括空非终端.

2.2.3 存在性的另一个定义 (Yet Another Definition of Existence)​

对同一概念还可以这样解释: 在 DNS 中, 如果 1) 权威数据中存在以该名称为名的记录, 或者 2) 该名称位于另一个已知存在的名称之下 (位于分割点之下或位于 RRSet 所有者名称之下), 则该域名存在.

对 DNSSEC [RFC4033] 而言, 存在性的定义是相关的. 例如, 如果查询的名称不是通配符自身的名称, 但匹配某个通配符, 则答案是一个通过合成记录构造出来的答案. 该合成答案会使一组记录与新的所有者名称相关联, 但并不会使这个新的所有者名称变为存在. 这一点很重要, 因为在 DNSSEC 中, 只有在存在该名称不存在的认证证明时, 才能称某个名称 "不存在". 然而, 由通配符合成构造出的名称既没有被证明存在, 也没有被证明不存在, 因此解析器不得基于通配符匹配断言该名称存在或不存在.

2.3 通配符域名何时不特殊? (When Is a Wildcard Domain Name Not Special?)​

本文档关于通配符的讨论, 涉及查询中域名的匹配, 以及使用通配符域名进行响应合成. 在更新 RFC 1034 第 3.4.2.2 节的上下文中, 即出现 "RRs with wildcard names" 这段文本的地方, 并不使用术语 "通配符域名". 表述 "do not check for conflicts with wildcard domain names" 的含义是 "包含星号标签的域名". 该名称是否为通配符域名并不重要. 换言之, 在考虑一次更新是否与现有通配符冲突时, 应忽略该更新的内容. 动态更新和区域传送也是如此.

通配符域名只有在用于合成记录时才是特殊的. 在所有其他情况下, 它并不特殊. 通配符域名只在 RFC 1034 第 4.3.2 节指定的解析算法第 3.c 步中具有特殊性. 在所有其他情形中, 包括区域文件传送, 通配符域名都不特殊.

最后于 更新