TL;DR：例如，您选择的域名所关注的注册商没有遵守法规，并且确实没有通过RDAP显示联系人数据，而通过whois显示联系人数据;这不是应该发生的事情，应该在某个时候得到解决;这不是协议的缺陷，只是一个参与者不遵守规范。如果您尝试使用其他名称（在其他注册商处），您应该会得到更好的结果。

但是，由于您的问题也可能来自其他原因，因此请在下面找到更多解释。

此问题不一定特定于 RDAP，对于 .COM/.NET 的情况，whois 完全相同，因为这是一个瘦注册表，这意味着注册表没有有关联系人的数据。

WHOIS 客户端通常模拟重定向（WHOIS 协议中不存在），并将首先显示注册机构 whois 回复（.COM 中没有联系人），然后继续注册商 whois 回复（有联系人）。

如果您不注意whois客户端，则默认情况下不会看到这两个步骤，因为它是操作细节。

但是RDAP的结构为您提供了链接并让您关注它们，但是您的客户需要这样做。

让我们从头开始，遵循一种适用于所有情况的方法，只需使用 和 手动模拟 RDAP 客户端。wgetjq

1） 查找权威 RDAP 服务器

该过程基本上由 RFC 7484 概述，但让我们手动完成。

IANA 是这里的权威来源，因此，如果您转到 http://data.iana.org/rdap/dns.json，您会找到.COM的权威 RDAP 服务器，即：https://rdap.verisign.com/com/v1/

2） 查询注册表 RDAP 服务器

根据 RDAP 规范，从上面的基本 URL 中，您知道需要将其用作第一步 （即基本 URL 的串联，然后是 ，然后是您要查找的域名）。https://rdap.verisign.com/com/v1/domain/google.comdomain

您可以通过以下方式手动模拟它wget -O - https://rdap.verisign.com/com/v1/domain/google.com | jq .

您将获得大量数据，但由于上述原因，您没有关于联系人的信息，这与您正在使用 RDAP 的事实无关，只是注册表没有联系人数据。

但是，该回复会为您提供有关下一步去哪里获取缺失数据的信息。 如果仔细查看返回的 JSON 数据，则有以下部分：

  "links": [
    {
      "value": "https://rdap-core.vrsn.com/com/v1/domain/GOOGLE.COM",
      "rel": "self",
      "href": "https://rdap-core.vrsn.com/com/v1/domain/GOOGLE.COM",
      "type": "application/rdap+json"
    },
    {
      "value": "https://rdap.markmonitor.com/rdap/domain/GOOGLE.COM",
      "rel": "related",
      "href": "https://rdap.markmonitor.com/rdap/domain/GOOGLE.COM",
      "type": "application/rdap+json"
    }
  ],

请密切注意酒店。 第一个链接（它是响应中的数组）具有，这意味着它为您提供了表示您刚刚获得回复的对象的规范 URL。再次使用它应该会给你完全相同的回复 - 如果对象没有改变 - 并且将源 URL 保留在文档本身中很有用。事实上，它与我们使用的 URL 不同，那么基本 URL 与 IANA 现有的 URL 不同，这只是一个操作细节，在这里没有后果。relrel=self

但是看看第二个。如果您查看 RDAP 规范和 ICANN 规则，就会发现这是获取更多数据的链接，即注册管理机构/注册服务机构拆分模式的注册服务商部分，就像所有 gTLD 一样。rel=related

因此，我们应该在下一步中使用该链接。

3） 查询注册商RDAP服务器

如果我们搜索联系人所在的部分，我们会得到：wget -O - https://rdap.markmonitor.com/rdap/domain/GOOGLE.COM | jq .entities

  "entities": [
    {
      "objectClassName": "entity",
      "handle": "292",
      "events": [
        {
          "eventAction": "registrar expiration",
          "eventDate": "2020-09-14T04:00:00.000+0000"
        }
      ],
      "roles": [
        "registrar"
      ],

...

事实上，没有其他实体，除了. 该注册商的RDAP服务器没有提供任何联系数据，这与其whois访问相反。这显然违反了规范，并且该服务器不符合当前的 ICANN 规则。registrar

不幸的是，在你的水平上，你可能无能为力来改变这一点。它将会改变，因为ICANN将在某个时候开始执行某些事情，但在那之前，您将需要忍受这种破碎的案件，因为还有其他多个案件。

4）其他领域也一样，效果更好

如果您使用其他名称重复上述操作，假设您联系了另一个注册商，在最终回复中，您可以看到：stackoverflow.com

  "entities": [

...

   {
      "objectClassName": "entity",
      "handle": "",
      "vcardArray": [
        "vcard",
        [
          [
            "version",
            [],
            "text",
            "4.0"
          ],
          [
            "org",
            {
              "type": "work"
            },
            "text",
            "Stack Exchange, Inc."
          ],
          [
            "adr",
            [],
            "text",
            [
              "",
              "",
              "",
              "",
              "NY",
              "",
              "US"
            ]
          ]
        ]
      ],
      "roles": [
        "registrant"
      ],
      "remarks": [
        {
          "title": "REDACTED FOR PRIVACY",
          "type": "object truncated due to authorization",
          "description": [
            "Some of the data in this object has been removed."
          ]
        }
      ]
    },

正如您在 中看到的，此结构描述了注册人数据。但是，由于 GDPR 和 ICANN 的临时规范，大多数数据都被编辑了，实际上不存在。在该部分中，您基本上只有注册人姓名和国家/地区。registrantrolesvCard

5） 总结

这里要记住三点：

• RDAP（相对于 whois）的优势之一正是能够传达关于下一步去哪里获取更多信息的清晰链接;这是上面概述的过程
• 目前，这仅与 COM/NET 名称有关，因为这些 TLD 是在精简注册管理机构模型下运行的，即注册管理机构没有联系数据;请注意，这注定会消失：即使该流程在 ICANN 被多次推迟，它确实处于待决状态，并且在未来的某个时候，COM/NET 将像任何其他 gTLD 一样工作，因为注册管理机构将拥有所有联系数据
• 以上所有内容都受到GDPR的严重影响，GDPR限制了目前在WHOIS中显示的数据量，特别是关于联系人的数据量。由于目前还不知道未来的分层访问模型，也许我们仍然会有一个多步骤的查询过程，根据谁请求数据来获取更多联系人数据。