域名抢注工具的核心技术路径分为四个环节, 这四个环节必须紧密相连。第一个环节是对 DNS 状态进行实时监测。第二个环节是判定域名是否可用。第三个环节是对注册接口进行并发调用。
第四个环节是成功回执确认。只要在任一节点上的延迟时间超过 200ms , 那么就有可能存在被别人抢注的窗口期。接下来我们将按照不同的模块来拆解开发的重点内容。
DNS 监测层：获取"域名刚释放"信号
抢注工具执行的第一步, 实际上就是要在目标域名被正式释放的那个瞬间去捕获相关信号, 而相关的技术方案一共可以分为下面这两类:
TLD 注册局 whois 轮询：针对 .com/.net 等 TLD域名抢注工具开发域名抢注工具开发，以 50ms 间隔轮询 Verisign whois 接口，检测域名状态从"待删除"变为"未注册"的时间点。
其缺陷在于, Verisign 存在 IP 限流机制, 具体规定为每个单独的 IP 地址每分钟大约是能进行 5 次操作, 这种情况下, 就不得不构建起一个包含多个 IP 地址的群体并实行交替轮换的处理方式。
针对 DNS 递归查询探测这一情况, 我们会采取这样的操作步骤。也就是要去向那些根服务器, 以及那个顶级域名的权威服务器, 去发出对于 A 记录, 还有 NS 记录的查询动作。然后要观察返回的结果, 如果发现连续三次都返回了 NXDOMAIN 这个状态码。
并且同时注意到了一个条件, 就是那个_ttl_的值等于 0。当这两个条件都满足的时候, 就可以判定为这个域名是处于可注册的状态的。在这个过程里面, 所花费的时间延迟是可以压缩到 30 毫秒以内的。因为这个原因, 所以它是目前主流的那些抢注系统在选择技术方案时的一个最优先的首选办法。
以那个 gname.xin 公开的开放注册监控 API 作为一个例子来说, 它的接口返回的字段里面, 包含了域名当前的注册状态是怎么样, 还有下次删除的时间戳是多少, 以及注册局代理的信息。
开发者可以直接把这一个东西对接起来作为数据源使用, 这样就能够省去自己搭建那个 whoi轮询池所必须付出的运维成本。
注册执行层：并发与协议适配
在判定出域名是可以被注册的这样一个状态之后, 需要在一秒钟这个时间内尽快完成注册请求这一关键操作。
通过使用
针对批量抢注这种场景, 就像新顶级域名的第一天开放那样, 我们采取了使用线程池结合令牌桶来限制流量的办法, 这样就可以避免触犯注册局的拒绝服务保护机制。
接口层需要在操作的时候, 去兼容 RAA（Registry Accreditation Agreement）里面所规定的注册数据校验规则, 在完成提交动作之前的这一步, 需要把 WHOIS 这个必填字段, 包含联系人邮箱以及邮编在内, 先进行本地格式的验证, 这样做的目的是为了能够让数据的驳回率得到降低。
回执与落库
当注册这个接口完成操作并且返回了代码是1000, 表示成功, 或者返回了代码1001, 表示对象已经存在之后, 系统会立马把相关数据写入到本地的数据库里面, 然后触发发送短信或者发送电子邮件的通知功能。
如果接到的回执消息里显示的是错误码1001, 这通常是因为在毫秒级别的时间里发生了竞争并且导致失败的情况出现, 这时候需要安排任务进入等待重试的那个队列当中去, 等间隔经过100毫秒的时间之后进行第二次的尝试和重新提交动作。
性能指标参考
合规边界
你不能去伪造EPP, 也不能通过破解注册局鉴权的方式, 来接触到后端。
对于像.cn这种顶级域名, 你必须先拿到CNNIC给的注册商资格认证, 然后才能去调取那个注册接口。
当抢注来得域名要去转卖的时候, 得遵守那些叫做 UDRP、也就是统一域名争议解决政策的东西, 里面有关于什么是恶意注册这样的判定标准, 不然的话, 就有被仲裁方给收回的风险。
开发落地建议
建议把最小可运行版本按照下面的这个顺序先去实现, 第一个步骤是先去做那个单域名的 DNS 轮询守护进程, 第二个步骤是去做 EPP 客户端的封装, 第三个步骤是去处理注册成功了之后的回调通知这些内容, 最后一个步骤才是去做好多 IP 池还有线程池的扩展工作。
前面的那一个和中间的那两个步骤, 大概只花费了三个人的工作日就可以完成, 后续的这些部分就根据不同类型的顶级域名去逐步地扩展对注册局的适配工作了。
