子域名挖掘前置基础 04DNS 数据与记录本篇定位前两篇讲了 DNS 怎么把域名翻译成 IP。本篇讲 DNS 里存了什么数据——记录类型、不同分级 DNS 服务器各存什么、树形结构与 Zone Delegation、通配符。这些是子域名挖掘最核心的基础知识因为挖掘的本质就是在这些数据里找子域名。阅读建议本篇内容偏概念但每个概念都直接关联挖掘方法。读的时候多想这条知识在挖掘里能怎么用。一、DNS 记录类型每种记录的情报价值DNS 服务器存的数据叫记录。不同类型的记录有不同的用途对子域名挖掘也有不同的情报价值。不要去背每种记录的定义而要从这条记录能告诉我什么的角度理解。1.1 主要记录类型一览记录类型全称作用情报价值AAddress域名 → IPv4 地址指向哪个 IP判断是否走 CDN/云AAAAIPv6 Address域名 → IPv6 地址同 A但是 IPv6CNAMECanonical Name域名 → 另一个域名的别名情报之王——暴露第三方服务依赖、潜在接管NSName Server域名 → 管理它的权威 NS揭示管理边界、子域是否独立 ZoneMXMail Exchange域名 → 邮件服务器暴露邮件基础设施TXTText任意文本SPF 的 IP 段、Google/MS 验证、DMARCSOAStart of Authority区域权威起点管理员邮箱、序列号推断更新频率SRVService Record服务定位暴露 SIP、XMPP、LDAP 等内部服务PTRPointerIP → 域名反向解析从 IP 反查域名CAACertification Authority Authorization指定可签发证书的 CA暴露证书签发策略1.2 各记录的挖掘价值详解A / AAAA 记录A 记录是最常见的——域名指向 IP。从挖掘者视角A 记录的价值不在这个 IP 是多少而在这个 IP 是什么性质IP 性质怎么判断挖掘意义CDN 节点IP 归属查是 CDN 服务商不能直接扫端口要绕 CDN 找源站云主机IP 归属查是云厂商可能是目标自建可扫端口真实服务器IP 归属查是目标企业高价值直接扫端口共享主机一个 IP 上有多个域名IP 反查能发现更多子域CNAME 记录情报之王CNAMECanonical Name别名记录告诉解析器这个域名其实是另一个域名的马甲。CNAME 暴露的信息量最大CNAME 指向推断出的架构挖掘意义*.cloudfront.net用了 CloudFront CDN走 CDN要绕过*.elb.amazonaws.com后端是 AWS 负载均衡云架构可能云资产延伸*.s3.amazonaws.com对象存储可能存在 Bucket 权限错配*.github.ioGitHub Pages 托管可能存在子域名接管*.vercel.appVercel 托管可能存在子域名接管已弃用的 SaaS 域名目标停止订阅但没删 DNS子域名接管漏洞关键认知每条 CNAME 都是一条架构线索。子域名挖掘工具通常会把 CNAME 链完整记录下来作为判断目标架构的关键依据。NS 记录管理边界NS 记录揭示这个域名归谁管。从挖掘者视角NS 情况意义子域 NS 和主域不同由不同团队管理安全配置可能有差异子域 NS 指向外部服务商用了第三方 DNS如 CDN、云厂商多个 NS 不同不同子域用不同 DNS暗示组织结构关键认知如果一个子域的 NS 和主域不同说明它由不同团队管理安全配置可能有差异——这种边界地带往往是防护薄弱处。MX 记录邮件基础设施MX 记录指定谁负责处理发往该域名的邮件。从挖掘者视角MX 可能指向不在主域名下的邮件服务器子域比如mail-guardian.example.net——一个你完全不知道的域名。TXT 记录服务使用TXT 记录里藏了大量服务使用证明TXT 内容暴露的信息vspf1 ip4:1.2.3.0/24SPF 记录里的 IP 段暴露发信服务器范围google-site-verification...用了 Google 服务MS...用了 Microsoft 服务_dmarcDMARC 的 report URI 可能指向监控子域SOA 记录管理员信息SOA 里的邮箱地址和序列号能让你推断 DNS 更新频率——序列号跳跃式增长说明配置在频繁变动。SRV 记录内部服务SRV 记录里可能藏着 SIP、XMPP、LDAP 等内部服务的地址这些子域往往是直接暴露内网服务的入口。1.3 记录类型的 mindmapDNS 记录类型A / AAAA::解析到哪个 IP::判断是否走 CDN/云CNAME::别名指向::暴露第三方服务依赖::潜在子域名接管NS::管理边界::子域是否独立 zoneMX::邮件基础设施::可能指向非主域的邮件服务器TXT::SPF 的 IP 段::Google/MS 服务验证::DMARC report URISOA::管理员邮箱::序列号推断更新频率SRV::SIP/XMPP/LDAP::内部服务地址二、不同分级 DNS 服务器的记录类型上一节讲了有哪些记录类型。这一节讲这些记录分别存在哪一级 DNS 服务器上。理解这个能帮你判断去哪里查什么记录。2.1 各级 DNS 服务器存什么服务器级别存什么记录例子根服务器所有 TLD 的 NS 指针.com归a.gtld-servers.net管TLD 服务器该 TLD 下所有二级域的 NS 指针example.com归ns1.example.com管权威服务器自己管辖的 Zone 内所有记录example.com的 A、CNAME、MX、TXT 等递归解析器缓存不存权威数据只暂存查过的你刚查过的api.example.com → 1.2.3.42.2 关键认知记录存在哪一级关键认知记录存在权威服务器上。根和 TLD 不存 A、CNAME 这些最终记录只存指路用的 NS 记录。递归解析器存的是缓存不是权威数据。这就意味着你想查example.com的 A 记录 → 要问example.com的权威 NS你想查example.com的 MX 记录 → 也要问example.com的权威 NS根和 TLD 都给不了你这些答案2.3 各级 DNS 服务器的查询对应关系存: 所有 TLD 的 NS返回: .com TLD 的 NS存: .com 下所有二级域的 NS返回: example.com 的 NS存: example.com 的所有记录返回: api 的 A 记录查询: api.example.com 的 A 记录根服务器.com TLD 服务器example.com 权威 NS2.4 对子域名挖掘的意义想查什么去哪查目标域名的 NS问 TLD或递归解析器它有缓存目标域名的 A/CNAME/MX/TXT问目标域名的权威 NS子域是否存在问目标域名的权威 NS直接查绕过缓存目标域名有哪些子域权威 NS 不直接给列表要靠字典爆破、CT Logs 等关键认知权威服务器不直接告诉你我有哪些子域名——DNS 协议没有列表功能。你必须用字典爆破、证书透明度日志、搜索引擎等手段去发现。这就是为什么子域名挖掘是一门发现的艺术而不是查询的功夫。三、DNS 树形结构与 Zone DelegationDNS 本质上是一棵层级分明的树根在顶部越往下越具体。整棵树由授权边界切分成一个个 Zone区域。3.1 DNS 的树形结构DNS 的树不是域名的树而是DNS 服务器 Zone的树——每一层服务器管一个 Zone委派就是切分 Zone 的边界。┌─────────────────────────────────────────────┐ │ 根 DNS 服务器Root Servers │ │ Zone: 根存所有 TLD 的 NS 指针 │ └──────────────────────┬──────────────────────┘ │ ┌───────────────────┼───────────────────┐ │ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ .com TLD │ │ .cn TLD │ │ .org TLD │ │ 服务器 │ │ 服务器 │ │ 服务器 │ │ Zone: .com │ │ Zone: .cn │ │ Zone: .org │ └──────┬─────┘ └────────────┘ └────────────┘ │ │ 存: example.com 的 NS 指针 ▼ ┌─────────────────────────────────────────────┐ │ example.com 权威服务器ns1.example.com │ │ Zone: example.com │ │ ├─ www → A 记录 未委派在父 Zone 内 │ │ ├─ blog → A 记录 未委派在父 Zone 内 │ │ ├─ api → A 记录 未委派在父 Zone 内 │ │ └─ dev → NS 记录 ★ 委派边界 ★ │ └──────────────────────┬──────────────────────┘ │ 委派控制权移交给子域自己的 NS ▼ ┌─────────────────────────────────────────────┐ │ dev.example.com 权威服务器ns1.devteam.net │ │ Zone: dev.example.com独立 Zone │ │ ├─ git.dev → A 记录 │ │ └─ ci.dev → A 记录 │ └─────────────────────────────────────────────┘如何读这张图每个方框是一台 DNS 服务器 它管辖的 Zone。箭头是指路关系——上层不存下层具体记录只存 NS 指针。带 ★ 的是委派边界dev从父 Zone 切离成为独立 Zone由自己的权威服务器管理。父域权威服务器对dev下面有什么一无所知只负责说去问 ns1.devteam.net。3.2 关键概念Zone区域Zone 是 DNS 管理权限的基本单位——一块连续的管理边界由一组权威服务器负责内容存放在一个**区域文件Zone File**里。一个 Zone 可以是一个域名及其所有子域名未委派时一旦某个子域名被委派出去它就从父 Zone 中切离成为独立的新 Zone树是逻辑结构Zone 是管理切片。一棵树可以被切成任意多个 Zone切分点就是委派边界。3.3 Zone Delegation区域委派是什么Zone Delegation 父域把某个子域名的解析控制权通过 NS 记录移交给另一组权威服务器。委派完成后变化说明子域成为独立 Zone由自己的权威服务器管理父域权威不再存子域具体记录只保留一条指向子域权威服务器的 NS 记录3.4 委派的具体例子假设example.com的 Zone 文件原本长这样; example.com 的区域文件委派前 example.com. IN NS ns1.example.com. example.com. IN A 1.2.3.4 www IN A 1.2.3.4 api IN A 5.6.7.8 dev IN A 9.9.9.9现在把dev.example.com委派给开发团队的 DNS 服务器; example.com 的区域文件委派后 example.com. IN NS ns1.example.com. example.com. IN A 1.2.3.4 www IN A 1.2.3.4 api IN A 5.6.7.8 ; ↓↓↓ 委派边界 ↓↓↓ dev.example.com. IN NS ns1.devteam.net. ; 子域的权威服务器此时dev.example.com成为一个独立 Zone由ns1.devteam.net管理example.com的权威服务器不再知道dev.example.com下有什么记录如git.dev.example.com递归查询走到父域权威时收到的是一条 NS 委托记录要转向去问子域的权威服务器3.5 委派对子域名挖掘的意义核心意义说明制造权威数据源切换委派后子域数据只在子域权威上要分别查每一级权威NS 记录是高价值枚举线索一条 NS 记录 一个被委派的子域Zone Transfer 受委派边界限制AXFR 只能拿当前 Zone委派出去的不在其中决定枚举的递归深度发现一个子域有 NS要把它当新主域重新挖可能隐藏信息孤岛不同部门各自管理子域常成为安全盲区3.6 委派下的子域名枚举策略example.com ├── www.example.com 父 Zone 内一次性可枚举 ├── api.example.com 父 Zone 内 ├── dev.example.com 委派 Zone → 需问 ns1.devteam.net │ ├── git.dev.example.com 子 Zone 内 │ └── ci.dev.example.com 子 Zone 内 └── corp.example.com 委派 Zone → 需问 ns.corp.net └── vpn.corp.example.com 子 Zone 内关键认知枚举工具必须跟随 NS 委派链递归深入只问父域权威服务器会漏掉所有已委派子域下的内容。这就是为什么子域名挖掘工具要做递归挖掘——发现一个子域有 NS 记录就把它当成新主域重新挖一遍。四、DNS 记录的通配符讲完委派再讲一个子域名挖掘的头号陷阱——通配符 DNS。4.1 什么是通配符 DNS通配符 DNSWildcard DNS是用*.example.com这条记录匹配所有未明确列出的子域名。原理当权威 NS 收到一个它没有明确记录的子域名查询时如果存在*.example.com这条通配符记录它会返回通配符记录的结果。换句话说你拿任何随机字符串拼上去都能解析成功。4.2 通配符的例子假设example.com的区域文件里有*.example.com. IN A 1.2.3.4那么api.example.com如果没明确记录→ 解析到1.2.3.4random123abc.example.com不存在→ 也解析到1.2.3.4任何东西.example.com→ 都解析到1.2.3.44.3 为什么这是头号陷阱不只产生假阳性那么简单——它会污染你后续的所有分析环节污染环节后果字典爆破跑出 50000 个子域名全是假的HTTP 探测浪费大量时间探测不存在的服务端口扫描可能触发目标的入侵检测资产清单全是垃圾数据掩盖真正有价值的发现4.4 识别通配符的思路关键认知识别通配符的思路是用不存在的东西验证存在——生成 5 个完全随机、不可能真实存在的子域名如xyzrandom123abc.example.com去做查询如果全部返回相同 A 记录就是通配符。但要注意部分通配符有些目标只在特定层级如*.api.example.com或特定记录类型上做通配符主域层面查不出来。所以识别要分层做。4.5 处理策略不能简单粗暴地丢弃所有通配符结果。原因在于有些服务在 DNS 层走通配符所有子域解析到同一 IP但在 HTTP 层根据 Host 头做了区分不同子域返回不同内容。你需要结合 HTTP 响应内容做二次判断——只有DNS 解析相同且 HTTP 内容也相同的才是真正的假阳性。通配符识别的具体技巧留到后续子域名搜集方法章节展开。本篇只讲基础概念。五、本篇小结概念一句话记录类型A、CNAME、NS、MX、TXT、SOA、SRV 等各有情报价值CNAME情报之王暴露第三方服务依赖NS揭示管理边界是发现委派子域的直接证据分级记录根/TLD 存 NS 指针权威服务器存具体记录Zone Delegation子域有独立权威服务器要当成新主域重新挖通配符 DNS*.example.com匹配所有未明确列出的子域是头号陷阱有了这些概念下一篇我们讲子域名背后的 Web 与网络层——CDN、负载均衡、网络架构图、HTTP/HTTPS 与 TLS。附本篇关键术语速查术语简明解释A 记录域名 → IPv4 地址AAAA 记录域名 → IPv6 地址CNAME 记录域名 → 另一个域名的别名NS 记录域名 → 管理它的权威 NSMX 记录域名 → 邮件服务器TXT 记录任意文本常用于服务验证SOA 记录区域权威起点含管理员邮箱和序列号SRV 记录服务定位记录暴露内部服务PTR 记录IP → 域名反向解析ZoneDNS 的独立管理单元Zone File权威服务器存的区域文件Zone Delegation父域把子域解析控制权移交给另一组 NS通配符 DNS用*.example.com匹配所有未列出的子域AXFR区域传送一次性拷贝整个 Zone 的记录