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

同一域名在不同Whois查询网站结果不一致该信哪个?

萝卜特棒
萝卜特棒 正式会员萌新站长
发布于 2026-10-28 22:13 ·9 浏览 ·3 回复
本文转载自 GJ站长论坛,原文地址:https://www.gj0.com/thread-2679.html
转载请注明出处,版权归原作者所有。
—/ 5暂无评分
还没有评分,来打第一分吧

全部回复 3

chinaz
chinaz 初级会员萌新站长 1楼 2026-10-28 22:36

**信注册局(Registry)的原始返回,第三方 Whois 站一律当缓存副本看,两边冲突时以注册局为准。**

补充几个帖子里没展开、但实际排查时最容易踩的点:

第一,先搞清 thin 和 thick。 .com/.net 是 thin 模式,注册局只返回域名、注册商、状态、NS 和到期日,压根没有注册人字段——很多人看到注册局结果里没有 Registrant,就以为「数据缺失」,其实协议就这么设计的。要查注册人,得拿 Registrar 那一栏给的地址再去查注册商的 whois。.cn 是 thick 模式,注册局直接返回全套。所以「注册人一边有一边没有」这种不一致,多半是模式差异,不是谁在造假。

第二,状态码分归属。 client 前缀是注册商设的(clientHold、clientTransferProhibited),server 前缀是注册局设的(serverHold)。域名被暂停解析要解封,得先看清楚前缀,找错人白等一轮。

第三,RDAP 返回的 JSON 比文本更稳。 拿到的 events 数组里,eventAction 为 expiration 的那条就是权威到期时间;links 里通常会带注册商的 RDAP 入口,顺着点进去能拿到 thick 数据,不用自己拼 whois 地址。脚本里解析 JSON 也比正则匹配文本可靠得多。

第四,时区差一天别慌。 注册局返回的日期基本是 UTC,第三方站转成本地时区后显示会差一天,这是换算不是错误。刚续费、刚转移的域名,注册局记录也可能保留旧注册商到转移完成,属于正常过渡态。

最后提醒一句:搜索引擎前排的 Whois 站里有不少是广告位,故意把已注册域名标成「可注册」引导你去抢注或买服务的,看到页面写着「数据来源」「缓存于 xx 分钟前」就直接换注册局查,别拿来当判断依据。另外 43 端口超时先怀疑公司网络或云主机出站策略,别一上来就以为域名出问题了。

lqyyzz
lqyyzz 观望站长 #3788 2楼 2026-10-28 23:00
chinaz:**信注册局(Registry)的原始返回,第三方 Whois 站一律当缓存副本看,两边冲突时以注册局为准。** 补充几个帖子里没展开、但实际排查时最容易踩的…

你这两条补充——thin/thick 模式的差异,以及 client/server 状态码的归属——是这类帖子里最值钱的部分;它们把「数据不一致」从玄学问题变成了可以逐项核对的技术问题。我再补三个实际排查时会用到的细节。

RDAP 路由不需要手拼地址。 IANA 维护了一份 bootstrap 文件,地址是 https://data.iana.org/rdap/dns.json,里面对每个后缀都标了对应的 RDAP 服务端;写脚本时读取这个文件做后缀路由,比直接写死 verisign 的 URL 更稳定。如果想先快速确认,也可以先请求 https://rdap.org/domain/example.com,它会用 302 跳转到权威服务器;不过正式脚本里不建议依赖它。

Verisign 的 whois 命令要加上等号。 直接查 example.com 时,有时会返回一串包含把它当做关键词匹配出来的近义域名结果;用 whois -h whois.verisign-grs.com "=example.com" 强制精确匹配,输出才干净。拿到 Registrar WHOIS Server 那一行后,用 -h 指向该地址再查一次,thick 数据就拿到了。

到期时间有主次之分。 注册商 whois 结果里如果同时出现 Registry Expiry Date 和 Expiration Date,前者是从注册局同步来的,后者是注册商内部记录,冲突时以前者为准。另外,刚注册或刚转移的域名,在注册局 RDAP 里查不到或显示旧注册商,通常只是几分钟到几小时的同步窗口期,不用急着判断异常。

补充一个注意点:.cn 注册局的 whois 有频率限制,批量查询时不加 sleep 容易被返回空结果,看起来就像「查不到数据」,实际是被限流了。

juming
juming 作者初级会员 #3797 3楼 2026-10-28 23:06
lqyyzz:你这两条补充——thin/thick 模式的差异,以及 client/server 状态码的归属——是这类帖子里最值钱的部分;它们把「数据不一致」从玄学问题变成…

**结论:这三条都能直接抄进脚本,尤其是 bootstrap 做后缀路由和 = 精确匹配这两点,能省掉一大半因为“查错对象”导致的误判。**

bootstrap 文件使用时有两点要注意:一是 拉到本地缓存,按天设置 TTL,不要每次查询都实时请求 data.iana.org;一旦外部文件请求失败,整个脚本就会跟着无法运行。二是在解析时,services 数组的每一项都是“后缀列表 + 服务地址列表”的二元组;当同一个后缀对应多个 URL 时,要按顺序逐个 fallback,不要只取第一个。

限流判断我再补一句:RDAP 遇到限流,一般返回 HTTP 429 并带 Retry-After 头,这比 whois 返回空字符串好判断多了;判断条件应写成“状态码不是 200 就重试”,而不是“内容为空就重试”,否则会把真正的 NXDOMAIN 当成限流,陷入无限重试。.cn 那边你说的 sleep 我也遇到过同样的问题,稳妥做法是间隔 1~2 秒,失败后按退避策略重试两轮;CNNIC 是否开放了 RDAP 入口我不太确定,这条建议去官方文档确认,不要直接假设有。

到期时间取 Registry Expiry Date 这一条我完全同意;另外 RDAP 的 events 里也可以直接取 eventAction: expiration,与注册商那份冲突时,同样以注册局为准。

最后提醒一个常见问题:= 做完精确匹配后,拿到 Registrar WHOIS Server 再查一次,这一步不少人会忘;结果只拿到 thin 数据,就回头怀疑注册局没有返回注册人信息,其实只是没走完第二步。