TL; DR: регистратор, связанный с доменом, который вы выбрали в качестве примера, не следует правилам и действительно не показывает контактные данные через RDAP, в то время как он показывает их через whois; это не то, что должно происходить и должно быть исправлено в какой-то момент; это не дефект протокола, просто один участник, который не следует спецификациям. Если вы попробуете использовать другие имена (в других регистраторах), вы должны получить лучшие результаты.
Но поскольку ваша проблема может быть также вызвана другими причинами, пожалуйста, найдите ниже дополнительные объяснения.
Эта проблема не Обязательно укажите c для RDAP, у вас есть то же самое для whois, для случая .COM /.NET, так как это тонкий реестр, что означает, что реестр не имеет данных о контактах.
Клиенты whois обычно эмулируют перенаправления (которых нет в протоколе whois) и сначала показывают ответ whois реестра (нет контактов для .COM), а затем продолжают ответ whois регистратора (который имеет контакты).
Вы не видите эти 2 шага по умолчанию, если не обращаете внимания на whois-клиенты, так как это рабочая деталь.
Но структурированная RDAP дает вам ссылки и позволяет вам следовать по ним, но ваш клиент должен сделать это.
Давайте начнем с нуля, чтобы следовать методологии, которая будет работать для всех случаев, и просто manua только эмуляция клиента RDAP с использованием wget и jq.
1) Поиск авторитетного сервера RDAP
Процесс в основном описан как RF C 7484 , но давайте сделаем это вручную.
IANA является официальным источником здесь, поэтому, если вы go до http://data.iana.org/rdap/dns.json, вы найдете авторитетный сервер RDAP для .COM, который: 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, просто в реестре нет контактных данных.
Но в ответе содержится информация о том, где go рядом с недостающие данные. Если вы внимательно посмотрите на возвращенные данные 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, это объясняется как ссылка для получения большего количества данных, то есть для регистратора в случаях деления реестра / модели регистраторов, как во всех рДВУ.
Итак, мы должны используйте эту ссылку для следующего шага.
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."
]
}
]
},
Как вы можете видеть по registrant в roles, эта структура описывает данные владельцев регистрации. Однако из-за GDPR и, следовательно, временной спецификации ICANN большинство данных отредактировано и фактически отсутствует. В основном у вас есть только имя и страна регистранта, в части vCard.
5) Резюме
Здесь нужно запомнить три пункта:
- один из Преимущество RDAP (по сравнению с whois) состоит в том, чтобы точно передавать четкие ссылки о том, куда go рядом, чтобы получить больше информации; это процесс, описанный выше
- , на данный момент это относится только к именам COM /NET, так как эти TLD запускаются по тонкой модели реестра, в которой реестр не имеет контактных данных; обратите внимание, что это обязательно исчезнет: даже если процесс несколько раз откладывается в ICANN, он действительно находится в состоянии ожидания и в будущем COM /NET будет работать как любой другой рДВУ, поскольку в реестре будут все контактные данные
- На все вышесказанное сильно влияет GDPR, который ограничивает объем данных, отображаемых в настоящее время в whois, в частности, о контактах. Поскольку будущая модель многоуровневого доступа сегодня неизвестна, возможно, у нас все еще будет многоэтапный процесс запроса, чтобы получить больше данных о контактах в зависимости от того, кто запрашивает данные.