DNS Wildcard 已配置却不匹配子域名：Closest Encloser 与 NXDOMAIN 排查

先查询权威服务器

分别向每台权威 NS 查询失败名称的 A/AAAA/CNAME，并保存状态码、Answer、Authority、AA 标志和 SOA。递归解析器可能缓存了旧的正/负答案，不能仅凭本地 nslookup 判断通配规则。

同时查询通配符所在节点、失败名称的每一级父名称，以及期望的终端记录。不要向 DNS 直接查询字面量 * 后就认为所有合成场景都已验证。

Wildcard 不是任意层级 glob

*.example.com 的星号只占一个完整 DNS label。它可以为某些不存在名称合成答案，但不是编程语言中的 **，不会无条件覆盖所有深层后代。是否匹配 a.b.example.com 取决于 DNS 树中哪些祖先节点已存在。

若产品需要多级随机子域名，不能只假设一条 apex 下 wildcard 永远有效。应按实际树结构测试，并在必要层级配置相应 wildcard。

Closest Encloser 是什么

对查询名而言，closest encloser 是区域中确实存在、且最接近查询名的祖先名称。权威服务器基于它寻找 *.<closest-encloser> 作为合成来源。只要中间节点存在，closest encloser 就会改变。

例如 b.example.com 因任何记录而成为现有节点后，查询 x.b.example.com 的 closest encloser 可能是 b.example.com，此时服务器寻找 *.b.example.com，而不是退回 *.example.com。

显式节点会遮断上级 Wildcard

一旦查询名自身存在，不论是否有请求的记录类型，都不会用上级 wildcard为同名合成。例如 foo.example.com 有 TXT但没有 A，查询 A 可能得到 NODATA，而不是使用 *.example.com A。

这不是记录优先级错误，而是 DNS 名称存在性规则。逐类型查询该节点，确认是否有 TXT、MX、CAA、NS 或其他记录让名称已经存在。

空非终端节点也算存在

一个名称自身没有 RRset，但它有更深的子名称时，会成为 empty non-terminal。比如存在 host.branch.example.com，那么 branch.example.com 在 DNS 树中存在，即使没有直接记录。它也会影响 closest encloser 和 wildcard 合成。

管理控制台可能不显示空非终端节点。需要根据区域内所有 owner name 构建树，或查询其子名称证明。不要只搜索是否有一行 branch 记录。

Wildcard 不覆盖区域顶点

*.example.com 不匹配 example.com 本身。区域顶点必须有 SOA、NS，并按需要显式配置 A/AAAA 或供应商支持的 apex 别名功能。

若裸域不解析而 www 正常，不要继续调整 wildcard TTL。直接查询 apex 权威答案并配置适当记录，同时遵守 CNAME 不能与顶点必需数据共存的规则。

委派会形成区域边界

如果 sub.example.com 被 NS 委派到另一个权威区域，父区的 *.example.com 不会越过 zone cut 为子区名称回答。需要在子区权威中配置所需记录或 wildcard。

从父区查询 NS 和 DS，确认实际委派；再直接查询子区权威。不要在父区增加更多 wildcard 试图覆盖一个已经委派的子域。

Delegation 与普通 NS 数据

区域内非顶点名称出现 NS RRset 通常建立委派。配置界面中误加 NS 可能把一个名称意外变成 zone cut，导致父区其他数据和 wildcard 不再按预期使用。

检查 Authority section 和追踪路径。若委派是误配置，移除前先确认没有真实子区依赖，并按变更流程处理 Glue 和 DS。

CNAME Wildcard 的限制

Wildcard owner 可以有 CNAME，但同一名称不能再与普通其他数据共存。合成后，解析还要继续跟随 CNAME 目标；目标 NXDOMAIN、循环或委派失败会让结果异常。

排障时把“通配符是否合成 CNAME”和“CNAME 目标是否成功解析”分成两步。第一跳存在不代表最终 A/AAAA 成功。

NXDOMAIN 与 NODATA

NXDOMAIN 表示名称不存在；NODATA 表示名称存在但没有所查类型。显式节点阻止 wildcard 后，常出现 NODATA。客户端把两者都显示为“找不到域名”会隐藏根因。

查看 RCODE、Authority 中 SOA 和其他类型查询。修复策略不同：NODATA 要补所需 RRset 或调整现有节点设计，NXDOMAIN 才继续检查 wildcard 合成和 DNS 树。

NXDOMAIN Cut 的影响

验证来自权威来源的 NXDOMAIN 后，递归解析器可推断其下方名称也不存在。错误权威配置或旧负缓存因而可能影响多个后代。新增 wildcard 后，递归缓存仍可能短期返回旧 NXDOMAIN。

检查 SOA 中与负缓存相关的 TTL，并直接查询权威确认新答案。不要因某公共递归尚未过期就反复改区域数据。

多个权威节点不同步

如果一台权威加载了新 wildcard，另一台仍是旧 serial，递归查询会随机成功或失败。比较所有 NS 的 SOA serial、wildcard RRset 和失败名称答案。

修复区域传送、发布流水线或 Anycast 节点一致性后再等待缓存。只验证控制面板“已保存”不能证明所有权威已发布。

DNSSEC 与 Wildcard 证明

DNSSEC 签名区域需要用 NSEC/NSEC3 等证明 wildcard 合成与名称不存在的关系。签名或否定证明错误时，验证型递归可能返回 SERVFAIL，而不验证的查询看似正常。

比较带验证的递归和权威原始响应，定位 RRSIG、NSEC/NSEC3、DS/DNSKEY。不要关闭 DNSSEC 验证作为长期修复，应重新签名并确认父区 DS 一致。

应用层证书仍是独立问题

DNS wildcard A/CNAME 成功只解决名称解析。HTTPS 还需要证书覆盖对应名称。证书 *.example.com 通常也只覆盖一个 label，不会自动覆盖 a.b.example.com。

把 DNS 和 TLS 分开验收：先验证权威 DNS，再检查证书 SAN、SNI 和反向代理虚拟主机。不要把浏览器证书错误误判为 wildcard DNS 未命中。

Split DNS 与 View

内外网权威 View 可能有不同区域树和 wildcard。公司网络内正常、公共网络失败，或反之，应分别记录使用的递归与最终权威。

确保两套 View 都包含所需显式节点、委派和 wildcard，并检查客户端 VPN/DoH 是否绕到另一视图。不要复制整个区域前先评估内部名称泄露。

一套逐层排查流程

第一步，固定失败 FQDN 和记录类型。第二步，直查每台权威。第三步，区分 NXDOMAIN 与 NODATA。第四步，列出从查询名到 zone apex 的存在节点。第五步，确定 closest encloser 与期望 * 节点。第六步，检查委派/empty non-terminal。第七步，验证 CNAME 终点和 DNSSEC。第八步，等待负缓存并检查所有权威一致。

修复后测试 apex、单层随机名、多层随机名、显式节点、只有 TXT 的节点、empty non-terminal、委派子区和不存在名称。每个场景都应对 A、AAAA、CNAME 和 DNSSEC 验证给出明确预期。

常见错误

常见误区包括：把 wildcard 当 **；认为显式 TXT 不影响 A；忽略空非终端节点；用 wildcard 覆盖 apex；父区 wildcard 跨越委派；只查一台权威；混淆 NXDOMAIN/NODATA；新增记录后忽略负缓存；以及 DNS 正常后忽略证书只覆盖一层。

常见问题

`*.example.com` 能匹配 `a.b.example.com` 吗？

不能按字符串 glob 简单判断。要看 closest encloser 和 *.b.example.com 等节点是否存在；中间名称存在时，上级 wildcard 不会自动回退匹配。

为什么加一条 TXT 后 A 不再使用 wildcard？

该名称已经存在，查询缺少的 A 会是 NODATA，而不是从 wildcard 合成。需要显式添加 A/CNAME 或重新设计记录位置。

Wildcard 能让裸域 example.com 解析吗？

不能。区域顶点必须显式配置合适记录或使用 DNS 提供商支持的 apex 别名能力。

为什么权威已正常，公共 DNS 仍 NXDOMAIN？

递归解析器可能缓存了旧否定响应。检查 SOA 负缓存 TTL和所有权威一致性，等待到期或在受控解析器刷新。

DNS Wildcard 和通配符证书覆盖范围一样吗？

它们是不同机制，但常见证书 *.example.com 同样只覆盖一个标签。DNS 解析成功不证明 TLS 证书覆盖深层子域。

总结

DNS Wildcard 的命中由 DNS 名称树而不是字符串模式决定。可靠排障要找到 closest encloser，识别显式节点、empty non-terminal、zone apex 与 delegation，再区分 NXDOMAIN 和 NODATA。通过权威直查、所有 NS 一致性、负缓存和 DNSSEC 验证，可以解释“部分子域名不匹配”，而不会靠堆叠更多星号制造新冲突。

来源资料

• RFC Editor, RFC 4592 — The Role of Wildcards in the DNS: https://www.rfc-editor.org/rfc/rfc4592
• RFC Editor, RFC 1034 — Domain Names: Concepts and Facilities: https://www.rfc-editor.org/rfc/rfc1034
• RFC Editor, RFC 8020 — NXDOMAIN: There Really Is Nothing Underneath: https://www.rfc-editor.org/rfc/rfc8020
• RFC Editor, RFC 2308 — Negative Caching of DNS Queries: https://www.rfc-editor.org/rfc/rfc2308