结论先行：域名的权威解析和它背后的证书，是一类长期被当作「IT 杂项」管理的资产。这次事件说明它们值得单独建一套台账：登记归属与续期状态、订阅证书签发日志、写一条限制签发的解析记录。浏览器侧的拦截是兜底，不是替代方案。
事件经过
据一家国际互联网企业 2026 年 10 月 6 日的公开披露，以及多家媒体在 10 月 7 日的报道：
| 维度 | 公开信息 |
|---|---|
| 被攻陷的对象 | 三个国家级顶级域（分别属于加纳、塞拉利昂、美属萨摩亚）的注册机构 |
| 攻击动作 | 修改被选中域名的权威解析记录与域名服务器委派信息 |
| 借此拿到的 | 通过了证书签发所需的域名控制权校验，获得针对多家大型机构域名的未授权证书 |
| 影响范围 | 该企业未公布受影响域名完整清单，并明确其自身系统未被攻破 |
| 处置方式 | 浏览器侧批量拦截可疑证书，同时与签发机构协作吊销 |
| 披露方提醒 | 不能只依赖浏览器侧拦截；受影响域名应自查签发记录，并发布限制签发来源的解析记录 |
披露方给出的理由很直接：解析劫持这类事件的排查很难做到穷尽，浏览器侧的手段也无法覆盖非浏览器客户端。也就是说，企业不能把「用户没报错」当成「我们没被影响」。
为什么这两类资产经常没人管
域名和证书有三个共同特征，恰好都指向管理空白。其一，数量不多但分散——通常由市场、行政、业务部门在不同时间注册，IT 部门手上没有一份完整清单。第二，平时不出声——不占资源、不产生告警，只有到期或解析出错时才会被想起。第三，责任链模糊——注册商账号可能在离职同事的个人邮箱名下，续期提醒发到了没人看的地址。
这次事件还暴露了一个更隐蔽的点：证书的签发依据是「谁能控制这个域名」，而不完全是「谁是域名的合法所有者」。注册机构被拿下之后，控制权校验就失去了原有的意义。企业能做的，是在这个链条上补上几道自己的检查。
三件可以落地的动作
一、给域名和证书建一份台账
台账的字段不用复杂，但要能支撑三个判断：这个域名归谁负责、证书什么时候到期、签发来源应该限定为谁。台账要覆盖全部域名，包括长期不用的停放域名和地区性子站——这两类恰恰最容易被漏掉，也最适合被拿来做跳板。建完之后，把续期与归属变更做成流程：负责人变更要同步台账，续期失败要有升级路径。
二、订阅证书签发记录的通知
公开的证书签发日志会记录每一张被签发的证书。把企业全部域名（含停放域名）纳入订阅范围，就能在有人申请到一张自己没申请过的证书时收到提醒。这是目前成本较低、见效较快的一项监测手段，且不依赖任何单一厂商。建议把它接入既有的告警通道，并指定谁来看、多久看一次。
三、用解析记录限定签发来源
通过一条专门的解析记录，域名所有者可以声明哪些签发机构被允许为其签发证书。需要说明的是，这条记录不能阻止劫持发生期间的签发，但它能阻止攻击者利用缓存下来的校验状态，在解析控制权恢复之后继续签发。这属于一次配置、长期生效的动作，适合与台账建立同步完成。
和可用性监测的关系
域名解析与证书位于「企业自己不完全掌控、但业务强依赖」的那一层，和第三方接口、外部网络链路属于同一类。这类外部依赖的共同点是：故障不发生在自己的机房里，但用户感知完全一样。因此建议把域名解析结果、证书有效期、外部接口连通性放进同一组拨测任务，按固定频率执行，并让告警直接落到负责的团队。奇摩在做外部依赖监测时，习惯把「解析是否指向预期地址」和「证书剩余有效期」做成两项固定的巡检项，而不是等出问题再查。
边界与前提
其一，浏览器侧拦截依然是有效保护，但它只覆盖使用该浏览器的用户，且依赖厂商的排查是否完整，不能作为企业侧仅有的防线。其二，签发记录订阅会产生一定量的通知，需要先定义什么算异常，否则容易淹没在日常噪音里。其三，解析记录限定只能约束合规的签发机构，对已经取得控制权的攻击者无效，因此它解决的是「事后不再被重复利用」，不是「事中不被签发」。
落地清单
- 盘点全部域名（含停放域名与地区子域），登记归属人、注册商账号与续期时间。
- 把全部域名纳入证书签发记录订阅，明确通知接收人与处置责任。
- 为关键域名配置限制签发来源的解析记录，并记录配置时间与内容。
- 把解析结果与证书有效期纳入周期性拨测，告警接到具体负责人。
- 清理已停用域名与过期证书，避免长期无人认领的资产留在台账外。
- 把证书到期与域名续期写进变更日历，提前留出处理窗口。
这两类资产的治理难点不在技术，而在把它们从「杂项」提升为「有人负责的资产」。需要梳理域名与证书台账、建立外部依赖拨测口径，欢迎 预约咨询。