泛解析与多子域名批量管理

当你的业务需要成百上千个子域名——例如 SaaS 给每个租户分配 tenant-a.example.com、tenant-b.example.com——手工一条条加 DNS 记录既慢又容易出错。泛解析(Wildcard DNS) 和 批量管理 就是为这类场景准备的。

什么是泛解析

泛解析是一条以星号开头的记录,例如:

*.example.com.  IN  A      203.0.113.10
*.example.com.  IN  CNAME  edge.example.com.

它的含义是:任何没有被精确定义的子域名,都会命中这条记录。a.example.com、x.y.example.com、随手编的 foobar.example.com 都会解析到同一个目标。这让「先注册用户、再实时给它一个可访问的二级域名」成为可能,无需为每个租户改动 DNS。

匹配优先级:精确记录优先

这是最容易被误解的一点。精确记录永远优先于泛解析:

• 已定义 mail.example.com → 198.51.100.5
• 同时存在 .example.com → 203.0.113.10

那么 mail.example.com 走 198.51.100.5,只有其余未定义的子域才落到泛解析上。此外, 通常只匹配一层标签,不同解析器对多级 ..example.com 的支持并不一致,不要依赖这种写法。

风险与取舍

泛解析很方便,但它「有求必应」,会带来副作用:

• 误导流量与钓鱼面:任意拼写的子域都能解析成功,可能被人拿 login.example.com 之类做钓鱼,也会掩盖前端的拼写错误(本该 404 的域名却「通了」)。
• 证书问题:泛解析出的子域要跑 HTTPS,需要 通配符证书(.example.com),而通配符证书通常只覆盖一层,a.b.example.com 不在其内;签发需用 DNS-01 校验。
• 难以审计:因为没有逐条记录,你无法从 DNS 里「列出」当前真实在用的子域,监控与资产盘点会失真。

多子域名的批量管理建议

即使用了泛解析,规范化管理仍不可少:

• 命名规范:约定统一格式,如 <租户>.app.example.com、api-<env>.example.com,避免语义冲突,也方便正则匹配与清理。
• 用 API 批量操作:通过 DNS 服务商的 API 或 IaC(把记录写成代码)批量增删改,保证可复现、可回滚,远胜手工点控制台。
• 通配符证书 + 自动化续期:用 ACME/DNS-01 自动签发续期 .example.com,避免逐域申请。
• 精确记录兜底关键子域:www、mail、api 等重要域名显式定义,不要「交给泛解析」,以免解析目标漂移。

何时该用 / 不该用泛解析

适合:租户数量多且动态增长、子域内容同质(都指向同一套接入层)、需要「即开即用」的多租户 SaaS。

不适合:子域各自指向不同后端、需要精细访问控制或审计、对安全边界敏感的场景——此时应逐条精确定义,或用自动化脚本按需创建真实记录。

小结

泛解析用一条 记录兜住所有未定义子域,是多租户 SaaS 的利器;但要记住三条边界:精确记录优先于泛解析、HTTPS 需要通配符证书且只覆盖一层、泛解析会放大误导流量并削弱可审计性。日常管理靠命名规范 + API/IaC 批量操作 + 关键子域精确兜底。子域同质且动态增长就用泛解析,异构或需强管控就逐条精确定义。