TL;DR：您选择作为示例的域所涉及的注册商没有遵守规定，并且确实没有通过 RDAP 显示联系数据，而它通过 whois 显示它；这不是应该发生的，应该在某个时候解决；这不是协议的缺陷，只是一个参与者没有遵循规范。如果您尝试使用其他名称（在其他注册商处），您应该会得到更好的结果。
但是由于您的问题也可能来自其他原因，请在下面找到更多解释。
此问题不一定特定于 RDAP，对于 whois，对于 .COM/.NET 的情况，您有完全相同的问题，因为这是一个精简注册表，这意味着注册表没有有关联系人的数据。
whois 客户端通常模拟重定向（whois 协议中不存在），并首先显示注册机构 whois 回复（.COM 没有联系人），然后继续注册服务机构 whois 回复（有联系人）。
如果您不注意 whois 客户端，则默认情况下看不到这两个步骤，因为这是一个操作细节。
但是结构化的 RDAP 会为您提供链接并让您关注它们，但您的客户需要这样做。
让我们从头开始，遵循适用于所有情况的方法，只需使用 wget 和 jq 手动模拟 RDAP 客户端。
1) 寻找权威的RDAP服务器
流程基本由RFC 7484概述，但让我们手动完成。
这里是IANA的权威来源，所以如果你去http://data.iana.org/rdap/dns.json你会找到.COM的权威RDAP服务器，即：https://rdap.verisign.com/com/v1/
2) 查询注册表RDAP服务器
根据 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 中拆分注册机构/注册商模型的注册商部分。
所以我们应该使用该链接进行下一步。
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"
],
...
确实没有其他实体，除了registrar，没有其他角色。
该注册商的 RDAP 服务器没有提供任何联系数据，与其 whois 访问相反。这显然违反了规范，并且此服务器不符合当前的 ICANN 规则。
不幸的是，在你的水平上，你可能无法改变这一点。情况会发生变化，因为 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."
]
}
]
},
正如您在roles 中的registrant 所见，此结构描述了注册人数据。但是，由于 GDPR 和 ICANN 临时规范，大部分数据都被编辑了，实际上并不存在。 vCard 部分中基本上只有注册人姓名和国家/地区。
5) 总结
这里要记住三点：
- RDAP（相对于 whois）的优势之一就是能够清晰地传达下一步该去哪里获取更多信息的链接；这是上面概述的过程
- 目前这仅与 COM/NET 名称有关，因为这些 TLD 在精简注册表模型下运行，在该模型中注册表没有联系人数据；请注意，这一定会消失：即使该流程在 ICANN 被多次推迟，它也确实处于未决状态，并且在某些未来 COM/NET 将像任何其他 gTLD 一样工作，因为注册管理机构将拥有所有联系数据
- 上述所有内容都受到 GDPR 的严重影响，GDPR 限制了当前在 whois 中显示的数据量，特别是关于联系人的数据量。由于目前还不知道分层访问的未来模型，也许我们仍将有一个多步骤的查询过程来获取更多的联系人数据，具体取决于谁请求数据。