子域名接管实战

解决什么问题

子域名接管的典型场景是：DNS 记录指向了某个已下线、未续费或未认领的外部资源。CNAME 可能悬空指向服务端点，NS 可能委派给失效名称服务器，MX 可能指向被释放的邮件主机。这类记录在浏览器里表现为厂商错误页、NXDOMAIN、过期响应头或不可达状态。真正麻烦的是它常与信任边界叠加：SSRF allowlist 信任 *.target.com，CORS 信任泛域名，缓存或鉴权按 Host 路由，页面又在目标源下执行脚本。于是，一个看似无害的悬空子域名可能变成跨源读取、Cookie 窃取、OAuth 跳转滥用或缓存污染的入口。

技能如何工作

该技能把接管判断拆成可验证的证据链，而不是把“存在 CNAME”当成“可接管”。

• 记录类型识别：汇总 CNAME、NS、MX 等解析结果，记录 TTL、目标值、异常响应和错误文本。
• 指纹匹配：按响应头、Body、状态码、DNS 错误和历史行为匹配厂商或资源类型，避免把普通 404、限流页、关闭页误判为可认领。
• 认领前置条件检查：确认目标资源是否已解除绑定、无活跃绑定、仍在可声明窗口内，并保存非破坏性证据。
• 验证与处置：在授权范围内验证认领流程；对无法确认的项目降级为风险项，而不是继续扩大攻击面。
• 防御监控：持续比对 DNS 清单，对悬空记录、厂商错误页、异常 Host 行为和泛域名信任配置告警。

适用边界

只用于已获授权的资产和测试范围。不同厂商的释放、回收、恢复策略不同，指纹库必须随行为变化更新。NS 与 MX 更换可能直接影响业务，验证前先确认业务依赖。即使检测到接管面，也应优先修复 DNS、绑定资源、收敛泛域名信任，而不是先尝试认领。