关于域名漏洞的整改情况

我们手上的关于改情域名，远不止是域名网址。它像门牌号，漏洞更像一把钥匙。关于改情上个月，域名安全团队例行扫描时，漏洞发现一个子域名的关于改情DNS记录里，静静躺着一条指向早已过期云服务器的域名A记录。那台服务器上跑着测试用的漏洞后台，没有口令保护。关于改情更巧的域名是，这个子域名恰好被某个合作方写进了他们系统的漏洞回调白名单——这意味着，谁先抢注了那个过期域名，关于改情谁就能冒充我们的域名系统，接收合作方推送的漏洞敏感数据。

这不是孤例。翻遍资产清单，类似的“僵尸记录”还有十几条。有的子域名指向内网IP，解析出去别人根本访问不了，但黑客在内网横向移动时，却能拿它当跳板。有的CNAME记录还链着三年前就停用的CDN加速域名，那个域名现在挂着赌博广告。域名系统这东西，平时没人看，一出事就是大事。

整改先从“清点”开始。我们把所有域名和子域名的解析记录导出来，跟云厂商的资产列表、备案信息、SSL证书申请记录逐条比对。这一步最费劲，因为很多老记录是不同部门在不同时期加的，文档没更新，只能靠问。问下来发现，有个营销活动的落地页子域名，活动早结束了，但解析记录还活着，指向的对象存储桶也忘了删，里面的用户手机号脱敏数据就这么裸奔了三个月。

然后是“收紧”。对不再使用的域名，直接停解析、注销备案，该删的删。对还在用的，强制要求所有解析记录必须关联到当前有效的云资源ID，并且设置TTL从默认的600秒降到60秒——这样万一再出问题，切换或删除后，生效时间能缩短到一分钟内。有人抱怨说TTL调低会增加DNS查询量，我说，这点成本比被薅一次羊毛便宜多了。

最棘手的是“外部依赖”。很多合作方在系统里写死了我们的回调域名，甚至有些是写在他们客户现场的私有化部署里。我们没法强制他们改，只能挨个发函，附上新的验证文件，请他们在下次版本升级时替换。有一家银行客户，他们的安全团队回复说，内部流程要求变更必须走三个月审批周期，这期间我们的旧域名不能停。行，那就给这个旧域名单独加一条“仅允许该银行IP段访问”的访问控制策略，并用监控盯住任何异常解析请求。

整改完成后，我们做了次模拟攻击测试。尝试用未备案的域名去替换一个已废弃子域名的解析记录，系统在五分钟内告警，并自动封禁了操作IP。这个结果让我松了口气，但说实话，更让我后怕的是那个过期云服务器的案例——如果当时没人扫描，如果那个子域名没被合作方写进白名单，后果不堪设想。

域名漏洞不是技术难题，而是管理漏洞。技术手段再强，也架不住“忘了删”“没记录”“懒得改”这些日常惰性。现在我们的规矩很简单：任何域名或子域名的创建、变更、销毁，必须走工单系统，关联到具体负责人和到期时间。到期前三十天自动提醒，到期未续费或未申请延期的，直接暂停解析。规矩定得死板，但至少下个季度再盘点时，表格里不会出现“未知用途”这种鬼话。