子域名网址查询

子域名网址查询，域名说白了就是网址通过一个已知的主域名，去挖掘它下面挂着的查询所有二级甚至三级域名。这事儿在网络安全圈里是域名基本功，但多数人压根没意识到自己每天都在用——你访问的网址`mail.google.com`、`drive.google.com`，查询本质上都是域名`google.com`的子域名。 我见过太多人把精力花在爆破路径上，网址却忽略了子域名这扇门。查询举个例子，域名去年某金融公司做渗透测试，网址主站防护得像铁桶，查询WAF、域名态势感知、网址全流量审计，查询结果测试人员通过子域名找到了一个测试环境的`uat.pay.example.com`，直接打穿了内网。为什么？因为子域名往往对应着不同的业务系统、不同的开发团队、不同的安全水位。运维可能把主站管得死死的，但某个边缘子域名上挂着老旧的Tomcat或者未授权访问的Jenkins，这就成了突破口。 子域名查询的本质，是在利用DNS的公开记录做情报收集。有三条路可走：一是被动收集，通过证书透明度日志（Certificate Transparency）、搜索引擎、DNS历史记录这些公开数据源去捞。比如`crt.sh`这个网站，输入域名就能看到所有申请过SSL证书的子域名，因为证书签发过程是公开的，这招几乎不碰目标服务器，隐蔽性极好。二是主动爆破，用字典去猜常见的子域名前缀，比如`admin`、`test`、`dev`、`oa`，然后发起DNS解析请求。这招效率高，但容易触发告警，毕竟大量不存在的域名解析请求本身就是异常行为。三是利用搜索引擎的site语法，比如在Google里搜`site:example.com -www`，能翻出不少被收录的子域名页面，有时候还能直接搜到后台登录入口。 工具方面，开源的`subfinder`和`amass`是主流选择，前者胜在速度快，聚合了几十个公开源，几秒钟就能返回结果；后者更重，支持被动和主动结合，还能做关联分析，但配置复杂，跑一次能把你CPU烧到80度。商业的像`SecurityTrails`，数据全，历史DNS记录能回溯到几年前，但收费不便宜。我自己习惯先用subfinder快速扫一遍，再用`dnsx`做存活验证，最后用`httpx`探测HTTP服务，三步下来，一个域名的攻击面基本就清晰了。 有个细节容易被忽略：子域名查询不只是为了找漏洞，还能帮你做资产盘点。很多公司自己都说不清到底有多少个子域名在跑，尤其是那些并购来的业务线，老域名没注销，新域名又没统一管理，导致大量僵尸资产暴露在公网。前阵子帮一个客户做安全审计，光通过证书透明度就发现他们名下挂着300多个子域名，其中40多个已经无法访问，但DNS记录还指向公网IP，等于给黑客留了后门。这种问题，光靠安全团队查是查不完的，得让业务部门认领资产，定期做清理。 查询结果出来之后，别急着高兴，先做去重和过滤。很多子域名解析到CDN或者云服务商，比如`cdn.example.com`指向了Cloudflare，那就不是源站IP，没法直接打。这时候得靠历史DNS记录或者SSL证书的SAN字段去翻真实IP，有时候还能通过子域名关联到同一个SSL证书下的其他域名，顺藤摸瓜找到更多资产。另外，泛解析（Wildcard DNS）是个坑——如果你发现随便输入一个不存在的子域名都能解析到同一个IP，那说明目标配置了`*.example.com`，爆破出来的结果全是无效的，得换个思路，比如直接查根域名的NS记录或者邮件服务器的SPF记录。 说到底，子域名查询不是一次性动作，而是持续性的监测过程。域名会变，业务会扩，今天查完了，明天可能就多了个新子域名。我习惯把这套流程做成定时任务，每周跑一次，把新增的域名拉出来对比，有变化就自动告警。毕竟，对手不会等你准备好了才动手。

(责任编辑：娱乐)