注册商锁定 vs 分层防御：各自何时更有效

想象一下，某天醒来发现公司名下的每一个域名（生产环境、预发布环境，还有那个承载着 MX 记录的域名）在一夜之间全被你的域名注册商暂停了。没有部署出错，没有服务器宕机。某个风控团队（更可能是一条自动化的滥用举报流水线）按了个开关，你的整个互联网存在就这么没了。这事并非空想：系统管理员论坛上时不时就有注册商因未经核实的滥用举报、一条有歧义的推文，或者数百万用户上传内容中的一张被标记图片而冻结账户的惨痛经历。

我多年来为基础设施团队处理过事故响应，规律总是一样的。工程师为计算资源设计了复杂的冗余方案（多可用区、多地域、故障转移手册），却把唯一无法重新部署的资产，也就是域名本身，放在一个只靠密码甚至短信验证码保护的账户里。本文比较了应对这一风险的两种思路：传统的注册商锁定（挑一家靠谱的注册商，加固账户，然后相信它们）与分层防御（假定注册商会坑你，并围绕它做工程设计）。剧透：两者你都需要，但真正能在凌晨三点救你的是后者。

为什么你的注册商是另一种单点故障

技术栈里的大多数单点故障都在你的掌控之中。数据库主节点、NAT 网关、消息代理，你可以做副本，故障转移方案也是你自己写的。注册商则不同，原因有三。第一，它是无法复制的控制面依赖。同一个域名不能同时由两家注册商管理，注册局只认一个登记注册商。第二，注册商故障的恢复很慢。正常情况下域名转移需要五到七天，如果当前注册商已经冻结了你的账户，你甚至可能拿不到发起转移所需的授权码。第三，这种故障带有一种古怪的对抗性：攻击者并不存在，是服务商自己基于你从未见过的举报对你动手。

影响范围也比大多数人想象的更糟。注册商暂停域名时，通常会把 NS 记录指向一个下架页面，或者干脆不再应答。这当然会让你的网站瘫痪。但它也会让你的邮件（MX 记录就存在 DNS 里）、如果回调地址引用了你域名的 SSO、API 客户端、如果状态页与主站同域的话的状态页，还有我个人最喜欢的一点，用来接收找回账户指引的邮箱全部失效。如果你的注册商账户邮箱是 admin@yourdomain.com，而 yourdomain.com 已被暂停，那你就陷入了一个死循环：要用一个注册商客服不信任的地址证明身份。我亲眼见过这个循环吃掉一次事故的整整一天。

经济激励也在与你作对。当注册商被私募股权收购（几家大型注册商确实如此）时，剧本是可以预料的：砍掉人工客服、把滥用处理自动化、提价。自动化滥用系统优化的是它们自己的风险，而不是你的。把一个后来被证明无辜的域名停掉，对它们没有任何代价；放任一个后来被证明有问题的域名，则会带来注册局的麻烦和负面舆论。你猜自动化会朝哪个方向出错。

方案一：注册商锁定，加固单点

锁定的思路是：承认注册商就是单点故障，然后尽可能把这个点加固。无论大家是否明确表述过，这其实是大多数公司实际在用的策略。做得到位的话，大致是这样：

• 按客服质量而非价格选择注册商。每个域名每年省的 3 美元，跟一天的宕机损失比起来毫无意义。你需要电话客服、大型域名组合的专属客户经理，以及一家万一真出事时你能在本国司法辖区起诉的公司。
• 为所有域名开启注册商锁定（clientTransferProhibited），并为关键域名开启注册局锁定。注册局锁定要求在任何 NS 或转移变更前进行带外验证，通常是打电话并核对口令。它很烦，而这正是它的意义所在。
• 使用硬件密钥或 TOTP 双因素认证，绝不用短信。客服人员被一段令人信服的聊天说辞说动、移除了 2FA 的故事多到数不清；现在有些注册商提供了「没有硬件密钥就不允许任何账户变更」的策略。用上它们。
• 为注册商账户使用专用的角色邮箱，并且该邮箱的域名不能在同一家注册商注册。比如 domains-admin@example.org，注册在完全不同的地方。
• 严格控制访问权限。指定两到三个具名人员，凭据存放在公司密码库中，而不是某个电子表格里的共享登录。
• 把所有信息都记录下来：账户编号、PIN、客服升级路径、账户认证所用的确切身份证件。写进你的事故应急手册。

锁定确实有真实的优势。它能防止最常见的注册商灾难，那不是扣押，而是劫持。社会工程攻击和账户接管这些年来偷走了大量高价值域名，而注册局锁定加硬件双因素认证几乎能挡住所有这类攻击。而且它成本低，无需持续的工程投入。

但现实很残酷：锁定保护你不受攻击者侵害，却保护不了你不被注册商本身伤害。上面每一项控制措施，都是由注册商自己运营的。如果它们的滥用自动化系统冻结了你的账户，那你的注册商锁定就变成了把你锁在外面，你的客服 PIN 存在一个你进不去的系统里，而能推翻这一切的那个人，可能因为上季度的客服「优化」已经不在了。即便是简单的误判案例，从业者也报告过六小时以上的恢复时间；如果暂停跨越周末，则可能是好几天的拉锯。锁定是必要的，但远远不够。

方案二：分层防御，假定注册商会背叛你

分层思路从一个更阴暗的前提出发：总有一天，无论出于恶意、自动化还是失误，你的注册商会把你的域名停掉，而你必须在他们的客服队列轮到你之前恢复上线。这与针对灾难性故障的防御性工程背后的思路是一致的：你无法阻止灾难发生，但可以让灾难变得可以承受。

核心技巧是把通常捆绑在一起的各层拆开。大多数小公司会买域名、用注册商的 DNS、托管在注册商的主机服务上，邮件也一并交给它。这就在同一个账户里堆叠了四个单点故障。把它们拆开：

• 域名注册：在注册商 A 注册，因其稳定性和客服质量而选择它。
• 权威 DNS：托管在独立的 DNS 服务商 B（或以双主模式使用两家服务商），并以代码方式管理。
• 主机托管：根据工作负载选择最合适的平台，与前两者无关。
• 邮件：使用专门的邮件服务商，A 和 B 的账户找回邮箱则放在又一个不同的域名上。
• 备用域名：在另一家注册商预先准备一个备用域名，签发好 TLS 证书，并让你最关键服务的精简版本已经在上面提供响应。

备用域名值得强调，因为几乎没人这么做，而它是杠杆效应最高的一招。当主域名被暂停时，DNS 的 TTL 和解析器缓存意味着你无法简单地「切换到备份」。备份必须在事故发生之前就已经存在、预热并且可以解析。像 example-status.net 这样在别处注册的备用域名，承载着你的状态页、事故沟通渠道和紧急 MX 记录，就能把一场可能致命的宕机变成一个略显尴尬的周二。

DNS 即代码：所有人都会跳过的一层

这种故障我在真实事故中见过两次：团队在注册商暂停后拿回了域名，把一切重新打开，却发现 DNS 是错的，因为其区域的「事实来源」是注册商的网页界面，而事故期间那个界面根本进不去，而且本来就和任何人的记忆对不上了。在事故期间凭记忆重建一个 200 条记录的区域文件，那种痛苦简直难以言表。正如我们之前写过的，DNS 配置错误在正常情况下也会不断搞崩生产环境；而在注册商事故中，它就是灾难性的。

解决办法很无聊：把 DNS 区域当作代码来管理，放在版本控制中，由 CI 部署。dnscontrol 或 Terraform 的 DNS 服务商插件这类工具，可以让你以声明式的方式描述区域，并将其推送到多家服务商。这样，即使任何一家服务商的控制面失效，你的 DNS 状态依然完好，「切换到 DNS 服务商 B」就变成一行修改加一次部署，而不是一场英雄式的复制粘贴。

# dnsconfig.js — one zone, two providers, deployed by CI
var REG_NONE = NewRegistrar('none');
var DSP_CLOUDFLARE = NewDnsProvider('cloudflare');
var DSP_ROUTE53 = NewDnsProvider('route53');
D('example.com', REG_NONE,
DnsProvider(DSP_CLOUDFLARE),
DnsProvider(DSP_ROUTE53),   // dual-authoritative: either can die
A('@', '203.0.113.10'),
A('www', '203.0.113.10'),
MX('@', 10, 'mail.example.net.'),   // MX on a DIFFERENT TLD/provider domain
TXT('@', 'v=spf1 include:_spf.example.net -all'),
CNAME('status', 'statuspage.example.net.')
);

双权威 DNS 被严重低估了。大多数解析器都会乐于尝试所有列出的 NS 服务器，所以如果某家服务商出了故障（而大型 DNS 服务商确实偶尔会出故障），解析依然能继续。难点在于保持两家服务商同步，而这恰恰是 DNS 即代码免费提供的能力。没有它，双服务商 DNS 就是一台制造配置漂移的机器，说它比单一服务商更糟也不为过。

关于 TTL 有一点需要注意：团队总爱把 TTL 调到 86400「为了性能」，然后在事故中才发现，全网有四分之一的地方会把旧的 NS 记录缓存整整一天。对于与 NS 相关的记录，以及任何你可能需要紧急修改的记录，把 TTL 保持在 300–900 秒。相比灵活性带来的收益，多出来的查询量成本微不足道。

正面对比：各自何时更有效

我们直说这其中的取舍，因为两种策略针对的威胁和适用的组织都不同。

• 威胁模型：锁定对劫持和社会工程攻击最有效，这些是统计上常见的灾难。分层防御则对注册商一侧的故障更有效：滥用自动化、账户扣押、公司破产或客服体系崩溃。
• 成本：锁定几乎不花钱，只需注册局锁定的费用、一把硬件密钥，再加上纪律性。分层防御则需要承担第二家服务商的账单、备用域名、CI 的搭建成本，以及为防止配置漂移而持续投入的精力。
• 恢复时间：在扣押场景下，只做锁定的团队只能听凭客服队列摆布（根据我听过的每个惨痛故事，要等几小时到几天）。而拥有预热备用域名的分层团队可以在几分钟到几小时内恢复。
• 运维负担：锁定设置好就不用管了。分层防御若无人维护则会腐烂，一个从未测试过、证书已过期的备用域名，只是安全剧场。
• 组织适配：一个只有五个人、只做一款 SaaS 产品的创业公司，应该做完整的锁定，外加两项成本最低的分层措施（外部 DNS 即代码，以及域外的找回邮箱）。而收入会随域名一起消失的公司，则需要完整的分层架构。

锁定保护你的域名不受攻击者侵害，分层防御保护你的业务不受注册商侵害。两者你都面临风险，所以两者你都需要。

直到为时已晚，大家才会去写的恢复手册

无论你选哪种姿态，现在就把扣押应急手册写出来。我见过的那些处理得还算顺利的事故，都事先有这么一份手册；而那些灾难性的情况，都是临场摸索的。你的手册应当按顺序涵盖：确认影响范围（是单个域名还是整个账户，检查 whois 的状态码，例如 clientHold 或 serverHold）；用你记录下来的账户标识符提交客服工单；启用备用域名并更新状态页与沟通渠道；通过不依赖已失效域名的渠道通知客户；并同时启动转出流程，不要等问题解决了才决定离开。

也要演练那些枯燥的部分。你能否在一台干净的设备上、用硬件密钥登录注册商，而不依赖那个藏在被暂停域名背后 SSO 之后的密码管理器？值班人员能否找到注册局锁定的口令？团队每季度都会演练数据库故障转移，却从不演练注册商恢复。考虑到注册商故障会切断你用来访问其他一切的 SSO，这种优先级是倒过来的。

我的建议

把锁定做到位，这只是一个下午的工作，却能挡住最可能发生的攻击。然后按以下顺序，实施恰好三项分层防御：把权威 DNS 迁出注册商，并以代码方式管理；把注册商账户的找回邮箱迁到另一家注册商的域名上；以及搭建一个预热的备用域名，配好证书、状态页和紧急 MX 记录。这三项每年只需几百美元，就能覆盖最主要的故障模式。完整的双注册商、双 DNS 架构，留给那些能说清楚域名全部丢失一天会造成多大损失的组织。如果这个数字有六位数，你就已经知道该怎么做了。

如果你还在主要按价格选择注册商，请停下来。廉价注册商市场正在向一些所有者集中，这些所有者的动机是用自动化取代人的判断，而这套自动化会毫不犹豫地因误判而暂停你，然后在周四才来处理你的工单。你的域名是唯一一项无法从容器镜像重新部署的基础设施。请这样对待它。