做安全评估或者资产梳理的时候我听到最多的一个问法就是“这个目标到底有多少个子域名”主域名往往只是门面真正承载业务的、风险最高的是那些散落在各个环境里的子域名——测试站点、管理后台、旧版接口、第三方系统随便漏掉一个都可能是突破口。子域名收集的本质就是把目标组织在互联网上暴露出来的这些边角全部找出来搞清楚暴露面。这篇文章我想把子域名收集和子域名爆破工具背后的原理讲透再把 subfinder、ksubdomain、dnsx 这套常用工具链串成一条可以照着跑的完整流程。无论你是刚接触渗透测试的新手还是要定期做资产盘点、安全自查的从业者按照这条路子走都能把目标看得比之前清楚很多。1. 子域名收集的底层逻辑你其实是在和DNS服务器对话子域名收集看着像是个工具问题——装个工具跑一下就完事了。但工具的每一次查询本质上都是在和DNS服务器“对话”只有把DNS的工作原理摸清楚你才知道工具为什么会漏报、为什么会误报、为什么有的域名明明存在却查不出来。1.1 一次完整的域名解析过程当你在浏览器里输入example.com的时候操作系统并不会直接去问权威DNS服务器而是先找本地配置的递归DNS服务器。递归服务器如果缓存里没有答案就会依次去问根服务器、顶级域服务器最后才轮到负责example.com的权威DNS服务器。权威服务器手里握着所有已配置的DNS记录包括每个子域名的 A 记录、CNAME 记录、MX 记录等。这条链路里最关键的一环就是最后一步。权威DNS服务器对于“存在”的子域名会返回解析结果对于“不存在”的子域名会返回 NXDOMAIN。这两种响应之间的差异就是子域名收集技术最底层的判断依据。无论是拿着字典疯狂爆破还是从第三方数据源里捞域名最终都是在看同一个问题在权威DNS的眼里这个子域名到底存不存在。1.2 被动收集与主动爆破的分工子域名收集方法论上分成两条路线被动和主动。被动收集不接触目标域名的权威服务器而是去利用第三方已经积累的数据比如证书透明日志、搜索引擎缓存的旧快照、历史DNS记录库。这种方式不产生对目标的访问流量隐蔽性最好数据是“捡”来的不是“问”来的。缺点是数据可能有滞后性新上线但还没被任何平台收录的子域名被动方式根本没有办法发现。主动爆破则正好相反。它拿着字典里的一个个前缀admin、api、oa、vpn、test……拼出完整的子域名然后向DNS服务器批量发起解析请求通过观察响应来判断域名是否存在。这种方式的覆盖率高能找出大量被动方式发现不了的“冷门”子域名这也是为什么在安全测试和资产梳理场景里爆破依然是不可替代的一环。但代价也很明显会产生大量DNS查询流量需要对速率、并发、字典质量做精细控制。实战中这两条路线是配合关系不是替代关系。先用被动收集摸清公开可查的资产底数再用主动爆破去补足那些公开数据里没有的“隐藏资产”。2. 被动收集原理不接触目标的“捡漏”艺术被动收集听起来像是“撞运气”其实背后是有成熟数据源支撑的。不同数据源覆盖的信息维度不同组合使用才能拼出一张完整的子域名地图。2.1 证书透明日志最优质的子域名数据源之一证书透明日志Certificate Transparency简称CT是整个被动收集体系里最值得优先用的数据源。它的产生背景是浏览器和CA机构为了公开SSL证书的签发记录要求每一张证书在签发时必须提交到公开的日志服务器上。日志会记录证书里的所有域名字段比如一张证书同时签了login.example.com和www.example.com那这两个子域名都会被写入公开日志。因为CT日志是公开可查询的任何人都可以借助crt.sh、Censys、Cert Spotter 这类平台检索某个主域下所有出现过在证书里的子域名。我最常用的方式是直接查 crt.sh它的页面简洁还支持通配符查询。操作上可以直接在浏览器里打开https://crt.sh/?qexample.com但更实用的是用命令行调接口拉取JSON数据方便后续清洗。CT日志最大的优势是数据可信度高、覆盖面广因为证书签发是真实业务需求驱动的不存在为了“凑数据”而提交的假域名。但也要注意有些子域名虽然签过证书但证书可能已经过期域名可能已经不再指向原服务器所以CT日志的结果一般只能当作“候选名单”不能直接当作最终存活列表。2.2 搜索引擎与DNS情报平台除了CT日志搜索引擎也是被动收集的一把好手。像 Google、Bing 的爬虫会不停抓取网页内容那些被外部服务引用过的子域名比如友情链接、接口地址、资源加载路径都可能被索引。经典语法就是site:example.com它会返回所有被搜索引擎收录的该域名下的页面地址从中可以提取出子域名。DNS情报平台则走了另一条路。它们通过长期监听、协议解析积累了大量的历史DNS查询数据。你可以查到某个子域名过去解析到过哪些IP也可以按IP回查它历史上绑过哪些域名。这类平台里有代表性的包括 SecurityTrails、DNSDB它们适合做更深度的溯源分析而不仅仅是收集子域名。还有一类容易忽略的被动源是证书透明日志的聚合接口和第三方开源情报库比如hackertarget的接口、otx.alienvault的威胁情报库。这些平台会把分散的数据统一整理好调用方只需要按接口查询就行。被动收集阶段数据源的丰富程度直接决定了你能拿到多少“基础弹药”。2.3 被动收集工具的核心逻辑手动去一个个平台查很费时间所以我更推荐直接用工具把数据源聚合起来。subfinder 是我最常用的被动收集工具它的核心逻辑就是内置大量数据源接口包括CT日志、搜索引擎、DNS情报平台、开源威胁情报等然后并行拉取结果统一去重后输出。你可以加-all参数让它调用所有源也可以指定-s单独使用某一个源。工具自动化的意义不只是省时间更在于它能消除单平台查询的盲区。比如只查 crt.sh 会漏掉那些没签过证书的子域名只查搜索引擎会漏掉没被爬虫收录的内容只有把多个源的结果合并在一起才能得到相对完整的子域名集合。数据源类型典型平台/工具优点局限CT日志crt.sh、Censys数据可信、覆盖广可能有已失效证书搜索引擎Google、Bing能发现真实被引用的入口收录不全有延迟DNS历史SecurityTrails、DNSDB可做反查和溯源免费额度有限聚合工具subfinder、amass多源合并、自动去重依赖各源API的可用性3. 主动爆破原理字典与DNS的“暴力对话”如果说被动收集是“捡漏”那主动爆破就是“筛沙子”。自己带上字典把一个个可能的子域名前缀全部试一遍。这一节重点讲清楚爆破过程里最核心的四个问题爆破的请求模型、泛解析判定、字典选择、性能设计。3.1 爆破的本质就是批量DNS查询子域名爆破的原理并不复杂。你先把一个前缀比如api跟主域拼在一起得到api.example.com然后向DNS服务器发起一次解析请求。如果返回了 A 记录或 CNAME 记录说明这个子域名是真实存在的如果返回 NXDOMAIN说明它不存在。爆破就是把字典里的每个词都按这个流程查一遍。这里要注意一个细节爆破时用到的DNS服务器最好是可靠的公共递归DNS比如 8.8.8.8、1.1.1.1或者经过筛选的一套解析器列表。原因在于递归DNS服务器会做缓存如果本地配置的DNS解析过一批冷门域名缓存会让结果失真另外如果你用的是运营商默认的DNS并发太高很容易被限速。实践里我习惯先用一批公共DNS做性能测试选响应速度快、成功率高的那批来扛高并发。爆破结果的质量直接受两个因素影响字典质量和过滤逻辑。字典里没有的词无论如何都发现不了过滤逻辑有问题则会导致大量误报留在结果里。所以很多人抱怨“跑了半天全是不存在的”一查往往是对响应判断的规则写错了。3.2 泛解析检测与判定泛解析是爆破时最容易踩的坑。所谓泛解析就是DNS服务器上配置了一条通配符记录*.example.com意味着任何不存在的子域名都会被解析到同一个IP。面对泛解析的域名爆破工具会陷入“万物皆存在”的疯狂状态——字典里的每一个词都能返回A记录结果毫无意义。所以爆破前必须先做泛解析检测。我的做法是随机生成30到50个完全不可能存在的前缀比如jfksldfajkafble.example.com批量去解析然后观察返回结果。如果所有随机域名都能返回相同IP或者返回一个明显的固定IP集合那基本可以断定目标启用了泛解析。处理泛解析的思路有两种。第一种是直接放弃爆破改走纯被动收集或子域名字典变体分析第二种是爆破后做过滤——把所有解析IP与泛解析返回的模板IP一致的记录全删掉。对批量任务来说第二种方式更实用因为过滤操作可以自动化而且不会误伤那些真实存在、恰好解析到同IP的子域名。3.3 字典怎么选爆破效果差多少字典是爆破工具的“子弹”。没有一套好字典性能再强的工具也是浪费。子域名爆破的字典通常来源于两个方向公开的安全字典项目比如 SecLists 里的subdomains-top1million-5000.txt它从海量真实DNS数据中统计出频率最高的一批子域名前缀另外就是自己维护的常用前缀清单比如dev、beta、admin、api、test、uat、prod、gitlab这类高频业务前缀。字典大小的选择要结合实际场景。5000条字典大概够覆盖常见业务系统的子域名1万到5万条能覆盖更多英文单词组合但耗时和查询量也会线性增加。还要结合目标的地区属性和行业属性做定制比如教育机构通常有lib图书馆、portal门户电商通常有shop、checkout、pay。每次爆破前花10分钟检查一下字典比无脑堆几百万条字典词条效率高出不是一星半点。3.4 高性能爆破背后的设计思路传统工具比如 dnsenum、fierce走的是系统自带的DNS解析函数一条查询只能走“发出请求、等待响应”这样的串行流程网络等待时间都被浪费了所以速度上不去。现代的高性能爆破工具比如 massdns、ksubdomain思考方式完全不一样。它们直接从网卡层面发送和接收UDP数据包不依赖系统库的连接管理。由于UDP本身是无状态协议可以同时发出去成千上万个查询请求再慢慢等响应回来这样一来占用的资源不会随并发数线性上涨。ksubdomain 甚至在设计上更进一步它通过预先设置好源端口和DNS事务ID从响应包中快速匹配对应的查询记录从而做到单机每秒发送数万甚至数十万个查询包。高性能设计给我们的启示是如果你只是想收集子域名没必要手写一套爆破工具直接选带无状态扫描方案的现成工具就好但你要理解它的瓶颈在哪里——通常是网卡出口带宽、DNS服务器的服务能力、以及你自己的公网IP会不会被封。很多爆破任务跑不动不是工具不行而是发起查询的IP已经被目标DNS上层限速甚至封禁了。4. 实操流程从零跑通子域名收集全链路理论讲完直接进入实操。我用一条完整流程演示如何把被动收集、主动爆破、结果验证串起来。这里的目标域统一用example.com举例实际使用请确保对目标拥有合法测试授权。4.1 环境准备与工具安装这套流程用到三个工具subfinder负责被动收集ksubdomain负责高并发主动爆破dnsx负责最终验证和批量解析。它们基本都是Go语言写的安装很方便先在Linux环境里准备好Go环境go version如果没有Go可以根据发行版直接用包管理器装。随后安装工具go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinderlatest go install -v github.com/projectdiscovery/dnsx/cmd/dnsxlatestksubdomain 稍微特别一点它是基于raw socket高性能发包的在Linux下需要root权限macOS和新版Windows上支持度不同建议直接用Linux虚拟机或者服务器来跑。安装方式是从GitHub拉取源码后自行编译git clone https://github.com/knownsec/ksubdomain.git cd ksubdomain go build -o ksubdomain cmd/ksubdomain.go装好之后先用-h参数各自看一下帮助信息确认版本正常。这一步很简单但建议每次装完都做一下避免后面因为PATH路径问题浪费时间。4.2 第一步用 subfinder 做被动收集被动收集阶段不需要碰目标直接运行 subfindersubfinder -d example.com -all -recursive -o subfinder.txt-d指定主域名-all表示调用所有数据源-recursive表示对发现的子域名继续做递归查询意思是对子域名再进行一次被动收集能挖出多层子域比如dev.api.example.com这种层级。-o把结果写入文件。跑完看一下结果文件通常几百行到几千行都有可能。subfinder 已经做了去重但不同源返回的数据格式可能略有差异后续还需要统一清洗。如果某些源需要API Key工具会提示你配置环境变量比如CENSYS_USERNAME和CENSYS_SECRET不配置的话最多只是少几个源的数据不影响整体跑通。4.3 第二步用 ksubdomain 做主动爆破主动爆破前先准备字典。可以下载社区整理好的高频子域名词表wget https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/DNS/subdomains-top1million-5000.txt -O dict.txt然后执行 ksubdomain 爆破sudo ./ksubdomain -d example.com -f dict.txt -o ksub.txt参数含义很直接-d主域-f指定字典-o输出文件。前面建议先用自己的域名或者完全不存在的测试域各跑一次确认工具功能正常、不会因为泛解析域名产生海量误报。ksubdomain 的输出格式比较简洁每一行是一个确认存在的子域名但它默认带上了解析IP所以后面提取域名的时候需要处理一下。这里有一个小技巧先跑一次10到20条的字典观察工具落在当前环境下的实际速率再决定要不要加并发参数。默认参数已经够用不建议一上来就调到最高限制否则容易触发被封IP的风险。4.4 第三步用 dnsx 验证并解析最终存活把被动收集和主动爆破的结果合并、去重然后交给 dnsx 做最终验证cat subfinder.txt ksub.txt | awk {print $1} | sort -u all_domains.txt dnsx -l all_domains.txt -a -resp -silent dnsx_result.txt-l指定输入文件-a请求A记录-resp显示响应内容-silent只输出解析结果和记录值不输出额外的日志。这一步的目的是把前面所有“疑似存在”的域名再批量确认一遍同时拿到每个域名最终解析的IP地址。dnsx 验证完的结果就是一个干净的“子域名解析IP”清单可以直接用于后续的端口扫描、指纹识别、漏洞验证等环节。4.5 第四步结果清洗与资产分类拿到 dnsx 输出后我一般会再做一步人工清洗。要点有三个第一过滤内部IP把所有解析到10.x、172.16.x、192.168.x等内网地址的子域名单独抽出来它们经常是漏网的内网系统入口第二过滤泛解析误报如果之前检测到目标存在泛解析就把解析结果与泛解析模板一致的记录剔除第三按IP段聚类把解析到同一IP段或同一云厂商的子域名归到一起方便判断哪些系统可能是同一套基础设施上的业务。这一步做完一份可用的子域名资产清单才真正成型。前面的所有工具输出都只能叫“候选列表”不能叫“资产清单”。5. 常见问题与排查技巧实录工具跑多了总会遇到各种状况。这里我整理几个高频问题每个都是从实际项目里踩坑踩出来的经验。5.1 泛解析导致的全量误报症状爆破结果动辄几千上万条而且大量域名解析到同一个IP。原因就是目标启用了*.example.com泛解析。解决方案是爆破前先做随机前缀解析测试确认泛解析后要么停止爆破要么在验证阶段将命中IP与泛解析模板IP对比并剔除。我个人比较推荐提前做一个泛解析检测脚本把它做进流程里自动执行而不是等到结果异常了再回溯。5.2 公共DNS限速与超时症状工具跑到一半大量超时结果数量不升反降。公共DNS服务商为了保护自身资源对单一来源IP的查询速率有隐式限制。排查方法第一步把发送速率降下来看是否恢复第二步换一批DNS解析器比如同时配置8.8.8.8、1.1.1.1、9.9.9.9甚至可以维护一份包含几十个速度较快的解析器列表分散压力第三步检查自己的公网IP是否被对方临时封禁如果被封就只能等一段时间恢复或者换出口IP。5.3 结果里堆满了CDN节点症状很多子域名都解析到了知名CDN厂商的IP看起来像是目标资产实际上全是CDN节点。遇到这种情况先不要急着把它们全部删掉。因为CDN只是加速层后面代理的还是真实源站子域名本身依然有价值。处理方式是把这些域名单独归一类标注“CDN托管”在后续端口扫描和指纹识别阶段针对它们的测试策略要区别于直连源站的子域名。直接丢掉会损失信息全盘照收又可能干扰分析分类才是最优解。5.4 跑完发现结果为空症状工具正常运行没报错但输出文件是空的。可能性非常多我按概率排序字典里全是低频前缀目标本来也没配置多少子域名DNS服务器对不存在的域名截断响应导致工具全按“存在”处理然后又因为IP格式不符合被过滤或者泛解析场景下工具误把所有结果过滤掉了。排查思路是先用一个确定存在的子域名比如mail.example.com手动解析一遍确认目标域本身有可被发现的子域名再拿一条简单字典跑确认链路通最后再逐步放大字典规模。5.5 工具误报“存在”但解析不出IP症状爆破阶段显示某子域名存在但 dnsx 验证时解析不到IP。常见原因是爆破阶段使用的是UDP响应的状态而验证阶段使用的是系统DNS解析两者走了不同的网络路径和缓存策略。也可能是子域名是历史解析记录域名虽然曾经存在但现在已经删除了对应的DNS记录。处理方式以最终验证结果为准爆破输出只是“候选结果”不是“最终结果”。6. 几个压箱底的实操心得子域名收集这套流程我在不同规模的资产上跑过很多遍。最后分享几点纯经验层面的东西。第一被动收集不要只看CT日志搜索引擎和历史DNS库的价值往往在你需要溯源的时候才会体现出来数据源尽量都配齐。第二爆破字典宁精勿滥5000条高频子域名词加上所在行业的定制前缀效果经常好过直接上100万条超大字典。第三工具链不是越新越好稳定复现比新鲜功能更重要我直到现在仍然把 subfinder ksubdomain dnsx 作为默认组合就是因为这套组合出问题最少、定位最方便。如果你平时负责大量资产的定期盘点建议把整条链路做成可重复执行的脚本每次跑完自动生成差异对比看新增了哪些子域名、消失了哪些子域名。这样既省人工又不会漏掉新上线的系统。子域名收集不是一个“跑一次就结束”的动作而是一个持续观测的资产发现过程。定期跑、自动对比、及时更新才能真正掌握资产暴露面的变化趋势。