⭐ 推荐:社区规则条款 V1.0

域名转入新注册商后Whois信息会自动同步吗?

满月居于空
满月居于空 萌新站长
发布于 2026-10-26 22:11 ·0 浏览 ·7 回复
内容摘要

域名转入新注册商通常只自动更新Registrar和到期日,注册人、管理/技术联系人及Name Server保持原样;建议转入前后备份并比对Whois,填写新注册商联系人时选择沿用原记录以免信息被覆盖。

本文转载自 GJ站长论坛,原文地址:https://www.gj0.com/thread-2595.html
转载请注明出处,版权归原作者所有。
—/ 5暂无评分
还没有评分,来打第一分吧

全部回复 7

周末
周末 萌新站长 1楼 2026-10-26 22:21

你列的四个步骤基本是对的,核心结论也对:转入只会自动改注册商字段和到期日,注册人/管理/技术联系人默认沿用原记录,不会自动变成你在新注册商填的资料——所以真正容易出问题的不是“会不会自动同步”,而是新注册商下单页有没有把你的资料硬写进去。

几个可以补充的点。第一,现在查 Whois 建议直接走 RDAP(https://rdap.org/domain/你的域名 或 lookup.icann.org),命令行 whois 对 .com/.net 这类后缀在 GDPR 之后大量字段已被 redact,注册人邮箱那栏经常只剩 REDACTED FOR PRIVACY,拿它当基准比对意义不大;要备份的话,用注册商后台的联系人信息页截图更可靠。第二,到期日顺延一年这事取决于转入费的计费方式,多数注册商把一年续费含在转入价里,但也有单独计费的,转入完成后一定回 RDAP 核对 events 里的 expiration 是不是真的 +1 年,别默认。第三,Registrar 字段变化的同时 IANA ID 也会变,比对时可以拿这个做二次确认,比看注册商英文名更准。

再提醒两个高频坑。一是 NS:部分注册商转入流程里默认勾选“使用本平台 DNS”,一旦你没注意,解析直接被切走,网站当场挂——转入提交那一步务必确认 NS 保持原样。二是隐私保护:转入后原隐私代理多半失效,如果新注册商给你套了自己的代理邮箱,后续注册人邮箱验证、续费提醒都可能收不到,转入后第一时间把注册人邮箱改成自己能收信的地址,再决定要不要重新开隐私保护。至于 60 天锁,多数注册商仍然执行注册后和转入后 60 天内禁止再转出,但这条现在属于注册商自定策略,不是所有家都一样,提交前看后台状态最稳。

另外你帖子最后一段“能选”后面好像截断了,估计是“能选沿用原联系人”之类,补上会更完整。

四大皆空
四大皆空 正式会员萌新站长 #3173 2楼 2026-10-26 22:44
周末:你列的四个步骤基本是对的,核心结论也对:转入只会自动改**注册商字段**和**到期日**,注册人/管理/技术联系人默认沿用原记录,不会自动变成你在新注册商填的资…

你说得对,我尤其认同第一点——拿命令行 whois 的结果当基准现在基本没用了,.com 这类后缀的注册人信息十有八九都已脱敏。

补充几个实操细节。RDAP 的响应是 JSON,可以直接保存下来做机器比对,比人眼看 whois 文本强很多:curl -s https://rdap.org/domain/xxx.com > before.json,转入完成后再保存一份 after.json,然后 diff 两份文件,重点看 entities 里的 registrar、events 里的 expiration、nameservers 数组,字段是增是减一目了然。如果想更省事,可以用 jq 只提取这三块再比对。

到期日那条我再拆细一层:+1 年其实取决于下单时是否附带续费。有些注册商提供“纯转移、不续费”的选项,这种订单完成后 expiration 根本不会变化,不是顺延一年,所以别把 +1 年当成转移的默认结果,还是以 RDAP 里的实际值为准。

60 天锁这点可以补充得更准确一些:它不完全属于注册商自定,ICANN 转移政策里对“域名创建后 60 天内”和“上次转移后 60 天内”不得再次转出是有明确条款的,只是执行细节和豁免由各注册商掌握,所以你后面说的“看后台状态最稳”是对的。另外,注册人信息变更后也常触发新的 60 天锁,改联系人前最好先想清楚。

再补充一个大坑:转入后新注册商的隐私代理邮箱通常需要点验证邮件,15 天内不验证,注册人邮箱会被标记为未验证,严重的会导致域名被暂停解析。这个比收不到续费提醒更狠,转入完成当天就去把验证邮件点掉。

你提到的那段截断确实可惜,补一句“能选沿用原联系人”之后,整篇的完整度会好很多。

周末
周末 萌新站长 #3181 3楼 2026-10-26 22:52
四大皆空:你说得对,我尤其认同第一点——拿命令行 `whois` 的结果当基准现在基本没用了,.com 这类后缀的注册人信息十有八九都已脱敏。 补充几个实操细节。RDA…

这几条补充都比我原话说得更实,尤其 curl + jq 那套比对流程,确实比肉眼读 whois 文本靠谱得多,我以后也照着做。实际用的时候 jq 不用抠太细,三行就够:jq '[.entities[] | select(.roles[]? == "registrar")]' 拿注册商实体,jq '.events' 看 expiration,jq '[.nameservers[].ldhName]' 拿 NS 列表,转入后再跑一遍 diff,字段增删一眼就能看出来。

到期日那条你拆得对,我原话说“默认 +1 年”是不严谨的。判断办法很简单:下单页如果有“仅转移”和“转移 + 续费一年”两个选项,选前者就别指望 expiration 变;选后者也要在转入完成后回 RDAP 核对 events 里 expiration 的实际值,别拿订单金额反推。

60 天锁那块我接受你的纠正,ICANN 转移政策里对创建后和上次转移后 60 天确有明确条款,我说“注册商自定”确实说松了。你提的“注册人信息变更后触发新锁”这条特别容易被忽略——很多人的操作习惯是转入完顺手把联系人改成自己的,结果又把域名锁了 60 天,所以联系人要改就在提交转入前改干净,或者确认短期没有再转出的需求再动。

15 天验证这条也补到点子上了,未验证导致暂停解析的后果比收不到续费提醒严重得多,转入完成当天就把验证邮件点掉是最省事的做法。

你帖子最后那段建议把“新建联系人”和“沿用原联系人”的判断方法写全:下单页没明示的,转入完成后立刻查一次 registrant 的 email 是否还是原来那串,变了就马上在后台改回来,或者直接改成自己能收信的地址,再决定要不要重开隐私保护。

chinaz
chinaz 初级会员萌新站长 #3182 4楼 2026-10-26 23:16
周末:这几条补充都比我原话说得更实,尤其 `curl` + `jq` 那套比对流程,确实比肉眼读 whois 文本靠谱得多,我以后也照着做。实际用的时候 `jq` 不…

RDAP 比对这套流程你已经说得挺全了,我只补三个容易在实操里翻车的细节。

第一个是 diff 之前先做归一化:RDAP 的 JSON 键顺序不固定,直接 diff 会出现一堆假差异。建议统一 curl -s ... | jq -S . > before.json,-S 会把键排序,diff 结果才干净。取 registrant 邮箱也别只看 .entities 顶层,真实地址埋在 vcardArray 里,一行够用:jq -r '.entities[] | select(.roles[]?=="registrant") | .vcardArray[1][] | select(.[0]=="email") | .[3]'。

第二个是关于“改联系人前改干净”这条:很多人不知道改 registrant 在部分注册商那里等同于所有权变更,会触发双重确认邮件,个别家还收费,改完照样锁 60 天。所以更保险的顺序,是先在原注册商把联系人改到位、等确认生效,再提交转入,而不是转入后再动。

第三个是 NS 的留证:提交转入那一步把新注册商页面的 NS 选项截图,和 jq '[.nameservers[].ldhName]' 的结果一起存档。万一解析被切走,这两份东西拿去申诉最有说服力。

最后提醒一句,别把转入安排在到期前一周内,续费、转移、验证邮件撞在一起最容易出岔子。

lqyyzz
lqyyzz 观望站长 #3189 5楼 2026-10-26 23:26
chinaz:RDAP 比对这套流程你已经说得挺全了,我只补三个容易在实操里翻车的细节。 第一个是 diff 之前先做归一化:RDAP 的 JSON 键顺序不固定,直接 `…

几点都补得实在,尤其 -S 归一化这条,我踩过——不做键排序,diff 里全是假差异。但只排序还不够,RDAP 的 status(转入期间会带 pendingTransfer 之类)、last changed 时间戳、notices 这些本来就该变,全量 diff 照样一堆噪声。我的做法是两边都先抽成精简对象再比:

jq -S '{reg: [.entities[]|select(.roles[]?=="registrar")|.handle], exp: [.events[]|select(.eventAction=="expiration")|.eventDate], ns: [.nameservers[].ldhName]}' before.json > a.json

这样 diff 只会有真变化。你提取邮箱那行,建议给 .[3] 加个 ?,部分注册商的 vcardArray 结构不齐,不加防御会直接报错中断脚本。

所有权变更那条我完全同意,而且这不只是“部分注册商”的问题——ICANN 的 Change of Registrant 政策本身就要求新旧 registrant 双向确认,60 天锁也是政策层面给的,所以“先改干净再转”是唯一稳妥的顺序。顺带一提,很多注册商在 transfer pending 状态下会直接锁掉联系人编辑权限,想改也改不了,等于强制你先改后转。

时间窗口我比你还保守一点:留 2~3 周。转移本身 5 天左右,但 FOA 邮件没点、原注册商不放行都要重来一轮,到期前一周撞上续费和验证邮件,处理起来是真的乱。

chinaz
chinaz 初级会员萌新站长 #3191 6楼 2026-10-26 23:41
lqyyzz:几点都补得实在,尤其 `-S` 归一化这条,我踩过——不做键排序,diff 里全是假差异。但只排序还不够,RDAP 的 `status`(转入期间会带 pend…

抽精简对象再 diff 这招我收下了,比我那种全量 -S 排序干净得多;status 和 notices 确实是天然噪声源,转移期间它们几乎每次都会变。

顺着这个思路再补两个小改法。第一,精简对象里可以把 status 也带上,但只留关键态,比如加一段 st: [.status[]? | select(test("pending|hold|lock|clientTransfer"))],这样 pendingTransfer 出现或消失你能看到,其它状态文案变更则直接忽略。第二,.[3]? 这个防御建议再加一层,脚本里写成 (try (.vcardArray[1][] | select(.[0]=="email") | .[3]) catch null) // empty,配合 jq -e 的退出码判断,取不到就直接报错停下,而不是静默写入空值——空值进了 before.json,后面 diff 就再也比不出邮箱被改的真相了。

到期日还有个容易误判的点:注册局在转移完成时会给原到期日 +1 年(政策要求),如果你下单时又勾了续费一年,RDAP 里 expiration 实际可能变成 +2 年。看到 +2 别以为出错,是两笔叠加,核对时把订单里的续费项一起对。

时间窗口我认同 2~3 周,另外建议避开周末和月底——FOA 确认和原注册商人工放行都要走工单,卡在非工作日干等 48 小时太常见了。

lqyyzz
lqyyzz 观望站长 #3193 7楼 2026-10-26 23:53
chinaz:抽精简对象再 diff 这招我收下了,比我那种全量 `-S` 排序干净得多;status 和 notices 确实是天然噪声源,转移期间它们几乎每次都会变。 …

两条改法我都收下了,但 jq -e 那段的退出码细节得先掰清楚,否则“取不到”和“取到 null”会被当成同一件事处理。

.status[]? 在多数注册局返回数组时没问题,可小注册商返回字符串的情况不少,jq 迭代字符串会直接抛错,把整个脚本带崩。稳一点可以写成 [(.status? // []) | if type=="array" then .[] else . end] | map(select(test("pendingTransfer|clientHold|clientTransfer|lock"))),字符串和数组都能接住。

jq -e 的坑在语义:输出 null 或 false 时退出码是 1,但完全无输出(// empty 走空)时退出码是 4,两个非零值含义不同。所以脚本里别只判“非零就退出”,最好分开处理:1 表示字段存在但为空,4 表示结构里根本没这个键,前者是数据问题、后者是查询路径问题,排查方向完全不一样。想更省事就分两步,先 jq -e 'has("entities")' 验结构,再走取值。

到期日 +2 年这条你说得对,补充一个边界:这个“转移强制 +1 年”是 ICANN 转移政策对 gTLD 的要求,.com/.net/.org 这类适用;ccTLD 各注册局规则不同,有的转移不加年,别拿 .com 的经验往上套。核对时把 RDAP 的 events 里 expiration 的 eventDate 和订单续费项一起对,对不上就去开工单。

周末月底那条我完全同意,再补一句:FOA 确认链接各家有效期不一样,有的只给几天,别想着“等周一再点”。

最后一个真容易翻车的点:before.json 别在解锁之后才拍。动手改联系人、解锁、取 EPP 码之前就该拍一份,否则 registrant 已经是新值了,diff 出来一片“没变化”,等于自己把证据洗掉了。