子域与泛解析：什么时候该开 `*` 记录
一个域用久了，子域会自然长出来：blog 给博客、api 给接口、img 给图片、staging 给测试。管理这些名字有两种方式，一条条加记录，或者开一条 * 全接住。选错的代价不小：泛解析开得太随意，任何拼错的子域都会打到你的源站；该开的时候不开，每次加服务都要改 DNS。读完这篇，你能按用途判断该用哪种。
子域最终都要落到记录上，类型选择见 50-dns-records-tutorial.md；如果子域要挂到 Workers 或 Pages，路由配置见 55-workers-routes-custom-domain.md。
1. 子域只是记录名前缀
blog.example.com 之所以存在，是因为 DNS 里有一条名字为 blog 的记录。没有记录的子域就是不存在，查询返回 NXDOMAIN 或 NODATA。
规划上建议先定几类固定角色，再考虑泛解析：
| 子域 | 用途 | 记录类型 |
|---|---|---|
www | 主站别名 | CNAME 到根域，或 A |
api | 接口入口 | A / AAAA，通常开代理 |
img、static | 静态资源 | CNAME 到对象存储或 Pages |
staging、dev | 测试环境 | A，通常不开代理 |
mail | 邮件客户端入口 | A，仅 DNS |
命名上避开下划线（_ 在主机名里非法，只有 _dmarc、_acme-challenge 这类特殊记录才用），也别用太长的一串，证书和日志里都不好看。
2. 泛解析的匹配规则
一条 * 记录可以接住所有"没有单独定义"的子域。本机查到的两组对照很能说明问题：
| 查询 | 结果 | 含义 |
|---|---|---|
zz9q-random-test-1234.github.io A | 185.199.108.153、185.199.109.153、185.199.110.153、185.199.111.153 | 存在 * 记录，任意子域都解析 |
zz9q-random-test-1234.cloudflare.com A | 只返回 SOA，没有 A | 没有 * 记录，该子域不存在 |
github.io 是典型的泛解析用法：每个用户拿一个 username.github.io，平台不可能为每个用户预建记录，只能靠 * 接住。cloudflare.com 没开泛解析，所以随便编个子域查不到东西。
规则上有三点要记住：
* 只匹配一级。*.example.com 能匹配 a.example.com，匹配不到 a.b.example.com，后者需要单独一条 *.b.example.com。
显式记录优先。同时存在 blog 和 * 时，blog.example.com 用 blog 那条，* 只兜底没定义的名字。
* 不匹配根域。example.com 本身不受 * 影响，根域记录要单独加。
3. 泛解析适合什么
多租户场景是它的主场：每个客户一个子域（acme.yourapp.com），用户注册后立刻可用，不用等 DNS 生效，也不用调 API 建记录。这类系统里，* 指向一个统一入口，应用层按 Host 头分流。
另一个场景是短链、图床这类"名字无限多"的服务，* 加 Workers 路由就能把所有子域收进同一个 Worker 处理。
不适合的场景同样明确：企业内部服务、按环境划分的子域、需要独立证书的子域。这些名字数量有限且要精确控制，一条条加反而清楚。
4. 泛解析的三个副作用
第一是错误被掩盖。开了 * 之后，拼错的子域也会解析成功，api.exmaple.com 一样能打开，排查时看不到 NXDOMAIN 这种明确信号。
第二是垃圾子域。任何 xxx.example.com 都能访问，攻击者可以用你的域做钓鱼落地页、发垃圾内容的跳转，搜索引擎也可能收录一堆无意义子域。应对办法是在应用层校验 Host，不在白名单里的直接返回 404。
第三是证书覆盖范围。Cloudflare 免费版的 Universal SSL 覆盖根域与一级通配符 *.example.com，再深的 a.b.example.com 不在覆盖内，需要单独申请证书或上 Advanced Certificate Manager。开泛解析之前先确认证书能覆盖到你要用的层级。
5. 在 Cloudflare 上的写法
泛解析记录的名字栏填 *，类型选 A 或 CNAME，值填源站或上游域名。开代理的话，所有匹配到的子域都会走边缘，WAF、缓存、日志对这些子域统一生效。
Workers 路由可以写成 *.example.com/*，把泛解析子域的请求全部交给一个 Worker。这个组合在短链、图床类项目里很常见，具体做法见 97-project-url-shortener.md。
验证方式：
Resolve-DnsName -Name anything.example.com -Type A
Resolve-DnsName -Name deep.anything.example.com -Type A第二条如果查不到，说明只开了一级泛解析，符合预期。
常见问题
泛解析能不能匹配二级子域？
不能，* 只吃一级标签。需要多级时给每一级单独加 *，或者用 NS 把整个子域委派出去。
为什么加了 * 之后 www 还是旧地址？
显式记录的优先级高于 *，www 有自己的记录时 * 不参与。想统一走泛解析，得先删掉 www 那条。
泛解析会影响收信吗？
MX 查询不看 * 的 A 记录，但 mail.example.com 如果有 A 记录被 * 接住，客户端可能连到错误的地址。给邮件入口单独加显式记录。
小结
子域规划的本质是"名字由谁决定"：由你决定，就一条条加记录，控制精确；由用户决定，就开泛解析，把分流交给应用层。两种方式的运维成本完全不同，混用要有明确边界。
泛解析不是省事开关，它把 DNS 层的校验让给了应用层。开了 * 就要在代码里做 Host 白名单，否则拼写错误和恶意子域都会变成你的问题。多域名的重定向策略见 94-multi-domain-redirect.md。
数据来源与检索时间
检索时间 2026-11-10。通配符对照查询为本机实跑。
| 来源 | URL | 对应数据 |
|---|---|---|
| Cloudflare DNS 记录类型 | https://developers.cloudflare.com/dns/manage-dns-records/reference/record-types/ | * 泛解析记录的写法与匹配范围 |
| Cloudflare 通配符 DNS 说明 | https://developers.cloudflare.com/dns/manage-dns-records/how-to/wildcard-dns-records/ | 泛解析只匹配一级、与显式记录的优先级 |
| Cloudflare Universal SSL | https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/ | 免费证书覆盖根域与一级通配符 |
| Workers 路由 | https://developers.cloudflare.com/workers/configuration/routing/routes/ | *.example.com/* 路由写法 |
核验说明
- 实查：随机子域
zz9q-random-test-1234.github.io的 A 记录返回 4 个185.199.x.153地址，证明github.io存在泛解析；随机子域zz9q-random-test-1234.cloudflare.com只返回 SOA、无 A 记录，证明该域未开泛解析。 - 依据文档：
*只匹配一级、显式记录优先、Universal SSL 的覆盖层级、Workers 通配路由写法，均来自 Cloudflare 官方文档，未做实测。 - 未执行：创建泛解析记录、删改
www记录、绑定 Workers 通配路由，本机无 Zone 权限，全部未落地。文中"二级子域查不到"的验证命令未在自有域上跑过。