域名转移锁89%的站有，但那把锁是注册商默认替你上的

摘要：把130个英文大牌的域名注册局记录逐条拉出来看，89.2%的站带着转移锁，数字很体面。但按注册商拆开就变味了：GoDaddy名下32个站，31个的锁组合一个字都不差；阿里云名下7个站，6个一把锁都没有。锁的多少和品牌规模、行业、安全预算都不相关，只和你在哪家买的域名相关。另外130个站里签了DNSSEC的只有12个。

一个域名到底属于谁，这件事的最终答案不在你的服务器上，也不在你的DNS面板里，而在注册局的数据库里。那份记录写着谁是注册商、什么时候到期、以及最要紧的一栏——哪些操作是被禁止的。

这一栏叫EPP状态码，标准定义写在RFC 5731里，一共17个标准值，公开可查，任何人对任何域名都能查。它决定了一个域名能不能被转走、能不能被删掉、能不能被改。听起来像是每个品牌都会认真对待的东西，实测下来不太是。

本轮把131个英文大牌站点的域名做了一遍注册局查询，用的是RDAP协议——它是WHOIS的正式替代品，RFC 9083规定它返回结构化的JSON，而不是WHOIS那种各家格式不一、没法可靠解析的纯文本。查到的每个域名再交叉查一遍DNS里的DS记录，两边对账。

说明一下这篇和站内已有的几篇域名文章不重叠在哪。怎么挑一个域名、怎么起名、域名年龄影不影响排名，讲的都是买之前的决策；这一篇讲的是买完之后那份记录里写了什么，以及那些字段是谁替你填的。

域名这件资产，到底锁在谁手上？

先把角色理清楚，因为这三层经常被搞混。

注册局是最终记账的那一方，.com由Verisign运营，全世界所有.com域名的归属记录都在它那里。注册商是你打交道的那家，GoDaddy、阿里云、Cloudflare都属于这一层，它替你去注册局下单。你是注册人，名字写在记录里，但你没有直接操作注册局的权限。

EPP状态码分两套，正好对应后两层。ICANN的官方说明里写得很清楚：client开头的由注册商设置，server开头的由注册局设置，而且server码优先级高于client码。

这个区别很实在。clientTransferProhibited是你的注册商替你挂的牌子，如果有人骗过了注册商的客服，这块牌子可以被摘掉；serverTransferProhibited是注册局层面的，注册商自己也动不了，要走一套单独的流程才能解锁。一个防的是普通的账号失守，一个防的是注册商本身被绕过。

知道这个分层之后，再看那些漂亮的覆盖率数字，读法就完全不同了。

89%的站都有转移锁，可这把锁是谁上的？

130个域名拿到有效记录（graza.co的.co注册局没有提供RDAP服务，后面单说）。按状态码统计：

• clientTransferProhibited（禁止转移）：116个站，89.2%
• clientDeleteProhibited（禁止删除）：56个站，43.1%
• clientUpdateProhibited（禁止修改）：53个站，40.8%
• clientRenewProhibited（禁止续费）：33个站，25.4%
• 任意一个server级锁：21个站，16.2%
• 状态是active、一把锁都没有：14个站，10.8%

第一行看着很不错，接近九成。但把每个域名上的锁数量做个分布，形状就不对劲了：

• 0把锁：14个站
• 1把锁：45个站
• 2把：8个　3把：9个
• 4把锁：45个站
• 5把：1个　6把：8个

这是个双峰分布。要么只有一把，要么整整四把，中间的2把和3把加起来才17个。正常情况下，一群独立做决策的团队，做出来的结果应该是连续分布的。出现双峰，说明这些配置不是各家自己拍板的，是从少数几个模板里发出来的。

这个信号我之前撞见过好几次：查CAA记录那轮，11个站的授权名单逐字相同，一查是Shopify统一下发的；查支付页CSP那轮，45个配了策略的站里只有5个真管住了脚本，其余全是平台出厂配置；查robots.txt的分组规则那轮，一大批站的写法整齐得像是同一个模板生成的，事实也确实如此。凡是第一版跑出一组特别整齐的数字，八成是把一批本来不同的东西归进了同一格。

同一个注册商下面，锁的组合为什么一个字都不差？

按注册商拆开，双峰的成因当场现形。

GoDaddy零售（32个站，占样本24.6%）：31个站的状态码组合完全一致——delete、renew、transfer、update四把全上，一个不多一个不少。剩下那1个是eufy.com，一把锁都没有。

CSC Corporate Domains（15个站）：9个站是transfer加三把server锁的固定组合，5个站只有transfer一把，1个多带一把delete。

MarkMonitor（10个站）：整齐地分成两组，5个站是六把全上，另外5个站是三把client锁。

阿里云北京（7个站）：6个站一把锁都没有，只有1个站带了transfer加三把server锁。

Amazon Registrar（7个站）：6个只有transfer一把。NameCheap（5个站）：4个只有transfer一把。Cloudflare（3个站）：3个都只有transfer一把。

规律干净得不像话：同一家注册商下面，锁的组合是复制粘贴出来的。把品牌名字盖住，只看这一栏，你能反推出它在哪家买的域名，准确率高得离谱。

算一下平均值更直观：MarkMonitor每个域名平均4.50把锁，COM LAUDE 4.50，GoDaddy零售3.88，CSC 3.07；另一头，阿里云北京0.57，Amazon 0.86，NameCheap 0.80，万网系0.00。

差距不在品牌的安全意识上，在它选了哪家注册商。用MarkMonitor的多半是大集团的法务或品牌保护部门在管域名，那种地方的默认动作就是全锁上；用阿里云和Amazon的通常是技术团队顺手注册的，注册完就去干别的了。这两拨人对“域名安全”的重视程度未必有4.5比0.57这么大的差距，但他们买域名的地方替他们做完了选择。

这件事和选服务商会被连坐是一个道理的两面：你把一件事外包出去，拿到的不只是服务，还有对方的默认值。

一把锁都没上的那14个站，是些什么站？

先把名单摆出来：baseus.com、dji.com、dreametech.com、eufy.com、functionofbeauty.com、insta360.com、narwal.com、notino.com、oclean.com、shein.com、sulwhasoo.com、tuftandneedle.com、ugreen.com、vaude.com。

一眼看过去，中国出海品牌占了大半：Baseus、DJI、追觅、eufy、影石、云鲸、Oclean、SHEIN、绿联，九个。很容易得出一个结论说中国品牌不重视域名安全。

但把注册商那一列摆上就得改口了。这九个里有八个注册在阿里系名下——阿里云北京六个（追觅、影石、云鲸、Oclean、SHEIN、绿联），万网两个（Baseus、DJI），而这两家注册商在本轮样本里的平均锁数分别是0.57和0.00。这不是九个团队各自做出的九次决定，这是同一套默认值被复制了八遍。剩下那一个是eufy.com，它在GoDaddy，是GoDaddy那32个站里唯一没有锁的例外——同一家注册商的默认值在它身上没生效，这种个案反而值得它自己去查一下。

另外五个非中国品牌也说明这不是地域问题：functionofbeauty.com在Amazon Registrar，tuftandneedle.com在NameCheap，notino.com在捷克的Gransy，sulwhasoo.com（韩国爱茉莉太平洋旗下）在Gabia，vaude.com在德国电信。都是零售型注册商，都是不主动加锁的默认值。

值得单独提一句vaude.com。它一把锁都没上，却是130个站里仅有的12个签了DNSSEC的之一，同时它的域名还有44天就到期。一个域名可以在一个维度上做得比99%的同行都好，在另一个维度上完全空白——因为这几件事分属不同的系统、不同的界面、不同的人，从来没有一张表把它们放在一起看过。

顺便说一下ICANN在同一份文档里给注册人的建议，原话是：主动要求你的注册商启用clientTransferProhibited、clientDeleteProhibited和clientUpdateProhibited这类限制，有助于防止未经授权的转移、删除和修改。关键词是“主动要求”——它默认你得自己去开口。

那把写着“禁止续费”的锁，是安全锁吗？

这是本轮最反直觉的一处，也是我差点算错的地方。

统计的时候我一开始用“锁的数量”当作安全程度的代理指标，四把锁的比一把锁的强。按这个算法，GoDaddy零售平均3.88把，排在CSC（3.07）前面，成绩相当漂亮。

然后我去核对每一把锁到底是什么意思，卡在了clientRenewProhibited上。ICANN那份文档对它的描述是这样的：这个状态码告诉注册局拒绝续费请求；它是一个不常见的状态，通常在法律纠纷期间、或者域名即将被删除时启用；出现这个状态往往说明你的域名有问题需要解决。

对照实测：33个站带着它，其中31个来自GoDaddy一家，包括一批规模不小的DTC品牌的主域。这批域名显然不是集体在打官司，也不是集体等着被删。官方文档说“不常见、通常意味着有问题”的东西，在这里成了四分之一样本的默认配置。

合理的解释是它被挪作他用了：注册商在自己的自动续费流程里挂上这把锁，避免注册人从别的渠道触发一次重复续费，等于把续费这个动作收归自己独家办理。这是我的推测，GoDaddy没有公开说明过原因，所以它只能停在推测上。

但不需要知道动机，也能得出一个确定的结论：这把锁挡的是续费，不是劫持。把它算进“安全锁”，等于把一条商业流程约束当成了安全措施。修正之后，那把真正防劫持的三件套是transfer、delete、update，GoDaddy的四把里有三把在这个范围内，得分不变；但“四把比三把强”这个说法作废了——多出来的那一把和安全无关。

这条给我的教训比数字本身更值钱：做统计的时候，别用数量代替性质。四个状态码堆在一起看着像一道四重防线，逐个查过定义才知道其中一道是别的用途。响应头里那248个死字段栽的也是这一跤——字段在那儿摆着，接收端早就没了。

只有注册局能上的三把锁，130个站里谁拿到了？

21个站，16.2%。

这三把锁——serverDeleteProhibited、serverTransferProhibited、serverUpdateProhibited——按ICANN的说明由注册局设置，且优先级高于同名的client码。实务上它们通常打包成注册商的高阶服务卖，改一次要走人工核验流程，不是在后台点一下就能开关的。

拿到这三把锁的21个站，来源高度集中：CSC Corporate Domains占10个，MarkMonitor占5个，剩下6个分散在EuroDNS、Key-Systems、COM LAUDE、Lexsynergy、Ascio和阿里云北京各一个。

CSC和MarkMonitor这两家几乎不做零售生意，客户基本是大集团的品牌保护部门，年费是普通注册商的十几倍甚至几十倍。所以这16.2%基本可以读成：130个品牌里，有21个把域名当成需要专门花钱保护的资产在管，剩下109个把它当成一笔年费开销。

这个差别在出事那天才会显现。域名劫持的经典剧本是社工注册商客服、拿到账号控制权、发起转移；client级的锁在这个剧本里能被同一个客服摘掉，server级的不能。想想品牌被仿冒那类事故的处理成本，再对比一下这几把锁的年费差价，账其实很好算——前提是有人在算。

顺便说清楚这几把锁不管什么。它们锁的是注册局那份记录，不是你的DNS解析。攻击者要是拿到了你的DNS托管账号，域名归属一个字没变，解析却可以指到任何地方去，这时候server锁一点忙都帮不上。同理，它也管不了别人拿相近的域名去抢你的品牌词——那是商标和SERP占位的事，属于另一条战线。这几把锁只解决一个问题：你这个域名本身，不会在你不知情的情况下换主人。

DNSSEC走到今天，为什么还是只有9%？

130个站里签了DNSSEC的有12个，9.2%。名单：assos.com、charleskeith.com、farfetch.com、getquip.com、glossier.com、ikea.com、kotn.com、marinelayer.com、mejuri.com、ritual.com、sostrenegrene.com、vaude.com。

这个数字是两边对上的：注册局记录里的secureDNS.delegationSigned字段说签了的12个，直接查DNS拿DS记录也是这12个，两把尺子零分歧。

DNSSEC解决的问题是DNS应答可能被伪造：默认情况下，一条DNS回答没有任何签名，你怎么知道它真的来自权威服务器？签了之后每条记录带密码学签名，验证方能自己校验。RFC 4034定稿于2005年，二十一年了。

按DNS托管商拆开看普及率，能看出瓶颈在哪：

• AWS Route 53：1/33
• Cloudflare：3/27
• 自建或其它：4/23
• GoDaddy DNS：0/16
• MarkMonitor DNS：0/5　Akamai：0/4
• Azure DNS：1/4　Google：1/3　DNS Made Easy：1/3

有意思的是MarkMonitor这一格：这些客户舍得花钱上三把server锁，却一个都没签DNSSEC。说明这不是预算问题，是这件事根本没进他们的清单。

DNSSEC铺不开的原因，和邮件那层的MTA-STS、页面那层的严格加密声明是同一套结构：没有人强制、不做也不会有人发现、动手要跨两个供应商。它还多一层麻烦——签错了不是降级，是整个域名在开了验证的解析器上直接解析失败，也就是全网打不开。一个可能把网站搞挂的操作，和一个不做也没人管的现状放在一起，选择是很自然的。

这也解释了为什么DNSSEC和那三把server锁在人群上不重合。锁是买来的，付了钱就有；DNSSEC是做出来的，得有人排期、有人测试、有人在密钥轮换那天守着。能用采购解决的事，大公司都做得不错；需要有人持续盯着的事，规模再大也一样难。

不过要注意，托管商的托管本身早就不是障碍了。Cloudflare、Route 53、Azure DNS都支持一键签名，剩下的工作只是把DS记录交给注册商——难的是流程横跨两家供应商，而不是技术。之前排查海外解析问题时也是这个感觉：DNS这一层的活儿单看每一件都不难，难在没人统一管。

到期只剩14天的那个域名，说明了什么？

说明它十四天后要续费，仅此而已。这一栏最容易被过度解读，所以先把话说死：注册局记录里的到期日不等于失效日，绝大多数域名开着自动续费，到期日一到就往后推一年，注册人什么都不用做。看到一个大牌的域名还剩两周到期，不代表它要掉。

但这一栏还是有用，它反映的是续费策略。130个站的分布：

• 距到期中位数326天，也就是多数品牌把域名维持在“还有一年”这个水位
• 剩余不足90天的：17个站　不足180天的：33个站
• 剩余超过5年的：15个站

两头的样本最有信息量。最紧的三个：avocadogreenmattress.com剩14天、glossier.com剩22天、framebridge.com剩36天。最松的三个：buckmason.com到2036年、zalando.com到2035年5月、bollandbranch.com到2035年5月。

一次续十年和一次续一年，差价是几十美元，差别是十年里你不会再碰这件事。短续费周期的风险不在于忘记，自动续费基本不会忘；风险在于支付方式失效——绑定的信用卡过期、公司卡换号、财务把那笔小额扣款当成订阅给退了。这类事故的典型特征是：它不是没人管，是管它的那个人早就离职了。

还有一类风险是自己动手时踩的。域名迁移、换域名、换注册商这些操作，赶上锁开着就得先解锁，解完往往就忘了锁回去。解锁是个有明确目的的动作，锁回去不是，所以它经常留在待办列表里过夜。本轮那45个只有一把transfer锁的站里，有多少是本来有四把、迁移完只补回了一把，从单次快照里看不出来——这也是本轮数据的一个硬限制。

顺带把注册年份也看一眼，130个域名里1990年代注册的有59个，2000到2009年注册的32个，2010年之后的39个。最老的五个是philips.com（1987年）、weber.com（1992年）、on.com（1993年）、prose.com（1994年）、reebok.com（1994年）。这里有个常见误读值得提一句：注册日期反映的是这个域名字符串第一次被注册的时间，不等于这个品牌的年龄，也不等于当前这家公司持有它的时间——二手域名交易在注册局记录里通常只体现为一次“最后更新”。想细究这条线怎么读，域名年龄是不是排名因素和过期域名的信任继承这两篇讲得更细。

这一轮，我的尺子错在哪几处？

四处，其中一处如果不修，整篇文章的分母都是错的。

第一处：拿86个站当130个站用

第一轮查询走的是rdap.org，一个把请求转发到各注册局的聚合服务。131个域名跑下来，86个返回200，44个返回429，也就是被限流了，1个返回404。

如果就此收工，所有百分比都会建立在86这个分母上，而且这86个站不是随机抽出来的——它们是排在队列前面的那些，字母序靠前。用一个由请求顺序决定的子集去代表整体，这个错误没有任何统计方法能事后补救。

修法是绕开聚合器，直接问注册局。RFC 9224规定了怎么找到该问谁：IANA维护着一份引导注册表，把每个顶级域映射到对应注册局的RDAP服务地址。拉下这份表，按顶级域拼出地址逐个查，请求之间留出间隔。44个里救回44个，分母从86变成130。

剩下那1个是graza.co。.co在引导表里没有登记RDAP服务地址，这不是我没查到，是这项服务不存在。数据缺失和服务不存在是两回事，前者要补，后者只能如实剔除并说明——所以本文所有比例的分母是130，不是131。

这件事还有个副产品值得记一笔：限流本身不是站点属性，是我这一侧的请求节奏造成的。那44个站并没有拒绝提供数据，是聚合服务扛不住连续请求。之前测第三方脚本的时候也栽过同类跟头——把一次采集失败当成了被测对象的特征。凡是失败样本超过一成，先怀疑自己的采集方式，再怀疑数据。

第二处：把同一把锁数成了两把

RDAP返回的状态值长这样：client transfer prohibited，带空格的小写形式。而EPP协议里的原名是clientTransferProhibited，驼峰式。两种写法我一开始没归一化，结果同一把锁在统计里出现了两行。

这个归一化不是我拍脑袋定的：ICANN那份文档的表格里就并排列着两栏，一栏EPP状态码，一栏RDAP状态映射，明确写着两者的对应关系。能找到官方对照表的时候，就别自己编映射规则——上一轮做CAA的时候，我自编CA标识符映射表，差点冤枉一个站违规。

第三处：换个数据源，答案会不会变？

这一处没出错，但必须做，否则前面那次补采就没法交代——44个站的数据来自注册局直连，86个来自聚合器，两个来源的结果能不能混在一张表里？

做法是从已经成功的86个里随机抽12个，再用注册局直连查一遍，逐字段比对状态码列表、到期日和DNSSEC标记。12个站，零分歧。三项全部一致，聚合器只是个转发层，没有改写数据。

这就是上一轮总结出来的那条判据的常规用法：任何“A和B不一样”的结论，先问一句“A和A自己一样吗”。这次问下来答案是一样的，所以两个来源可以合表——花了几分钟，换来的是后面所有数字都站得住。

第四处：用数量代替性质

就是上面clientRenewProhibited那件事。锁的数量和防护强度不是一回事，四把里有一把是干别的用的。这个错误的隐蔽之处在于它不会让任何一个数字算错，只会让结论的方向错。

另外有一条局限得写明白：本轮所有数据都是2026年9月2日这一天的快照。状态码是会变的，一次转移、一次续费、一次客服操作都会改动它。没有历史序列，就无法回答“这把锁是什么时候上的”“这个域名换过几次注册商”这类问题——那需要长期采样，本轮没有做。

自己的域名该怎么查？

不用注册工具账号，命令行两条就够。

第一步，查注册局记录。

curl -s -H "accept: application/rdap+json" https://rdap.org/domain/你的域名 | python -m json.tool

返回的JSON里盯三处：status数组（有哪些锁）、events里的expiration（到期日）、secureDNS里的delegationSigned（有没有签DNSSEC）。如果rdap.org限流了，就去IANA的引导表里找到你这个顶级域对应的注册局地址，直接问它。

第二步，查DNSSEC是不是真的生效。

dig +short DS 你的域名
dig +dnssec 你的域名 | grep -c RRSIG

注册局记录说签了、但DNS里查不到DS记录，说明委托链断了——这种状态比不签更糟，因为你以为自己有保护。本轮130个站两边完全一致，没碰到断链的，但这不代表不会发生。

第三步，按这个顺序去补。

1. 先确认三把基础锁在不在：transfer、delete、update。缺了就找注册商开，这是免费的，多数注册商在后台就能自助勾选。ICANN的建议里明确点了这三个的名字。
2. 再看到期日和支付方式。到期日本身不重要，重要的是绑定的那张卡还有效吗、账单邮箱还有人收吗。这两件事一起过期的时候，自动续费就是一句空话。
3. 核心域名考虑上server级锁。判断标准很简单：这个域名要是被转走了，你的生意会不会停摆。会的话，那笔年费差价不值得省。
4. DNSSEC放最后，因为它是这几件事里唯一一个做错了会把网站搞挂的。先在一个不重要的域名上走通全流程，再动主域。
5. 把这几栏做成一张表，和证书到期日、DNS记录清单放在一起。域名根上那些验证记录、SPF那条链有多长、证书的续期节奏、注册局这几把锁，本来就该是同一张表上的几列——它们的共同点是平时完全没有存在感，出问题的那天全都是P0。
6. 顺手清一遍子域。域名这一层理干净之后，很容易发现下面挂着一批早就该下线的东西，参见之前那轮子域名清点：131个站里查出22个测试环境没设noindex。

保哥见过的域名事故里，代价最大的那类不是被人攻破了什么，是没人知道这件事归谁管：域名在前同事的个人账号下，账单邮箱是他离职后停用的，续费失败通知发进了一个没人看的邮箱，等到网站打不开才发现。本轮那14个一把锁都没有的站，风险其实不在没锁，在于这说明没有人系统地过过这一栏。

再说回那个双峰分布。130个域名的保护水平，最强的解释变量是注册商，不是品牌规模、不是行业、也不是安全预算。这句话反过来听更有用：你和那些做得最好的品牌之间，隔的不是能力，是几个没人替你点的默认选项。它们大多是免费的，而且今天下午就能点完。

常见问题解答

怎么快速知道自己的域名有没有上锁？

查RDAP记录里的status数组，一条命令的事：curl -H "accept: application/rdap+json" https://rdap.org/domain/你的域名。如果返回的状态只有active一项，说明一把锁都没有——本轮130个站里有14个是这个状态。老式的WHOIS查询也能看到同样的信息，只是返回的是非结构化文本，不好解析。

clientTransferProhibited和serverTransferProhibited差在哪？

差在谁能摘掉它。前者由注册商设置，注册商自己就能解除，所以如果攻击者骗过了注册商的客服或者拿到了你的账号，这把锁挡不住。后者由注册局设置，注册商也动不了，解锁要走单独的核验流程。本轮130个站里带server级锁的只有21个，其中15个来自CSC和MarkMonitor这两家专做企业品牌保护的注册商。

为什么我的域名上有clientRenewProhibited，是出问题了吗？

大概率不是。ICANN的文档把它描述成一个不常见的状态，通常出现在法律纠纷或域名即将被删除时，但实测里它被一家注册商当成默认配置批量下发了——本轮33个带这把锁的站里有31个来自GoDaddy。合理的解释是它被用在自动续费流程里，防止续费动作被重复触发。如果你确实需要手动续费或者从别的渠道续，会被这把锁挡住，这时候找注册商解除即可。

DNSSEC值得开吗？

看你的DNS托管在哪。Cloudflare、Route 53、Azure DNS这类平台都支持一键签名，剩下的工作只是把DS记录提交给注册商，风险可控。真正的风险在密钥轮换和迁移DNS服务商的时候，签名链一断，开了验证的解析器会直接判定解析失败，也就是网站在一部分用户那里彻底打不开。所以建议先在非核心域名上完整走一遍，再动主域。本轮130个站里只有12个签了，9.2%。

域名到期还剩两个月，要紧吗？

本身不要紧，绝大多数域名开着自动续费。要紧的是支付方式和通知渠道还有没有效——绑定的信用卡有没有过期、账单邮箱有没有人在看。本轮实测里到期不足90天的有17个站，中位数是326天，也就是多数品牌保持在“还有一年”的水位，这是正常状态，不是警报。

换注册商能提升域名安全吗？

能，但先别急着换。本轮数据显示锁的组合几乎完全由注册商的默认值决定，不过绝大多数零售注册商都支持你自己去后台把那三把基础锁勾上，这是免费的，效果和企业注册商默认给你上的client级锁一模一样。真正只有企业注册商能提供的是server级锁和人工核验流程。先把免费的部分做完，再判断要不要为那部分付费。

注册日期能说明这个品牌有多老吗？

不能。注册日期说的是这个域名字符串第一次被人注册的时间，中间可能已经易手过好几次。本轮130个域名里有59个注册于1990年代，最老的一个是1987年，但这些数字对应的是域名的年龄，不是持有者的年龄，也不是品牌的年龄。二手域名交易在注册局记录里通常只留下一次“最后更新”的时间戳，看不出转手过程。

权威参考资料