10 月初，Google 安全团队披露了一起很少见的劫持事件：加纳的 .GH、塞拉利昂的 .SL 和美属萨摩亚的 .AS 三个国别顶级域名，被人从注册局层面拿走了控制权。攻击者没有破解哪家公司的密码，也没有进入 Google 的内网，而是直接修改这些顶级域名下的 DNS 记录，再拿改好的解析去申请 TLS 证书。

这件事值得写下来，不是因为它又一次证明“DNS 很重要”，而是因为它把 HTTPS 的信任边界摆到了明面上：当域名从根上被别人控制时，浏览器里的锁标和证书只能说明这次连接是加密的，不能说明你连到的还是原来那家公司；HSTS 最多保证浏览器不退回 HTTP，也解决不了这个问题。

注册局失守，和注册商被盗不是一回事

平时说域名安全，大家先想到的是注册商账号：强密码、两步验证、转移锁。它们保护的是“谁能改这个域名的设置”。但这次出事的是注册局。注册局运营整个顶级域，掌握 TLD 区的权威解析和下级域名的委派；注册商只是替用户办理注册、把域名指向某个 DNS 服务商。注册局被攻破，等于所有挂在它下面的域名同时暴露，单个注册商那边的锁不一定帮得上忙。

攻击者拿到注册局权限后，最直接的动作是改委派记录，把域名的 NS 指向自己的服务器；如果注册局同时托管权威解析，也可以直接改 A、AAAA 记录。接下来申请证书并不难：CA 做域名验证时，只要求申请者能控制 DNS 或 HTTP 上的一个挑战；DNS 已经在攻击者手里，验证自然通过。Google 说没有证据表明 CA 违反流程，原因就在这里——从 CA 的视角看，申请者确实控制了这个域名。

Google 也确认，自家有域名出现了未授权证书，但内部系统没有被入侵；它没有公布受影响的域名清单和数量。

所以一张受信任的证书，证明的是“签发那一刻，申请者能控制这个域名”，不是“这个域名的主人授权了这次签发”，更不是“网站内容没有被替换”。攻击者拿到证书后，可以终止 TLS 再转发请求，读到明文，也可以直接返回一个看起来一模一样的登录页。用户看到的仍然是熟悉的域名和锁标，但连接的终点已经换了人。

Chrome 的拦截是止血，不是修复

Google 的处置分两步：先把已经识别出来的异常证书加入 Chrome 的 CRLSet，让 Chrome 在访问时拦截；再联系 CA 撤销这些证书，让其他浏览器和客户端也能收到撤销信息。与此同时，他们去翻证书透明度日志，发现还有更多品牌和常用服务可能被签发了异常证书。

CRLSet 是随 Chrome 更新下发的一份撤销集合，优点是快，缺点是只覆盖 Chrome 已知的证书。攻击者如果换了域名、换了证书，或者用户用的是别的浏览器、命令行工具、App 内置的 WebView，这套拦截就未必生效。Google 也承认，DNS 劫持的情况很复杂，无法保证找全所有受影响的域名，而且浏览器端拦截不能可靠地保护非 Chrome 用户。

证书透明度日志在这里更像监控摄像头，而不是门锁。它记录了公开签发的证书，事后能查，但不阻止签发。对域名持有者来说，真正有用的动作是定期查自己的域名有没有出现没申请过的证书，而不是等浏览器弹警告。

域名持有者应该检查什么

第一件事是确认自己的域名落在哪个注册局下面。com、net 这类通用顶级域和国别顶级域的风险模型不一样，一些小国的注册局资源有限，安全流程未必跟得上。不是说要马上把所有域名搬走，而是要知道自己依赖的是谁，以及出事时该找谁。

第二件事是注册局锁和注册商锁。注册商锁能挡住账号被盗后的转移，注册局锁要求域名变更经过额外的线下确认，能挡住一部分自动化攻击。它们都不是万能的，尤其当注册局本身被攻破时，锁的效力取决于对方还剩多少流程；但它们能把普通账号泄露升级成大规模劫持的门槛抬高不少。

第三件事是 DNS 变更监控。不要只在自己的解析面板里看，最好从多个外部视角定期检查权威 NS、A、AAAA、MX、TXT 和 CAA 记录有没有变化。攻击者改的是权威记录，本地缓存可能还留着旧值，只在一个地方看很容易错过。域名不多的话，一个定时脚本加邮件告警就够用。

第四件事是证书透明度监控。用 crt.sh 查询自己的域名，通配符写法是百分号加域名，例如查询 example.gh 下的所有证书可以搜 %.example.gh。看到没有申请过的证书，先确认是不是同事或某个云服务代申请，再联系对应的 CA 吊销。这个动作不能阻止第一张假证书被签发，但能缩短它被使用的时间。

第五件事是 DNSSEC 和 CAA。它们有用，但别把它们当成绝对防线。CAA 记录告诉 CA 哪些机构可以为域名签发证书，可 CAA 本身也放在 DNS 里；DNS 被控制时，攻击者可以改掉它。DNSSEC 能防止解析结果在传输过程中被篡改，但它的信任链同样从顶级域开始，注册局失守时不能假设它还能提供完整保护。它们提高攻击成本、留下痕迹，但不能把“注册局被攻破”这件事变成不可能。

最后是缩小爆炸半径。不要把登录、邮件、支付和主要内容全放在同一个国别域名下；重要服务至少准备一个独立域名和一套备用入口。这样即使某个顶级域出问题，也不会所有东西一起停摆。

如果已经被劫持

先联系注册局和注册商，确认委派记录和 NS 记录，要求冻结变更并保留日志。然后盘点证书透明度日志里出现的所有证书，逐个联系 CA 吊销；同时检查 MX、TXT 和 CAA 有没有被改，邮件和密码重置流程有没有被利用。

接着轮换所有可能暴露的凭据：后台密码、API key、部署令牌、对象存储密钥。不要只改网站登录密码，攻击者拿到 DNS 控制权后，很可能已经通过邮件或验证码流程重置了别的东西。最后再通知用户，说明时间窗口和影响范围，别用“部分用户受影响”这种没有信息量的表述。

普通用户能做什么

看到证书警告不要点继续。浏览器把警告做得越来越吓人，是因为它确实可能意味着中间人；这次事件里，攻击者拿到的是受信任的证书，警告反而可能不出现，所以更不能把“没有警告”当成安全证明。

在输入密码、验证码、支付信息之前，先确认自己是从收藏夹或官方入口进来的，不是从搜索结果、私信或邮件里的链接跳过来的。如果站点突然要求重新登录、重新验证银行卡，或者页面行为和平常不一样，先停下来，从另一个已知可靠的入口再试一次。锁标只说明连接加密，不说明对面是谁。

这次事件最刺眼的地方，是攻击者没有和应用层的任何一行代码搏斗。他们只是拿走了域名系统的控制权，然后让整条 HTTPS 链路替他们作证。证书本身没有坏，也没有证据显示 CA 的流程被绕过，坏的是信任链的起点。

对个人博客和小团队来说，可能没人会专门攻击你的注册局；但同一套逻辑在小尺度上也成立：域名账号、DNS 服务商、邮件域名、证书签发，任何一个环节被拿走，网站都可能在一段时间里“看起来完全正常”。把域名控制权当成生产系统的一部分来管理，比在页面上放一个 HTTPS 锁标更有意义。

参考：蓝点网（landian.news），2026 年 10 月 7 日；Google Security Blog 原始披露。原文编号：127171。