无人管理的子域名隐藏着哪些安全风险


你的 DNS 区域里,很可能存在一些已经没人负责的记录。这不只是卫生问题,也可能成为真实的攻击面。

很多安全讨论会关注应用代码、云资源、认证体系和权限控制,但 DNS 区域经常被忽视。对于经常创建活动入口、合作方入口、测试环境和租户域名的组织来说,DNS 同样需要生命周期管理。

这篇文章写给安全团队、平台团队、DevOps 团队和运营负责人,讨论废弃子域名为什么会出现,以及如何通过结构化管理减少风险。

子域名从创建、遗忘、暴露风险到安全退场的生命周期图。

典型场景

团队为春季活动创建了 campaign-spring.example.com,它通过 CNAME 指向某个第三方托管平台。活动结束后,托管资源被删除,但 DNS 记录还在。

从业务角度看,活动已经结束。从互联网角度看,这个子域名仍然存在。

类似情况会出现在很多地方:已结束但未清理的活动页面、几个月前删除的测试环境、已迁移的文档或客服页面、结束合作关系的合作方入口,以及已下线但 DNS 记录仍在的内部工具。

风险就存在于“资源已经没了”和“DNS 记录还在”之间。

什么是废弃子域名

废弃子域名是指:DNS 记录仍然存在并可以解析,但它指向的资源已经不存在,或者不再由组织控制。

最常见的形式是 CNAME 记录指向第三方服务,而第三方上的具体 app、bucket、project 或 site 已经被删除。

团队可能认为这个入口已经不用了,但 hostname 仍然对外可见。这就是问题。

为什么企业会积累“幽灵子域名”

创建子域名和删除子域名的激励完全不同。

创建是紧急的。活动要上线,客户要开通,合作方要入口,测试环境要在周五之前可访问。

删除通常不紧急。活动结束了、客户流失了、合作关系终止了、环境删除了,但没人因为 DNS 记录还在而马上感到痛。

没有所有权

大多数 DNS 记录没有“负责人”字段。几个月后再看,很难知道某条记录是市场创建的、客户成功创建的,还是工程创建的。

不知道能不能删,就倾向于不删。

创建分散,记录集中

市场、合作、工程、产品都可能产生子域名需求,但最后都堆在同一个 DNS 区域里。

知道业务背景的人,往往不是有权限删除 DNS 记录的人。

害怕误删

如果没人知道一个子域名是否还在使用,删除它就显得危险。保留它看起来更安全。

一次这样做没问题,长期这样做就会变成组织风险。

子域名 takeover 风险

废弃子域名在某些条件下会形成 subdomain takeover 风险。

机制并不复杂:CNAME 指向第三方平台,第三方上的具体资源被删除,但 DNS 记录仍然存在。如果这个平台允许其他人重新声明同名或相关资源,攻击者就可能接管该子域名下展示的内容。

攻击者可能在你的域名下展示钓鱼页面、托管恶意下载、滥用某些信任父域名或子域名的策略,或者给安全响应和品牌处理制造混乱。

严重程度取决于具体子域名和安全架构,但核心风险很清楚:外部人员可能在用户信任的 hostname 下展示内容。

为什么生命周期管理是正确解法

一次性的 DNS 审计有用,但不能解决结构性问题。根因在于:很多团队有“创建流程”,但没有“退场流程”。

生命周期管理要让每个状态都明确。

创建时记录所有权

创建入口时,就应该记录原因、团队和生命周期:

  • 活动入口应该有结束时间
  • 租户入口应该绑定客户状态
  • 合作入口应该绑定合作关系
  • 预览入口应该绑定部署或 PR

有了上下文,未来才知道如何处理。

先停用,再删除

直接删除常常让人担心。更安全的流程是先停用。

停用后,流量停止,但配置还在。团队可以观察一段时间,确认没有影响后再永久删除。

删除必须是一等操作

删除入口应该和创建入口一样简单、清晰、可追踪。如果删除比创建更麻烦,入口就不会被删除。

每次变更都要有审计日志

团队需要知道谁创建了入口、什么时候更新过、之前指向哪里、谁停用了它、什么时候删除。

这些信息对安全调查、合规审查和内部责任边界都很重要。

用访问数据辅助决策

如果一个入口 90 天没有访问,它可能适合进入清理流程。如果一个应该停用的入口突然有访问,也值得调查。

按入口统计访问数据,可以让清理决策从“猜”变成“看数据”。

PushUlink 支持子域名转发规则的完整生命周期:创建、更新、停用和删除。

每条规则都可以保留配置、状态、访问统计和操作 trace。关键操作写入日志,访问数据按入口统计,权限边界区分普通用户、管理员和 OpenAPI 凭证。

这并不意味着 PushUlink 是 WAF、漏洞扫描器或完整安全网关。它解决的是更具体的问题:让子域名入口有所有权、有状态、有日志、有退场路径。

当入口管理变成可观察系统,幽灵子域名就不再容易悄悄积累。

不要等事故发生后再清理

很多子域名安全问题是在事故后才被处理:有人报告 takeover,钓鱼页面出现,或审计发现 DNS 区域异常。

更好的方式是在事故发生前建立生命周期。

如果组织会持续创建子域名,每个入口都应该有负责人、状态、访问数据和退场机制。

PushUlink 目前处于 MVP 阶段,专注于托管子域转发、OpenAPI 自动化、访问统计、权限边界、日志和可追踪操作。