Rdap 查询的结果少于 google.com 的 whois？

Question

当我为 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 条目根本不包含 registrant/admin/tech 组织数据？

Answer 1

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

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

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

whois 客户端通常会模拟重定向（在 whois 协议中不存在），并且会首先显示注册管理机构的 whois 回复（那里没有 .COM 的联系方式），然后继续向注册商 whois 回复（有联系方式） .

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

但是正在构建的 RDAP 为您提供 links 并让您遵循它们，但您的客户需要这样做。

让我们从头开始，遵循适用于所有情况的方法，并使用 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 属性。首先 link（它是响应中的一个数组）具有 rel=self，这意味着它为您提供规范的 URL，代表您刚刚收到回复的对象。再次使用它应该会给你完全相同的答复 - 如果对象当然没有改变 - 并且将源 URL 保留在文档本身中是很有用的。事实上，它与我们当时使用的基础 URL 与 IANA 存在的基础不同，这只是一个操作细节，不会对此处产生任何影响。

但是看第二个rel=related。如果您查看 RDAP 规范和 ICANN 规则，这被解释为 link 以获得更多数据，即所有 gTLD 中拆分 registry/registrars 模型案例的注册商部分。

所以我们应该在下一步中使用 link。

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) 其他域相同，结果更好

如果你用另一个名字重复上面的内容，比如 whosebug.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）的优势之一就是能够清楚地传达 link关于下一步去哪里获取更多信息的信息；这是上面概述的过程
目前这仅与 COM/NET 名称相关，因为这些 TLD 运行在精简注册模型下，注册模型中没有联系数据；请注意，这肯定会消失：即使该流程在 ICANN 被多次推迟，它确实处于待定状态，并且在将来 COM/NET 将像任何其他 gTLD 一样工作，因为注册管理机构将拥有所有联系数据
以上所有内容都受到 GDPR 的严重影响，GDPR 限制了如今在 whois 中显示的数据量，特别是关于联系人的数据量。由于目前还不知道分层访问的未来模型，也许我们仍将有多个步骤的查询过程，以根据请求数据的人获取更多有关联系人的数据。

Rdap 查询的结果少于 google.com 的 whois？

Rdap query has less results than whois for google.com?

whois

rdap

1) 寻找权威的 RDAP 服务器

2) 查询注册表 RDAP 服务器

3) 查询注册商 RDAP 服务器

4) 其他域相同，结果更好

5) 摘要