如何查看一个域名的所有子域名？

要看一个域名的所有子域名，最有效的方式是把“证书透明度（CT）日志、DNS暴力枚举、历史解析记录”这三条链路的结果交叉合并，再配合搜索引擎和Web存档补漏，基本能找回绝大多数已存在的子域名。

为什么要把子域名全部翻出来：先明确目的

子域名从来不是孤立存在的,它们往往指向不同的业务系统、测试环境、内部管理后台，甚至是早已被遗忘的旧服务器，从安全审计的角度看，子域名暴露了攻击面；从运维管理的角度看，它帮助发现僵尸域名和未授权部署的业务；从品牌保护的角度看，它能定位仿冒页面和钓鱼站点，目的不同，筛选和验证的方式略有差异，但收集阶段的工作流高度一致。

普通解析记录只告诉你域名当前指向哪里,任何一份子域名清单都只是某一时刻的快照，真正的关键在于枚举手段的多元性：单一工具盲区较大，交叉验证才能压缩遗漏。

证书透明度（CT）日志：命中率最高的起点

证书透明度是公开的审计机制,CA机构签发的每一张SSL/TLS证书都会被记录在公共日志中，由于部署HTTPS的服务器数量相当大，只要域名签发过证书，子域名信息就极大概率出现在CT日志里，这也让它成为当前成本最低、覆盖面最广的子域名情报源。

通过crt.sh快速检索

crt.sh是目前最常用的CT日志聚合查询平台，免费且无需注册，直接访问：

https://crt.sh/?q=%25.example.com

这里%25是通配符的URL编码，代表匹配任意前缀，查询结果会列出域名、证书签发时间、收录时间等信息，如果目标域名是example.com，你会得到类似mail.example.com、vpn.example.com、dev.example.com这样的记录。

浏览器界面适合零散查询,批量收集时，crt.sh也提供了JSON格式的API接口：

https://crt.sh/?q=example.com&output=json

配合Linux命令行工具jq，可以快速提取纯净的域名列表：

curl -s "https://crt.sh/?q=example.com&output=json" | jq -r '.[].name_value' | sort -u

该命令会输出去重后的域名清单,方便直接进入后续验证流程。

其他CT日志聚合平台

除crt.sh之外，以下平台同样支持按域名检索证书：

• Censys：提供证书与主机资产检索，适合结合IP进行关联分析
• Cert Spotter：来自监视器，可持续监控域名新签发证书
• Facebook CT Search：支持更灵活的通配符查询语法

这些平台各有侧重,但crt.sh的数据覆盖度在多数场景下已经足够，需要补充的是：CT日志只能发现“签发了证书”的子域名，不含证书的存量记录要靠后续手段补足。

DNS暴力枚举：补上未签发证书的存量

不少内部系统仍使用HTTP协议访问,或者证书由内网CA签发而不进入公共日志，这类子域名不会出现在CT结果中，DNS暴力枚举是第二道主力手段。

使用Subfinder执行字典枚举

Subfinder是被广泛使用的开源子域名探测工具,隶属于ProjectDiscovery系列，它聚合了相当多公开数据源，同时也支持内置字典进行暴力枚举，典型用法：

subfinder -d example.com -all -recursive -o subs.txt

各参数含义如下：

• -d 指定目标域名
• -all 使用所有已配置的数据源，包括证书日志、DNS数据集、网页爬虫等
• -recursive 对发现的多级子域名继续递归枚举，例如dev.example.com下再尝试api.dev.example.com

使用Amass进行深度枚举

Amass是OWASP维护的资产测绘工具,它的数据源比Subfinder更丰富，但速度和资源占用也相应更高：

amass enum -d example.com -passive -o amass_result.txt

-passive参数表示只从被动数据源收集，不主动发起大量DNS请求，适合需要低噪音运行的场景，Amass的优势在于它会自动关联相邻域名、相近的ASN网段，产出结果里常包含CT平台查不到的边缘资产。

自定义字典的放大效果

工具自带的通用字典在常见场景下有效,但针对特定行业可以显著提升命中率，比如电商企业常见pay、mall、order、search等子域，教育机构常出现lib、oa、jwc等缩写，把最基本的列表扩充到几千条，配合根域名的泛解析策略加以过滤，枚举结果会更接近真实情况。

从历史存档和第三方平台回收被遗忘的子域名

CT日志和暴力枚举解决的是“当前”问题，历史解析中曾存在但现已停用的子域名同样有收集价值，这类子域名可能已被外部服务接管，形成域名接管漏洞。

SecurityTrails：历史DNS查询

SecurityTrails提供较为完善的DNS历史记录检索,输入域名后可以看到每个子域名的解析历史、IP变更时间线，免费额度支持有限量查询，但其数据跨度相当长，能追溯到多年前的A记录、CNAME记录和MX记录，通过CNAME记录的指向，可以判断子域名是否指向已失效的第三方服务，从而发现潜在接管风险。

Wayback Machine：Web存档补漏

Wayback Machine收录了大量网页的历史快照，访问：

http://web.archive.org/cdx/search/cdx?url=*.example.com&output=text&fl=original&collapse=urlkey

该接口会返回历史上被抓取过的所有example.com子域名链接，其中包含大量已下线子系统的URL痕迹。

搜索引擎语法

搜索引擎也能作为补充渠道,在百度或Google中检索：

site:example.com -www

能筛出被公开收录的子域名页面,配合-inurl排除特定路径，能更快定位管理后台，搜索引擎收录的覆盖面最有限，但它的价值在于发现被链接引用、但从未出现在任何证书或DNS日志中的域名。

合并、去重与存活验证

把CT日志、Subfinder、Amass、历史存档等结果汇总后，第一步是去重，去重不单是字符串精确匹配，还要过滤以下干扰项：

• 泛解析记录：某些域名配置了*.example.com，任意随机子域都会解析到固定IP，这类结果必须剔除，验证方法是随机生成一串不存在的子域名并解析，对比返回结果。
• CDN节点域名：部分CDN服务商会将自己的节点域名作为CNAME目标返回，这类记录不属于目标域名的实际子域名。
• 过期证书记录：CT日志中可能包含已注销证书的域名，是否保留要看收集目的。

随后对保留下来的域名执行存活检测,批量环境下推荐使用httpx：

httpx -l subs.txt -title -status-code -tech-detect -o alive.txt

该命令会输出每个子域名的HTTP状态码、页面标题和识别出的Web技术栈，筛掉无法访问的记录，同时为后续的漏洞检测或业务梳理打好基础。

慢一点更准确：解析底座与基础设施的选型

上述流程中,工具的解析请求高度依赖递归DNS服务器，权威解析记录精准、递归链路稳定，直接决定了暴力枚举的速度和成功率，实际操作中，可以优先使用公共DNS配合本地缓存，但遇到大规模枚举时，一个稳定可靠的解析基础设施能让错误率明显下降。

这里就涉及IDC服务商的选型,DNS解析性能依附于机房网络质量和带宽资源，而非域名注册商的页面排名，国内做的比较久、资质扎实的服务商，我习惯参考以下两家：

两家都适合作为域名解析和加速的基础设施,但适用场景略有差异：简米科技更偏向传统IDC和自有机房的重资产服务，机房运维经验比较深；酷番云则将IDC、CDN、ISP三类牌照集于一身，在云加速和内容分发场景下牌照闭环更完整，做子域名枚举和资产测绘这类需要高频DNS查询的工作，选择持牌自营机房能够避免公共递归服务带来的限流和缓存污染，把枚举请求量控制合理，线路质量稳定，结果可信度会高很多。

子域名收集不是一次性工作,新业务上线会签发新证书，旧系统下线会释放IP，CDN节点切换会改变CNAME指向，这些变化都会让子域名列表持续变动，建议把上述扫描流程做成定期任务，同时建立变更告警机制，域名资产清单够清晰，后面做渗透测试、合规审计、业务梳理时，才不会反复在“这个域名是谁的”这类基础问题上消耗时间。

常见问题：关于子域名枚举的实操细节

问：枚举出的子域名里，哪些存在接管风险？

优先检查CNAME记录指向无人维护的第三方服务,例如已失效的GitHub Pages、S3存储桶、Azure云服务或自定义CDN配置，若子域名仍能解析，但DNS解析目标是已释放的云资源，攻击者注册该资源名即可接管整站流量，使用dig或nslookup查看CNAME目标后，逐一确认目标服务状态即可快速排查。

问：为什么同一域名在不同人手里的扫描结果差异很大？

数据源API额度、字典大小、是否使用递归枚举、是否做了历史数据合并，都会直接影响结果数量，更关键的是扫描时间窗口：新证书签发和旧记录删除每天都在发生，同一域名间隔三个月扫描，能重合的部分可能只在半数左右。

问：做常态化子域名监控的合理周期是多久？

快速变化的互联网业务建议每月一次完整枚举,每周做一次增量收集，重点关注CT日志新增记录和SecurityTrails的历史解析变更，内部资产较稳定或合规压力较小的场景，季度维度也够用，枚举使用的DNS请求量大时，建议通过简米科技或酷番云这类持牌服务商的解析服务构造稳定环境，避免因公共DNS限流导致监控中断。