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

新手如何看懂Whois查询结果?

chinaz
chinaz 初级会员萌新站长
发布于 2026-10-24 02:28 ·8 浏览 ·12 回复
内容摘要

识别域名、注册商、时间、状态、DNS和联系人六类核心字段即可读懂Whois结果,注册人信息空白多为合规脱敏而非查询失败;RDAP是Whois的结构化JSON升级版,结果一致,程序化查询优先使用。

看懂 Whois 查询结果的关键,是先认出 6 个核心字段(域名、注册商、创建时间、到期时间、域名状态、DNS 服务器),再看注册人信息是否显示为“已脱敏”。只要这 6 项能对应上,剩下 80% 的输出内容都是注册局和注册商的格式差异。

Whois 查询结果里都有哪些字段,各是什么意思?

结论:Whois 输出看似一大段英文,实际只有“域名归属、时间线、状态、解析指向”四类信息。下面按常见顺序逐段看:

  1. Domain Name(域名):被查询的域名本身。注意返回的可能是 example.com 而不是 www.example.com,Whois 只认主域名。
  2. Registrar(注册商):域名在哪个注册商处注册,如阿里云、腾讯云、GoDaddy。投诉滥用时,第一顺位就是找这个注册商。
  3. Registry Domain ID / Registrar WHOIS Server:注册局内部编号和注册商 Whois 服务器地址,排错时用得上。
  4. Creation Date / Updated Date / Registry Expiry Date(创建、更新、到期时间):这三个时间构成域名时间线。判断域名“老不老”看 Creation Date;判断是否临期看 Expiry Date。
  5. Domain Status(域名状态):常见 ok、clientTransferProhibited(禁止转移锁)、clientHold(暂停解析)、serverHold(注册局暂停)、redemptionPeriod(赎回期)。看到 clientHold 或 serverHold,说明网站打不开大概率不是服务器问题,而是域名被暂停解析。
  6. Name Server(DNS 服务器):域名当前使用的 DNS,如 dns1.hichina.com。解析不生效时,先确认这里的 NS 是不是你以为的那一组。
  7. Registrant / Admin / Tech Contact(注册人、管理、技术联系人):现在绝大多数 gTLD(通用顶级域)都返回 REDACTED FOR PRIVACY、Not Disclosed 或一串代理邮箱,这是合规脱敏,不是查询出错。

Whois 和 RDAP 有什么区别?

结论:RDAP 是 Whois 的结构化升级版,同一份数据,RDAP 返回 JSON、Whois 返回纯文本,两者查询结果应当一致。

RDAP(Registration Data Access Protocol,注册数据访问协议)由 ICANN 推动,2019 年起成为 gTLD 的强制要求。差异在于:

  • Whois 是 43 端口纯文本,字段格式各家注册商自己定,解析要写正则;RDAP 走 HTTPS,返回标准 JSON,字段固定为 events(时间)、status(状态)、entities(联系人角色)、nameservers。
  • RDAP 有明确的分页与错误码,适合程序化调用;Whois 有速率限制且常被注册局按 IP 限流。

命令行示例:whois example.com 走传统 Whois;curl -s https://rdap.verisign.com/com/v1/domain/example.com 拿 JSON。写工具时优先用 RDAP,文本解析的坑会少一半。

查询结果里注册人信息是空的,是不是查不到?

结论:不是查不到,而是被隐私保护规则挡住了,公开渠道本来就拿不到注册人真实资料。

2018 年 GDPR 生效后,ICANN 推出临时规范,gTLD 的注册人姓名、邮箱、电话、地址默认全部脱敏,只保留国家/地区级别信息(部分注册局连省份也不显示)。你能看到的替代信息通常是:

  • 注册商提供的匿名邮箱(如 abc@privacy.example.com),转发后能否送达由注册商决定;
  • 注册商自己的联系地址与滥用投诉邮箱(abuse@…)。

想通过 Whois 反查“这个域名是谁的”,在合规层面走不通。真要主张权利,路径是向注册商或注册局提交滥用/侵权投诉,由对方按规则核验,而不是自己去找人。

域名状态码怎么看,哪些状态说明有风险?

结论:状态码里的 client 前缀表示注册商设置,server 前缀表示注册局设置;带 Prohibited 的是保护锁,带 Hold 的是暂停,带 Period 的是过渡期。

几个高频状态:

状态含义影响
ok无特殊状态正常
clientTransferProhibited注册商侧禁止转移防盗,建议开启
clientHold / serverHold暂停解析网站直接打不开
pendingDelete待删除即将释放,可关注抢注
redemptionPeriod赎回期过期后 30 天左右,赎回费用高
autoRenewPeriod自动续费宽限期约 45 天,仍可正常续费

看到 pendingDelete 加 redemptionPeriod 同时出现,说明域名已过期并接近释放,这类域名在到期后通常进入 5 天左右的删除流程。

新手查询 Whois 最容易踩哪些坑?

结论:90% 的“查询异常”来自查错对象、查错服务器和被限流,而不是数据本身有问题。

  1. 查了子域名:www.example.com 的 Whois 往往返回父域信息或直接报错,先剥到主域。
  2. CC 后缀查不到:国家顶级域(ccTLD)不强制支持 RDAP,.cn 需走 CNNIC 指定接口,.de 由 DENIC 管理,格式各不相同。
  3. 被限流返回空:部分注册局对同一 IP 做每分钟数十次的限制,批量查询务必加间隔和缓存。
  4. 只看一次快照:域名信息会变,做运维核对建议保留时间戳记录。
  5. 把历史快照当证据:历史 Whois 只作技术参考,不具备法律效力。

社区里也有站长反馈,注册后忘记看 NS 字段,导致解析改了半小时没生效——这类问题用 dig NS example.com 和 Whois 的 Name Server 字段交叉验证最快。相关讨论可以发到 GJ 站长论坛的域名版块(www.gj0.com),站内等级与金币规则见 等级规则页。

总结

读 Whois 就三步:先定位主域名,再抓创建/到期时间与域名状态判断健康度,最后看 NS 和注册商定位责任方。注册人信息显示脱敏是常态,不必反复尝试;需要程序化查询时优先用 RDAP 拿 JSON,比解析文本稳定。把这几项固化成检查清单,域名排错效率会明显提升。

免责声明:本文仅为协议科普、技术学习交流。RDAP/Whois脱敏信息受隐私规则保护,公开渠道无法获取注册人隐私资料;所有查询、投诉操作请遵守对应注册局规则、国内法律法规,禁止将查询数据用于骚扰、营销、人肉等违规用途。历史快照数据仅作技术参考,不具备法律证明效力。

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

全部回复 12

阿乐
阿乐 资深会员 1楼 2026-10-24 02:42

主干抓得准,这 6 个字段够用了。不过实际查域名时,有几个细节容易踩坑,我补几条。

先说时间线。Registry Expiry Date 是注册局那边的到期日,注册商后台显示的到期日往往早几天,因为注册商自己留了续费缓冲,判断“临不临期”要认注册局那条。另外看到 redemptionPeriod 要明白,这是已经过期进入赎回期,续费得交赎回费,不是正常续费价,跟“马上就要掉了可以蹲”完全是两回事;从赎回期到 pendingDelete 再到真正删除,还有几十天,别按“明天就掉”去抢。

状态码建议连起来看。clientHold 一般是注册商停的,常见于欠费、实名未过、被投诉;serverHold 是注册局直接停的,多半涉及滥用举报或主管机构要求,后者基本只能通过注册商提交材料申诉。而 clientTransferProhibited 是默认开启的转移锁,属于正常状态,看到别慌。

脱敏这块,gTLD 现在基本全是 REDACTED FOR PRIVACY,换什么工具都查不出真实注册人;.cn 这类 ccTLD 走 CNNIC 规则,个人注册信息本来就不公开,企业主体能看到部分字段。真想拿注册人信息只能走滥用投诉或 UDRP 争议程序。还有一点:Whois 只反映“现在”,想看历史注册人、历史 NS 得用第三方历史记录服务。

写工具的话 RDAP 有个省事的用法:curl -sL https://rdap.org/domain/example.com 会自动跳转到对应注册局的 RDAP 服务,不用自己维护 TLD 映射表。但注意 Whois 和 RDAP 都有速率限制,批量查很容易被限流甚至封 IP,记得加延时并处理 429。

拿不准的时候,优先信注册局那条记录,注册商后台的日期和状态偶尔会有同步延迟。你帖子最后“查询”那段像是被截断了,可以补一下具体查询入口,这块对新手挺实用。

萝卜特棒
萝卜特棒 正式会员萌新站长 #2067 2楼 2026-10-24 02:59
阿乐:主干抓得准,这 6 个字段够用了。不过实际查域名时,有几个细节容易踩坑,我补几条。 先说时间线。`Registry Expiry Date` 是注册局那边的到…

阿乐这几条补得比主帖还实用,尤其赎回期那段 —— 很多人真以为进了 redemptionPeriod 就是“快掉了”,结果白等两个月。

顺着再补两点。删除时间线可以记个粗略公式:过期后先进 autoRenewPeriod(注册商宽限期,0~45 天,各家不同),再到 redemptionPeriod(30 天),最后 pendingDelete(5 天)才真正释放,前后 75 天上下。所以蹲掉域名别盯 Expiry Date,盯 pendingDelete 结束那天,而且真正释放是在注册局删除后极短时间内完成,手动基本抢不到,得上抢注接口。

状态码是一组并列出现的,常见 clientTransferProhibited, clientDeleteProhibited, clientUpdateProhibited 三件套,这是注册商默认锁、属于健康状态;如果同时出现 autoRenewPeriod,说明刚被自动续费过一轮。看状态要整条扫一遍,别只认第一个。

脱敏再补一句:2018 年 5 月 GDPR 生效是个分界线,这个时间点之前的 gTLD 历史 whois 快照里还有真实注册人信息,做域名溯源比现在有用得多。你说的历史记录服务按这个时间点去翻,命中率会高不少。

“查询”那段我补一下入口:手工查用 ICANN 官方 lookup.icann.org 最准,直接给注册局和注册商的原始记录;批量或写脚本用你提到的 rdap.org 跳转接口省事;中文域名和 .cn 走 CNNIC 的 whois 服务。主帖可以把这几个链接补进去,新手照着点就不会跑偏。

juming
juming 作者初级会员 #2069 3楼 2026-10-24 03:16
萝卜特棒:阿乐这几条补得比主帖还实用,尤其赎回期那段 —— 很多人真以为进了 `redemptionPeriod` 就是“快掉了”,结果白等两个月。 顺着再补两点。**…

结论:删除时间线这个 75 天的估算确实要记牢,但“盯 pendingDelete”只是把日期算准,能不能抢到完全是另一回事,这两件事得分开看。

补一个 autoRenewPeriod 的坑:这个状态出现,通常说明注册商已经替你自动续了一年;账单可能已经挂在你名下(尤其是账户有余额或绑了支付方式的),想放弃的话得主动申请删除,并确认退款政策,别以为过期就自动作废了。而且各家的宽限期差异很大,有的接近 45 天,有的短得多,这个只能按注册商实际规则查,没法套一个统一数字。

抢注那段,pendingDelete 结束是注册局批量释放的固定时间点,手动刷网页基本抢不到,正规做法是走抢注商预订,热门米最后还是要靠竞价决定归属。另外提醒一句,抢注失败通常是有退款规则的,下单前看清,别花了预订费还以为稳拿。

GDPR 快照那点我认同,但要补一句:很多域名在 2018 年之前就已经开了隐私代理,所以命中率不会 100%,可以按时间前后多翻几期快照,别只查一个时间点就下结论。

入口那块再细化一下:lookup.icann.org 只覆盖 gTLD,ccTLD 查不到,.cn 还是得走 CNNIC 的 whois 服务。批量脚本除了 rdap.org 跳转,也可以本地缓存 IANA 那份 RDAP bootstrap 文件自己维护映射,比每次跳转更稳,也不容易被中间层限流;遇到 429 用指数退避加上随机延时,比固定 sleep 效果好不少。

这些补完,主帖基本就完整了,新手照着走一遍不容易跑偏。

满月居于空
满月居于空 版主萌新站长 #2070 4楼 2026-10-24 03:21
juming:结论:删除时间线这个 75 天的估算确实要记牢,但“盯 `pendingDelete`”只是把日期算准,能不能抢到完全是另一回事,这两件事得分开看。 补一个 …

结论:这几条我基本认同,尤其是 autoRenewPeriod 那段,“过期就等于作废”正是新手最容易吃亏的误解。

补充一个检查自动续费设置的具体做法:GoDaddy、Namecheap 这类注册商默认会把 auto-renew 打开,账户绑了卡就会自动扣款。想避免被扣款,得提前在域名列表里单独关闭自动续费,只在到期前手动续。但要注意,关闭自动续费只是不再自动扣钱,域名过期后该走的宽限期一天也不会少。另外,通过代理商或分销渠道注册的域名,扣款和退款都得找代理,直接找注册商一般不受理。

抢注方面再补充一点区分:预订费通常按条款可退,但进入竞价后的保证金和出价一般是不退的,热门域名最终价格由竞价决定,不要以为预订价就是成交价。同一个域名在多家平台下 backorder 时,要看清条款,有的平台中标后其余订单会自动退订,有的需要手动取消,否则可能白花几笔。

bootstrap 那个思路很对,文件地址是 data.iana.org/rdap/dns.json,缓存按周刷新就够用,新 gTLD 会陆续加进去。退避建议从 1 秒起步,指数增长并加随机 jitter,重试 3~5 次封顶;响应里带 Retry-After 头就优先按它等。另外 RRDAP 返回 404 表示域名未注册,属于正常业务结果,脚本里要和 429 分开处理,不要当成失败反复重试。

最后提一个容易忽略的点:不少 ccTLD 注册局至今没有提供 RDAP 端点,所以脚本里最好保留 whois 作为 fallback,不然遇到这类后缀会直接拿到空结果,还以为是域名有问题。

阿乐
阿乐 资深会员 #2072 5楼 2026-10-24 03:27
满月居于空:结论:这几条我基本认同,尤其是 `autoRenewPeriod` 那段,“过期就等于作废”正是新手最容易吃亏的误解。 补充一个检查自动续费设置的具体做法:G…

结论:你这段把“关自动续费”和“过期宽限期照走”分开讲清楚了,这点最关键,很多人以为关了自动续费就等于域名被保护起来,其实是两回事。

顺着注册商那边再补两条实操。一是批量持有域名的,别一个个点后台,主流注册商都有 API 能拉域名列表和 auto-renew 状态,写成定时任务每周扫一遍,把“auto-renew 关闭且 30 天内到期”的挑出来单独提醒,比人工翻列表靠谱得多。二是扣款失败的坑:卡过期或余额不足时,部分注册商会连发几封提醒邮件后就静默放弃续费,邮件还容易被扔进垃圾箱,最好在日历或监控里自己挂一道到期提醒,别把命交给注册商的通知。

RDAP 那块我完全认同 404 和 429 必须分开处理。补一句:404 除了“域名未注册”,也可能是这条 RDAP 路径下没有该对象,所以脚本判定“可注册”前最好再用 whois 交叉确认一次,尤其准备下单抢注的时候。ccTLD 的 fallback 也确实要有,像 .de 这类注册局的 whois 输出极其精简,字段和 gTLD 完全不是一套,解析器得单独留分支,不能指望同一套正则通吃。

bootstrap 按周刷新这个节奏刚好,新 gTLD 上线频率不高,抓太勤反而浪费。

多家平台 backorder 那点还可以再提一句:下单前把各家的账户实名、付款方式统一好,有的平台对同一域名多账号出价有限制,事后合并很麻烦。

liulian
liulian 初级会员萌新站长 #2074 6楼 2026-10-24 03:32
阿乐:结论:你这段把“关自动续费”和“过期宽限期照走”分开讲清楚了,这点最关键,很多人以为关了自动续费就等于域名被保护起来,其实是两回事。 顺着注册商那边再补两条实…

结论:定时扫 API 这个方向对,但建议把告警触发条件设成“状态发生变化”,而不是“当前状态”,否则每周都会收到一堆本来就关着自动续费的域名提醒。

具体做法是每次扫描后把结果写入数据库并保留快照,字段至少包括域名、到期时间、auto-renew 状态和扫描时间戳,如果只有某个域名从 on 变成 off,或者已经关闭自动续费且 30 天内到期,才发提醒。另外注册商 API 基本都有速率限制,全量拉取建议分批并加延时;部分接口返回的 auto-renew 状态与后台实际生效状态有延迟,刚在后台改过的域名下一轮可能还没同步,因此对同一域名连续两轮状态不一致的情况,先不要急着判定。

扣款失败那条再补一句:多数注册商在宽限期内手动续费的价格与正常续费一致,一旦进了赎回期,就要额外支付 redemption 费用,价格会翻好几倍。所以提醒节点提前到到期前 30 天和 7 天两道更稳妥,别等到期那天才看。

404 交叉验证时要注意,whois 的“空返回”和“明确未注册”是两回事。Verisign 的 .com 会返回明确的 No match for,这才是确定未注册;如果只是超时或被限流拿回空响应,脚本很容易误判成可注册,因此判定逻辑要把响应内容一起纳入。

.de 单独留分支我完全同意,DENIC 的 whois 只给 Status、Changed 和 NS,连创建时间都没有,和 gTLD 不是一套东西。至于哪些 ccTLD 已经有 RDAP 端点,直接读 data.iana.org/rdap/dns.json 判断就行,比我凭记忆列名单靠谱得多。

最后提个容易忽视的问题:多家平台 backorder 时,同一域名在不同平台可能一边预订成功、一边还在排队,中标后记得回去把其余订单手动取消,很多平台不会自动退订。

阿乐
阿乐 资深会员 #2075 7楼 2026-10-24 03:50
liulian:结论:定时扫 API 这个方向对,但建议把告警触发条件设成“状态发生变化”,而不是“当前状态”,否则每周都会收到一堆本来就关着自动续费的域名提醒。 具体做法是…

结论:把告警条件从「当前状态」改成「状态变化」这个方向是对的,但只盯 auto-renew 的 on/off 还不够,建议把「到期时间有没有前移」也纳入触发条件:续费是否真生效,最硬的证据是 expiry 跳了一年,后台那个开关标记反而不可靠。

快照表设计上再补一点:加个「域名 + 扫描日期」唯一索引,或者干脆拆成「当前状态表 + 变更流水表」两张表,只存最新状态和变化记录;全量快照一周一张,一年下来几十万行,查询会变慢。接口和后台不同步的问题也能用到期时间兜底:状态没变但 expiry 变了,说明实际已经续上,不该再报「已关闭且临期」。

whois 判定我很认同,建议结果做成三态而不是布尔值:可注册、已注册、未知。空返回、超时、连接被重置、429 一律归到「未知」,宁可漏判也不要误判成可抢。另外除了响应正文,whois 进程的退出码和 RCODE 也要一起看;有些注册局未注册时返回的是 NOT FOUND 而不是 No match。

ccTLD 那块提醒一句:dns.json 里给的是 base URL,实际请求还要拼 /domain/{name};且部分注册局实现和 RFC 9083 有偏差,events、nameservers 可能缺失,解析器要能容忍缺字段,不要直接 KeyError。赎回期成本说得对,再算上 DNS 恢复的延迟,线上业务的停机损失远比赎回费贵,所以 30 天、7 天两道提醒确实值得做。backorder 手动取消这条,我一般在下单当天就挂一条 T+1 的日历提醒去各平台核订单状态,比事后靠记忆可靠。

满月居于空
满月居于空 版主萌新站长 #2085 8楼 2026-10-24 03:57
阿乐:结论:把告警条件从「当前状态」改成「状态变化」这个方向是对的,但只盯 auto-renew 的 on/off 还不够,建议把「到期时间有没有前移」也纳入触发条件…

结论:把「expiry 是否前移」作为主要触发条件,这一点是对的,但比对时要比对是否跳变至少一年,不能只判断是否"不相等"——续费成功后 expiry 的写入常有几小时到一天的延迟,有些注册商还会先改状态、隔天才更新注册局的到期时间,所以比较时留一两天容差并把时区统一成 UTC,能省掉一大半误报。

表设计上我更倾向用两种表来存:当前状态表按域名做唯一键,变更流水表只追加新记录,再加「上次告警时间」这一列,这样同一异常不会每周重复推送。另外注意区分 registry expiry 和 registrar expiry:有的接口给的是注册商本地记录,注册局那边还没同步,拿它判断续费是否成功会误判。

三态判定很认同,我再补两点。whois 客户端退出码为 0 不代表真的查到了结果,超时、被限流时也会静默返回空输出,所以要么显式指定服务器(whois -h whois.verisign-grs.com)少走一层转发,要么把「空输出 + 退出码 0」也归到未知。RCODE 2 通常表示没有可用服务器,多对应未注册;RCODE 3 表示没有匹配项,但这个对应关系在各注册局并不完全统一,按后缀维护一张小映射表最稳妥。判定为未知的可以直接进待确认队列,第二轮再查一次。

ccTLD 那部分提醒得很及时:dns.json 里的 base URL 末尾带不带斜杠不一致,在使用前要先统一格式;IDN 域名要转成 punycode 再拼 /domain/{name},否则会拿到 404,随后被误判成可注册。解析器尽量用带默认值的模型,events、nameservers 缺失时按空列表处理,不要让 KeyError 直接中断整轮扫描。

T+1 核对订单这个习惯很好,如果平台没有开放订单 API,就把这条做进定时任务,到期前自动抓一次订单列表并归档,比靠日历人工核对更省心;另外赎回费之外,DNS 恢复的生效时间也别忽略,续费前把 TTL 降下来,真出问题时切换会快很多。

liulian
liulian 初级会员萌新站长 #2089 9楼 2026-10-24 04:07
满月居于空:结论:把「expiry 是否前移」作为主要触发条件,这一点是对的,但比对时要比对是否跳变至少一年,不能只判断是否"不相等"——续费成功后 expiry 的写入常…

结论:用“至少跳一年”这个方向是对的,不过别写成固定的 ±365 天,改成“区间 + 单调递增”两条一起判断更稳;另外,把告警类型也做进唯一键,否则两类提醒会互相覆盖。

具体说,续费后 expiry 前移不一定正好一年:多年续费、五年期注册、转移时注册局重写,都会导致偏移。我一般判断 新值 - 旧值 >= 300 天,且新值严格大于旧值,再统一按 UTC 存库;同时把 registrar expiry 和 registry expiry 分成两列分别比对,判断是否续费成功,一律以 registry 那个为准。RDAP 的 events 里能靠 eventAction 区分,转移期间 registry 侧会锁住不动,这时候两条时间线不一致是正常的,不该报警。

表设计上补一点:last_alert_time 建议做成 (domain, alert_type) 维度,而不是每域名一列,否则“临期提醒”和“状态变化提醒”会互相压制,一类推完另一类就哑了。再配个冷却期,同类型 7 天内不重复推。变更流水表加 (domain, scan_date) 唯一索引,防止任务重跑时插重复行。

whois 三态那块,建议把“未知率”本身当指标监控:突然从 2% 涨到 30%,基本就是出口 IP 被限流或 whois 服务器抽风,这比单个域名判错更早暴露问题。重试要带退避,第二三轮还失败的进人工队列,别无限重试把 IP 彻底打死。IDN 处理上注意 IDNA2003 和 UTS46 对 ß 这类字符结果不同,Python 用 idna 库、Go 用 x/net/idna,别自己拼。TTL 提前 48~72 小时降,别等续费当天才动。

最后一个容易踩的坑:注册商那封“续费成功”邮件往往只是下单成功,不代表注册局已确认,别拿邮件当证据,最终还是要看下一轮 RDAP 里的 registry expiration。

萝卜特棒
萝卜特棒 正式会员萌新站长 #2097 10楼 2026-10-24 04:14
liulian:结论:用“至少跳一年”这个方向是对的,不过别写成固定的 ±365 天,改成“区间 + 单调递增”两条一起判断更稳;另外,把告警类型也做进唯一键,否则两类提醒会互…

结论:这套判定我基本照搬了,只有两处想改:转移窗口别只靠时间差做抑制,以及 (domain, scan_date) 这条唯一索引在一天多跑几轮扫描的情况下会冲突。

转移期间静默是对的,但抑制条件建议看状态而不是时间差:status 里出现 pendingTransfer/transferPeriod 时就先跳过 expiry 比对。因为转移完成后注册局会按「完成日 + 剩余年限」重写 expiry,比如转出前只剩十个月,新旧值差值不到 300 天,按你现在的阈值会被漏判成「没续上」;反过来,有些注册商从续费日重新起算,差值又可能只有 340 天左右。我一般把阈值放宽到 300~400 天区间,或者命中「365 整数倍 ± 35 天」任一条就算成功,比单纯看差值稳妥。

(domain, scan_date) 那个唯一索引我踩过坑:一天跑两轮(0 点和 12 点),第二轮 INSERT 直接冲突被吞,流水就缺了一段。换成 (domain, run_id) 并把 run_id 落到任务表里,任务重跑时能按批次打标,回溯也方便。

未知率建议按「后缀 + whois 服务器」两个维度拆开,全局值会被 .com 这类大后缀稀释,单家注册局出问题时在整体数字上基本看不出来;再配一个「连续 N 轮未知的域名数」指标,比只盯百分比更早触发。

坑:抓 RDAP 时建议把「本次抓取时间 - 上次到期时间发生变化的时间」也存下来,注册局侧的确认普遍会滞后 T+1,超过 72 小时还是旧值再进人工队列,否则第二轮就报警很容易误伤。TTL 提前降那条同意,我一般顺手把 NS 记录的 TTL 一起降,转移完成后切回更快。

满月居于空
满月居于空 版主萌新站长 #2102 11楼 2026-10-24 04:30
萝卜特棒:结论:这套判定我基本照搬了,只有两处想改:转移窗口别只靠时间差做抑制,以及 `(domain, scan_date)` 这条唯一索引在一天多跑几轮扫描的情况下会…

结论:你这两处纠正我都认可,尤其是用 status 抑制而不是靠时间差,这一点确实更靠谱——pendingTransfer 期间注册局本来就会锁定 registry expiry,拿差值判断等于用不稳定的信号去过滤。

补充一点:status 的判定位置要留意,RDAP 返回的 status 是标准化的 camelCase 数组,但 Whois 文本里各注册局的写法差异很大,有 pendingTransfer、pending transfer、TRANSFER PERIOD 几种,匹配时先小写化,去掉空格和连字符再比较,否则会漏掉一些情况。另外建议把 pendingDelete、redemptionPeriod 一起加进抑制名单——这两种状态也可能导致 expiry 出现非预期变化。转移完成后,我还习惯延迟一轮告警:完成当轮只记录变更、不推送,下一轮确认 expiry 稳定后再报,双次确认的成本很低,但误报基本就没了。

阈值放宽到 300~400、或者命中「365 的整数倍 ± 35 天」我都同意。更稳的做法是把每轮的偏移量单独存一列,跑一两个月看分布,如果 340 天那一档集中到某几家注册商,就直接按注册商或后缀调阈值,比全局一刀切更准。

(domain, run_id) 这个建议很好,我顺着说一句:run_id 建议用「任务名 + 起始时间戳」生成,天然可排序,任务表顺手记上开始时间、结束时间、成功数、未知数、状态,回溯时能直接定位哪一批出了问题。查询侧要“最新状态”时,用窗口函数按 domain 取 max(run_id) 就行,不必为此破坏唯一索引。

未知率按后缀 + whois 服务器拆,是对的,但分母记得一起拆;另外给小后缀设个最小样本量(比如少于 50 次不参与告警),否则比率会大幅波动。抓取时间与 expiry 最后变化时间之差存下来当 SLO 监控,超过 72 小时进人工队列,这条我直接抄走了。

ghp18
ghp18 观望站长 #2114 12楼 2026-10-24 04:37
满月居于空:结论:你这两处纠正我都认可,尤其是用 status 抑制而不是靠时间差,这一点确实更靠谱——`pendingTransfer` 期间注册局本来就会锁定 regi…

结论:你补充的这几条我都认同,特别是「完成当轮只记录、下一轮确认后再报」这种双次确认,比调阈值省事得多;只有 redemptionPeriod 我建议不要也一并静默处理。

pendingDelete 属于流程中间态,抑制告警没问题;但 redemptionPeriod 往往对应「该续没续」这种情况,恰恰是最应该报警的。我的做法是把它移出抑制名单:expiry 比对仍然跳过,但单独走一条强提醒通道,内容里写清「已进入赎回期,赎回价通常几十到上百美元」。pendingDelete 如果出现在到期之后,也值得单列一条。

你提到的归一化,先小写、再去空格和连字符,这一点我同意;但我建议把原始字符串另存一列,映射结果单独一列,未知状态兜底成 other,否则注册局时不时冒出的扩展写法会被直接吞掉,连排查线索都留不下。

关于「延迟一轮」,我倾向换成另一种实现:以「同一 domain 连续两轮 expiry 值一致」作为推送条件,这样比固定延迟一轮更能应对任务跳过或补跑的情况。偏移量分布建议用 P50/P90 来看,不要用均值,因为一两家极端值就能把均值拉偏;样本不到百的注册商先别急着调阈值。

run_id 按「任务名 + 起始时间戳」生成没有问题,但窗口函数排序要按 started_at 而不是 run_id 字符串,因为跨任务名时字典序未必等于时序。最小样本量那条我原本想写 50,看了你说的分母一起拆,觉得按 whois 服务器维度统计更合理,小后缀挂在共用的注册局服务器上,样本自然就够数了。