你以为自己只维护一个网站，DNS、证书日志和旧项目却可能告诉你另一件事：api、staging、old、mail 甚至几年前活动页留下的入口，仍然可能在公开世界里留下痕迹。子域名发现工具适合做一次有边界的资产盘点：输入自己拥有或明确获授权的主域名，选择 DNS 枚举和证书透明度线索，观察哪些名称能解析、哪些入口能响应，再把结果交给真正的系统负责人确认。它能帮你把“我们是不是漏了什么”变成一张可讨论的清单，但不会自动证明某个入口存在漏洞，也不能替代授权、安全测试或后台资产台账。
为什么明明只有一个官网，还要盘点子域名
网站首页往往只是最容易被看见的入口。业务接口可能在 api.example.com，后台在 admin.example.com，静态资源走 cdn.example.com，测试环境则藏在 staging.example.com。这些入口不一定都由同一个团队维护，也不一定都有相同的登录、证书、监控和下线流程。资产盘点的第一价值，不是“找到越多越好”，而是知道每个公开名称对应什么用途、谁负责、是否仍然需要存在。
子域名也不等于 DNS 记录。一个名字出现在证书透明度日志里，说明它曾经出现在公开证书的名称字段中；它现在可能已经下线。一个名字有 A 记录，也不代表 HTTP 服务一定正常；它可能只是邮件、内部转发或其他协议入口。相反，一个 HTTP 页面能打开，也不代表你已经掌握了它背后的真实资产。把发现、解析、访问和归属分开，后面的判断才不会混乱。
两类线索分别告诉你什么
| 能力 | 免费版 | Pro |
|---|---|---|
| DNS 枚举 | 查询内置常见名称是否有 IPv4 解析 | 发现当前仍能解析的常见入口 |
| 证书透明度 | 从公开证书名称中提取候选子域名 | 补充历史或不在常见字典中的线索 |
| HTTP 探测 | 尝试 HTTPS，失败后再尝试 HTTP | 查看状态码、标题、响应时间和部分技术特征 |
| 搜索引擎与被动收集 | 页面标注为即将推出 | 当前不应当把它们当成已完成能力 |
DNS 枚举是一个朴素但有用的起点。工具会对内置的常见名称集合进行解析，例如 www、mail、api、dev、staging、cdn、docs、git 等。它擅长发现“名称符合常见习惯、现在还有解析”的入口，但不会遍历整个域名空间，也不能保证找到所有自定义命名的子域名。
证书透明度是另一条视角。公开 CA 签发的证书会留下可查询的日志，工具从日志中的名称字段提取候选子域名，再对一部分候选做 DNS 和 HTTP 验证。它可能发现一个团队从未写进资产表的旧入口，也可能返回已下线、改名或只在历史证书中出现的名称。这里的关键词是“线索”，不是“当前资产已确认”。
一次可靠的盘点，建议按这 5 步走
- 1输入主域名并选择可用来源先使用主域名，不要把
https://、路径或查询参数一起粘贴。首次盘点可以选择 DNS 枚举和证书透明度；页面中标注“即将推出”的来源目前不会产生真实结果。 - 2等待结果，不要把进度条当成完整度查询会经历 DNS、证书日志和 HTTP 检查，耗时受目标响应、外部服务和网络影响。进度条表示当前页面的处理过程，不表示已经覆盖了主域名下所有名称。
- 3先看名称、来源和解析地址把结果按子域名、来源、IP 和状态整理。相同名称可能被多个来源发现，页面会按子域名去重；去重后的列表更适合初步盘点，但不要因此丢掉来源证据。
- 4逐项确认业务归属和必要性联系 DNS、运维、研发、邮件或业务负责人，确认每个名称的用途、所有者、环境、是否仍在使用，以及是否应该从公网开放。
- 5对重要入口做第二次核查对 API、登录、后台、测试环境和邮件入口，分别用 DNS 查询工具、SSL 证书检查工具 或实际项目监控复核，不要只凭一张发现表做结论。
结果里的字段，应该怎么读
状态是“可访问”，不是“安全”
当前工具会尝试 HTTPS，失败后尝试 HTTP，并记录响应状态码、页面标题、响应时间、是否使用 HTTPS 和部分技术特征。这里的“活跃”主要表示解析后能够继续完成一定的 HTTP 检查；它不等于页面没有漏洞、不等于登录保护正确，也不等于后端服务没有暴露敏感信息。一个返回 403 的管理后台，可能正是配置正常的结果；一个返回 200 的测试页，也可能需要负责人立即确认。
IP 地址要结合 CDN、负载均衡和历史记录
同一子域名可能返回多个地址，不同网络和时间也可能得到不同结果。地址落在 CDN、云负载均衡或共享托管网络上时，不能只凭 IP 反推唯一业务归属。工具展示的地理位置来自外部 IP 地理位置服务，服务失败时会显示未知；它适合做粗略线索，不适合当作服务器实际位置、数据存储位置或合规结论。
技术栈识别只能当作提示
页面会从响应头和 HTML 内容中尝试识别 Nginx、Apache、Cloudflare、WordPress、React、Vue 等特征。响应头可能被代理改写，页面也可能没有明显标记，所以“未识别”不代表没有使用某项技术，“识别到”也不代表版本准确。把技术栈列当作后续核查入口就好，不要把它直接写成漏洞报告。
迁移后发现一个不认识的 staging 子域名
staging.example.com 仍然有 DNS 解析并返回测试页面。大家第一反应是马上删记录，但删除前还缺少归属和回滚信息。- 1.先把来源、IP、状态码、页面标题、证书状态和检查时间复制到变更工单，不要只截一张图。
- 2.联系研发和发布负责人确认它是否仍用于验收、回滚或第三方回调，并检查是否存在登录保护和敏感数据。
- 3.确认不再使用后，再按变更流程处理 DNS、CDN、证书和部署配置；完成后重新查询，避免只删了 DNS 却留下其他入口。
最常见的 6 个误判
- 把结果数量当成盘点完整度：工具使用常见名称和证书线索，不是全量 DNS 数据库；数量少不代表资产少。
- 把证书日志当成实时清单：证书透明度记录可能来自历史证书，必须重新解析并核对当前负责人。
- 只看 HTTP 200：301、403、404、超时各自代表不同线索，不能用一个状态码替代业务判断。
- 看到 IP 就认定是源站：CDN、反向代理和共享服务会让 IP 与真实应用边界不一致。
- 把技术栈识别写成版本结论：响应头和页面特征可能不完整，只能作为待核查提示。
- 没有授权就继续探测：发现工具不是绕过权限的工具，尤其不要对陌生目标做连续或扩大范围的测试。
怎样把结果交给同事，而不是制造一张没人看的表
资产表真正难的不是列字段，而是让下一位接手的人知道下一步是什么。建议至少保留：主域名、子域名、发现来源、首次或本次检查时间、IP、HTTP 状态、页面标题、HTTPS 情况、技术栈提示、业务用途、负责人、环境和处理状态。工具的导出功能适合把当前结果带走，但业务字段仍然需要你在台账或工单里补齐。
如果要分享结果，先检查 URL、页面标题和导出文件里有没有内部域名、测试地址、客户名称或其他不应公开的信息。公开分享链接很方便，但方便不等于适合所有材料。对外沟通时可以只保留脱敏后的名称和结论；对内交接则保留原始结果，并注明检查时间和授权范围。
发现之后，下一步用什么工具
子域名发现适合做“找入口”，后续动作要按问题类型拆开。解析异常时，用 DNS 查询工具查看 A、AAAA、CNAME、MX、NS 和 TXT；HTTPS 报错时，用 SSL 证书检查工具核对证书、域名匹配和 TLS 线索；入口数量已经确认、需要检查页面内部链接时，再用 网站链接检查工具做下一层排查。不要把所有问题都归到“子域名扫描结果”里，分层处理更容易找到真正负责的人。