公众号旧文
为什么很多废弃的子域名没人清理？
大家注册域名以后，都会陆续创建一些子域名的解析记录。
比如：
blog.example.com
api.example.com
dev.example.com
test.example.com
panel.example.com
vps.example.com一开始，这些子域名可能都对应着真实用途：
有的指向博客服务器，有的指向测试环境，有的指向某台 VPS，有的指向对象存储、CDN、云函数或者第三方托管平台。
但是随着时间推移，服务器可能被删除了，项目可能下线了，测试环境可能不用了，第三方服务也可能已经释放了。
问题是：域名解析记录却还留在那里。
于是就出现了一种很常见的情况：
子域名还在解析
但背后的服务器、服务、项目早就没了这类记录通常可以叫作废弃解析记录、过期解析记录、悬空 DNS 记录，或者 stale DNS record。
一、为什么很多人不会主动删除废弃子域名？
因为删除它没有明显收益，但维护它需要成本。
对于很多个人站长、开发者来说，平时的操作流程是这样的：
VPS 不用了 → 直接销毁机器
项目不用了 → 代码不维护了
测试环境不用了 → 服务关掉了
域名解析 → 忘了删这很正常。
因为 DNS 记录通常不是每天都会看的东西。
很多人只有在新建网站、配置服务、迁移服务器时才会打开 DNS 控制台。
等服务下线时，人的第一反应往往是关机器、停项目、删资源，而不是回头检查所有相关子域名。
尤其是下面这些子域名，最容易被遗忘：
test.example.com
dev.example.com
staging.example.com
old.example.com
panel.example.com
api-test.example.com
demo.example.com这些名字本身就带有临时、测试、过渡性质。
用的时候很方便，不用的时候也最容易没人管。
对个人来说，几个废弃记录影响不大。
对公司来说，几年下来可能会积累出几十个、几百个历史子域名。
二、废弃解析记录有风险吗？
不一定。
要看它指向的是什么。
常见情况主要分两类。
第一类是 A 记录或 AAAA 记录，直接指向某个 IP 地址：
old.example.com A 1.2.3.4如果这台服务器已经被销毁，但 DNS 记录还在，那么这个子域名仍然会解析到旧 IP。
这时风险取决于这个 IP 后来做了什么。
如果 IP 已经不可访问，那通常只是一个“坏链接”或者“无效域名”。
用户访问时打不开，体验不好，但安全风险相对有限。
但如果这个 IP 被云厂商重新分配给了别人，而别人刚好在这个 IP 上部署了 Web 服务，那么访问 old.example.com 的用户，就可能连到别人的服务器。
这不一定意味着对方能控制你的域名，但至少说明：
你的域名还在把流量引向一个你已经不控制的地方。
第二类是 CNAME 记录，指向第三方云服务或托管平台：
app.example.com CNAME old-project.vercel.app
docs.example.com CNAME old-site.github.io
cdn.example.com CNAME old-bucket.s3.amazonaws.com这种情况更需要注意。
因为很多第三方平台的资源是可以被释放、删除、重新注册的。
如果你把子域名 CNAME 到某个第三方资源，后来你删除了那个资源，但 DNS 记录没有删，那么别人有可能重新创建同名或可接管的资源。
这就可能导致所谓的子域名接管。
简单说就是：
你的子域名还指向第三方平台
但第三方平台上的原资源已经不存在
别人重新创建了对应资源
于是你的子域名可能被别人接管显示内容这类风险通常比普通 A 记录更值得重视。
三、什么情况下应该清理？
有两类情况尤其应该清理。
第一种：子域名曾经用于重要入口
如果某个子域名曾经是登录入口、管理后台、远程访问、API、内网穿透、远控服务、面板地址，那就不建议长期保留废弃解析。
比如：
admin.example.com
panel.example.com
rdp.example.com
ssh.example.com
api.example.com
rustdesk.example.com这些名字本身就容易让人联想到管理、连接、接口或远程控制。
即使服务已经不用了，也最好删除相关解析。
因为这些子域名可能被搜索引擎、安全扫描器、历史记录、证书透明日志、浏览器收藏夹、旧文档、旧脚本记录下来。
只要 DNS 还在解析，就可能继续有人访问它。
如果它指向的资源已经不受你控制，就会带来不必要的风险。
第二种：子域名 CNAME 到第三方平台，但资源已经释放
这是最值得重视的情况。
比如你曾经用过：
blog.example.com CNAME username.github.io
app.example.com CNAME project.vercel.app
static.example.com CNAME bucket.s3.amazonaws.com
docs.example.com CNAME site.netlify.app后来你在第三方平台上删除了项目、空间、站点，但 DNS 记录还留着。
这时如果第三方平台允许别人重新创建相关资源，或者存在资源绑定校验不严格的情况，就可能出现子域名接管风险。
所以有一个简单原则：
只要 CNAME 指向的第三方资源已经不用了，就应该优先删除对应 DNS 记录。这比普通 A 记录更需要优先处理。
总结
废弃子域名没人清理，是非常普遍的现象。
因为很多人只记得创建解析，却很少在服务器销毁、项目下线、测试环境废弃时，回头清理 DNS 记录。