我在尝试理解 Whois 协议如何工作时遇到了问题，特别是与名称服务器信息相关的部分。
例如
dig +short NS adtogroups.com
不返回任何内容，这是预料之中的，因为域上存在 ClientHold，阻止其解析
Whois adtogroups.com
... Showing part of the output: Domain Status: clientHold https://icann.org/epp#clientHold
但是，whois answer 的名称服务器部分会返回一组服务器。我知道 dig 是解析任何域名的可靠来源，因为它是建立在发送 DNS 查询的基础上的，而 whois 中的名称服务器信息则以某种方式从另一个来源镜像而来。
我的问题是，在上面的例子中，whois 从哪里获得名称服务器信息，知道该域处于 ClientHold 状态（即 DNS 不会响应解析请求）并且 whois 的 NS 输出均未出现在被动 DNS 中？
我认为我遗漏了一些关于 Whois 如何获取与 NS 相关的信息。
答案1
即使您确实存在此差异问题，您的证据也并不正确。为什么？因为您的 dig 查询询问的是本地/默认递归名称服务器，而不是注册中心级别的权威名称服务器。如果您想证明您的观点，则需要重做此操作……除非我们已经知道您的观点是正确的。
whois 和 dig（如果您查询权威域名服务器）来自完全相同的来源：注册中心。但它们满足两种不同的需求：顾名思义，whois显示域名在注册中心的注册方式或是否免费；wheredig显示域名在互联网上的解析方式。
whois 是一个非常简单的协议，客户端只需在端口 43 上打开一个套接字到目的地，在一行上发送域名，然后返回一段文本和一个关闭的连接。它返回的内容是注册中心决定发送的内容。
域名可以注册但无法解析的情况有多种：
- 其所有者可能决定不指定任何 NS 记录，因此域名无法解析
- 或者在注册后，域名可能尚未加载到注册中心权威名称服务器中（有些是实时的或接近实时的，有些则较慢）
- 错误和失误也时有发生
- 但对于您来说，如果您通过 whois 查询您的域名，您将看到：
状态：clientHoldhttps://icann.org/epp#clientHold
您可以查看这个 URL，它应该能为您解释情况。简而言之，拥有clientHold或serverHold意味着，由于各种原因，虽然域名已注册并存在于注册数据库中，但不会解析。
在您这个非常特殊的情况下，根据您的域名使用的名称服务器，我认为您需要联系注册商。
另外，一些 whois 客户端有一个固定的 whois 服务器列表，根据查询本身进行查询（实际上，它还可以是域名以外的其他东西），其他客户端会使用whois.nic.$TLD经常但并非总是有效的列表（您可以在 IANA 网站上看到每个 TLD 的页面，其中必须显示 whois 服务器）。
还要注意的是，将来，RDAP 应该会取代 whois（或至少开始共存），并可能使引导问题变得更容易。在 gTLD 中，少数剩余的薄注册表（但较大的注册表）将“很快”转换为厚注册表。
答案2
Whois 从服务于特定 TLD 的注册中心获取数据（如果没有单一注册中心，则从 TLD 内的特定域获取数据）。
它是保存所有者提交的域名的所有信息的注册中心，包括其 NS RR 和提示，以及联系人、状态等。
TLD 的区域数据是根据注册表内容生成的，如果存在保留，则相关域名将不会导出到该区域。