当我对 Google.com 进行简单的域名 whois 查找时，我得到以下结果：
[...]
Registrant Organization: Google LLC
Registrant State/Province: CA
Registrant Country: US
Registrant Email: Select Request Email Form at https://domains.markmonitor.com/whois/google.com
Admin Organization: Google LLC
Admin State/Province: CA
Admin Country: US
Admin Email: Select Request Email Form at https://domains.markmonitor.com/whois/google.com
Tech Organization: Google LLC
Tech State/Province: CA
Tech Country: US
[...]
但是当我使用 rdap 时，例如使用以下网站：
https://client.rdap.org/?type=domain&object=google.com
生成的 json 不包含任何指向 Google LLC 的数据。这是因为我以错误的方式使用 rdap 还是因为 Google 的 rdap 条目根本不包含注册人/管理员/技术组织数据？
TL;DR：您选择作为示例的域名所涉及的注册商没有遵守规定，并且确实没有通过 RDAP 显示联系数据，而通过 whois 显示联系数据；这不是应该发生的情况，应该在某个时候修复；这不是协议的缺陷，只是一个参与者不遵守规范。如果您尝试使用其他名称（在其他注册商处），您应该会得到更好的结果。
但由于您的问题也可能来自其他原因，请在下面找到更多解释。
这个问题不一定是 RDAP 特有的，对于 whois，对于 .COM/.NET 的情况也有完全相同的问题，因为这是一个薄注册表，这意味着注册表没有有关联系人的数据。
whois 客户端通常会模拟重定向（whois 协议中不存在），并首先显示注册机构 whois 回复（没有 .COM 的联系人），然后继续显示注册商 whois 回复（有联系人）。
如果您不注意 whois 客户端，默认情况下您不会看到这 2 个步骤，因为这是一个操作细节。
但是 RDAP 的结构化为您提供了链接并让您跟踪它们，但您的客户需要这样做。
让我们从头开始遵循适用于所有情况的方法，并且只需使用wget和手动模拟 RDAP 客户端jq。
RFC 7484基本上概述了该过程，但让我们手动完成。
IANA 是这里的权威来源，因此如果您访问http://data.iana.org/rdap/dns.json，您会找到 .COM 的权威 RDAP 服务器，即：https://rdap.verisign.com/com/v1/
根据 RDAP 规范，从上面的基本 URL 中您知道您需要将
https://rdap.verisign.com/com/v1/domain/google.com其用作第一步（即基本 URL 的串联，然后是domain，然后是您所在的域名）。
您可以通过类似的方式手动模拟它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"
}
],
密切关注房产rel。第一个链接（它是响应中的一个数组），这rel=self意味着它为您提供了代表您刚刚收到回复的对象的规范 URL。再次使用它应该会给你完全相同的答复 - 当然，如果对象没有改变 - 并且将源 URL 保留在文档本身中很有用。事实上，它与我们使用的基本 URL 与 IANA 中存在的不同，这只是一个操作细节，不会产生任何后果。
但看看第二个rel=related。如果您查看 RDAP 规范和 ICANN 规则，就会发现这是获取更多数据的链接，即所有通用顶级域名 (gTLD) 中拆分注册管理机构/注册商模型情况下的注册商部分。
因此，我们应该使用该链接进行下一步。
如果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"
],
...
事实上，除了 之外，没有其他实体，没有其他角色registrar。该注册商的 RDAP 服务器未提供任何联系数据，这与其 whois 访问相反。这显然违反了规范，并且该服务器不符合当前 ICANN 规则。
不幸的是，以你的水平，你可能无法改变这一点。它会发生变化，因为 ICANN 将在某个时候开始执行某些规定，但在此之前，您将需要忍受此类破坏案例，因为还有多个其他案例。
如果您使用另一个名称重复上述内容，假设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."
]
}
]
},
registrant正如您在in中所看到的roles，该结构描述了注册者数据。然而，由于 GDPR 以及 ICANN 临时规范，大部分数据都经过编辑，实际上并不存在。该部分基本上只有注册人姓名和国家/地区vCard。
这里要记住三点：