子域梳理思路
子域梳理的目的是找出主域名之下所有可访问的资产，因为很多风险藏在被遗忘的测试域名、遗留系统与内部系统的对外入口上。做法上优先使用被动源：证书透明度日志、公开数据集、历史 DNS 记录都能提供大量候选子域，且完全不触碰目标；随后用低频字典做解析验证，确认哪些真正存活、解析到什么地址、用途是什么。海量子域里往往夹杂大量遗留与第三方托管域名，先标注用途再决定测试优先级。最终产出是一份存活子域清单，附带用途与归属标注。
基本信息
| 被动来源 | 证书透明度日志、公开数据集、历史 DNS 记录 |
|---|---|
| 主动方式 | 低频字典解析验证（需限速与窗口） |
| 产出 | 存活子域清单 + 用途标注 + 归属核对 |
| 优先级 | 业务系统优先，其次测试遗留系统 |
| 边界 | 第三方 SaaS 子域不属测试目标，需先确认归属 |
典型使用场景
- 攻击面清点：找出主域名之外所有对外可访问的资产
- 遗留系统发现：test、dev、old、beta 类命名常指向被遗忘的系统
- 归属核对：区分自有子域与第三方托管（CDN、SaaS）子域
- 变更监测：定期梳理能发现新上线但未纳入台账的系统
- 台账补全：为资产管理提供实测清单
梳理步骤
梳理步骤
1. 汇总被动来源的子域列表（证书日志、公开数据集）
2. 去重并与客户台账比对，标注新增项
3. 抽样解析确认存活（低频、限速）
4. 标注用途：业务、测试、遗留、第三方托管
5. 归属存疑的先暂缓，上报确认后再处理命名模式与含义
| 命名模式 | 常见含义 | 处理建议 |
|---|---|---|
| www 或 api 或 app | 主站与业务接口 | 优先纳入测试范围 |
| test 或 dev 或 uat | 测试与预发环境 | 确认是否在范围内，注意数据敏感性 |
| old 或 legacy 或 bak | 遗留系统 | 重点核查，常缺维护与补丁 |
| cdn 或 static 或 img | 静态资源与 CDN | 注意 CNAME 指向第三方 |
| vpn 或 mail 或 oa | 内部系统入口 | 确认归属后再定 |
海量子域中大量是遗留或测试系统，先标注用途再决定测试优先级；数量异常时优先抽样确认，而不是逐个深挖。
高并发字典解析容易触发 DNS 限流甚至被上游封禁，应控制在低频并分散时间；把第三方 SaaS 子域当测试目标属于越界。