摘要

  • DNS 通配符不是正则表达式，而是首标签为 * 的资源记录集；只有逐标签精确匹配走出权威区树时，服务器才考虑使用它。
  • RFC 4592 要求先找到查询名的最近包围者，再且只检查 *.<最近包围者>；候选不存在或缺少所问类型时，不得改找更远的通配符。
  • DNSSEC 验证通配回答时，既要认证源记录，也要证明不存在更精确或更接近的名字；这并不证明目标安全或查询者本来就想访问它。

服务器回答了一个从未存过的所有者名

假设区域里有 *.example 的地址记录，却没有 blue.example。服务器仍可为后一个查询返回正面回答：可见所有者写成 blue.example，值、类型与 TTL 取自通配记录。回答是为这次问题合成的，区域并没有保存这个精确所有者。

RFC 1034 在 1987 年把通配记录称为合成记录的指令。邮件转发曾是典型用途：区域中未列出的名字可以共享交付属性。但星号既没有注册无限多个名字，也不是匹配任意字符串的语法。它只授权权威服务器在满足条件时执行一次确定动作。

因此，正面 DNS 回答不能自动证明某人逐个配置、审查或有意创造了该名字。DNS 能证明的是区域算法允许这份回答；名字背后的意图与应用信任仍需别的证据。

已存在的节点先行使拒绝权

服务器先做普通的逐标签匹配。名字若存在，通配符不能替它补齐缺失类型。某节点有 AAAA、没有 MX，结果就是该节点没有 MX，而不是从 *.example 借来一条 MX。

“存在”也不等于节点自身必须带记录。一个中间名字只要拥有更深的后代，就是空非终结点。这个沉默节点仍在树上，足以改变最近匹配位置。新增一条看似无关的深层记录，可能让此前的通配回答突然停止。

删除最后一个后代则可能反向扩大默认值：空非终结点随之消失，更宽的通配符再次获得合成资格。通配记录没有变，决定其权限的周围结构变了。

最近包围者把直觉变成唯一计算

早期规范的措辞在实现和 DNSSEC 设计中暴露出歧义。RFC 4592 因而定义了“最近包围者”：区域里真实存在、并从根开始与查询名共享最长连续后缀标签的节点。

精确匹配从树上掉落后，服务器只形成一个候选，即紧邻最近包围者之下的 *.<最近包围者>。它存在，才是本次查询的合成源；它不存在，就没有通配合成。

服务器不会向祖先方向寻找备用星号。候选存在但缺少所问类型时，得到的是通配无数据，不会让更远的通配符填空。于是每次查询最多只有一个合成源，嵌套通配也有可重复计算的结果。

“一个星号覆盖域名下所有内容”由此成为危险简写。任何更近的显式节点，哪怕只是空非终结点，都会重新计算唯一候选。覆盖范围不是星号占有的疆域，而是当前树结构与具体查询共同产生的结果。

星号只是一个标签

只有最左侧标签恰好是 *，整个域名才具有通配语义。星号出现在其他位置没有这种能力。查询名里写入字面星号，也不是向 DNS 发出模式搜索请求；它仍按普通标签处理，甚至可直接查询通配所有者本身。

合成完成后，记录类型的普通规则继续生效。通配 CNAME 可以先被合成，再走正常别名处理。这不把 DNS 变成应用重定向器、证书策略引擎或模糊匹配系统。

委派终止父区域的默认权

RFC 1034 已经明确：通配默认值不能跨越区域边界。匹配遇到委派时，父区域把解析器引向子区域，而不是把自己的星号延伸到委派之下。子区域可以自行建立通配规则，但那属于新的权威数据。

这是一条控制边界。父区域交出子树后，不能仍用隐藏默认回答填充其中所有空缺；子区域运营者也不能假设父级通配行为会随委派自动继承。

合成成立之前，先证明没有更近答案

通配回答依赖一个不易看见的前提：没有更具体的名字拥有优先权。RFC 4035 让签名区域必须证明这个前提。回答要携带展开后的记录与签名，也要提供经认证的 NSEC 否定证据，说明精确名字或更近匹配不存在。

RRSIG 的标签计数使验证者能从可见查询名重建真正被签名的通配所有者。于是验证分为两项：源数据确由区域签名；区域树中的空缺确实授权该源生效。

证明止于此处。DNSSEC 不证明拼写符合人的原意，不保证目标服务安全，也不替应用决定身份或权限。它认证区域陈述及其树上优先规则。

来源与边界

封闭来源为 RFC 1034、RFC 4592 与 RFC 4035。它们确立机制、术语和 DNSSEC 证明义务，不提供当前部署率、查询量、滥用比例、解析器份额或产品行为。