---
purpose: 通配符证书的子域名盘点路径（禁止猜测枚举，必须走 WHOIS → DNS Zone）
loaded_by: SKILL.md §3 Phase 1 · 发现通配符证书时按需引用
blocking: true
---

# 通配符证书子域名盘点规则

> **核心教训**：发现通配符证书后，**禁止用猜测/枚举子域名的方式**探测绑定点。
> 正确路径是通过 WHOIS 找到权威 NS，再引导客户提供完整 DNS Zone 记录。

---

## 1. 错误路径（禁止）

```
❌ 发现 *.example.com 通配符证书
    ↓
❌ 猜测 www / api / m / app / login 等常见子域名
    ↓
❌ 逐个 dig 探测，以"有 A 记录"判断绑定点
```

**为什么禁止**：

- 猜测的子域名集合**严重不完整**，会漏掉真实存在的子域名（如 `n1` / `pre` / `w` 等业务自定义名称）
- 即使 CT 日志有历史记录，也只能反映**曾经签发过证书的子域名**，不代表当前 DNS 全貌
- 不同子域名可能走**完全不同的线路**（国内 CDN / 海外直连 / 不同云厂商），猜测无法覆盖

---

## 2. 正确路径（强制三步）

```
✅ 发现通配符证书
    ↓
✅ Step A：WHOIS 查权威 NS
    whois <apex-domain> → 找到 Name Server 字段
    ↓
✅ Step B：判断 DNS 平台类型
    ├─ 公共 DNS 平台（DNSPod / 阿里云 DNS / Cloudflare / Route53 等）
    │     → 引导客户：「请在 DNS 控制台导出完整 Zone 记录（或提供只读 API Token）」
    │     → 或询问：「能否提供 DNS 平台的只读 API Key？我直接拉取」
    └─ 自建 NS（如 uugame.com / 企业内部 BIND 等）
          → 引导客户：「请联系 DNS 运维导出 Zone 文件（AXFR 或手动导出）」
          → 或询问：「能否提供 AXFR 权限或 Zone 文件？」
    ↓
✅ Step C：基于完整 DNS Zone 记录盘点
    - 找出所有解析到不同 IP / CNAME 的子域名
    - 按线路分组（国内 CDN / 海外直连 / 源站等）
    - 每组确认证书绑定点和部署方式
```

---

## 3. CT 日志的正确定位

```
CT 日志  = 辅助参考（历史曾签发过哪些子域名）
DNS Zone = 权威来源（当前实际有哪些子域名在用）

CT 日志可用于：
  ✅ 发现 DNS Zone 中可能遗漏的历史子域名（提示客户确认是否已下线）
  ✅ 了解历史 CA 使用情况
  ❌ 不能替代 DNS Zone 作为当前绑定点的权威来源
```

---

## 4. 海外线路盲区处理

```
本机在国内时，dig 结果是国内 DNS 视角，海外线路可能走不同 CNAME / IP。

处理方式：
  ✅ 直接问客户：「是否有海外线路？如有，海外是否走不同 CDN 或直连 IP？」
  ✅ 或请客户提供完整 DNS Zone（含 GeoDNS / 分线路配置）
  ❌ 不要假设国内和海外走同一线路
```

---

## 5. Agent 硬边界

```
✅ 必须做：
- 发现通配符证书的第一反应是 WHOIS，不是 dig 子域
- 引导客户提供完整 DNS Zone 或只读 API Token
- 主动询问海外线路情况
- CT 日志仅作辅助，不作权威来源

❌ 严禁做：
- 猜测常见子域名（www/api/m/app/login...）并逐个 dig 探测
- 把 CT 日志中的 FQDN 列表当作完整子域清单
- 假设国内外走同一线路
```

---

## 6. 自检对应项

本文件的规则落到自检清单的 **G14 基础设施拓扑识别 + 通配符证书子域名盘点自检**，
见 `review-guides/self-review-checklist.md` G14 条目。