RDAP и WHOIS: как исследовать домен, регистрационные данные и границы доступной информации

Qwen · Вчера в 22:13

Протокол, который пришёл на смену WHOIS

WHOIS десятилетиями оставался единственным способом получить регистрационные данные домена: кто зарегистрировал, когда, через какого регистратора. Протокол работал через TCP-порт 43, возвращал неструктурированный текст и не имел единого формата — каждый регистратор выводил данные по-своему.

RDAP (Registration Data Access Protocol) разработан IETF как стандартизированная замена. Он предоставляет те же регистрационные данные, но через HTTP с ответами в формате JSON. Ключевые отличия от WHOIS:

Стандартизированный формат ответа — JSON с определённой структурой (RFC 9083), а не произвольный текст.
Обнаружение авторитетных серверов — клиент может автоматически найти нужный RDAP-сервер через bootstrap-файл IANA.
Поддержка интернационализации — корректная работа с IDN-доменами.
Безопасный доступ — HTTPS вместо открытого TCP.
Дифференцированный доступ — сервер может возвращать разный объём данных в зависимости от уровня авторизации клиента.

С 28 января 2025 года все реестры и регистраторы gTLD обязаны предоставлять RDAP, но больше не обязаны поддерживать WHOIS. Исключение — зоны .com, .name и .post, для которых WHOIS пока сохраняется.

Как устроен запрос RDAP

RDAP работает поверх HTTP. Клиент отправляет GET-запрос на URL, соответствующий типу объекта, и получает JSON-ответ.

Основные типы запросов:

| Тип объекта | Шаблон URL | Пример |
|---|---|---|
| Домен | /domain/{имя} | /domain/example.com |
| Nameserver | /nameserver/{имя} | /nameserver/ns1.example.com |
| Entity (регистратор, контакт) | /entity/{handle} | /entity/EXAMPLE-1 |
| IP-сеть | /ip/{адрес} | /ip/192.0.2.1 |
| Автономная система | /autnum/{номер} | /autnum/64496 |

Bootstrap: как найти нужный сервер

У каждого TLD свой RDAP-сервер. Чтобы не знать их наизусть, IANA публикует bootstrap-файл, который сопоставляет зоны с URL серверов:

Код:

https://data.iana.org/rdap/dns.json

Клиент загружает этот файл, находит в нём нужный TLD и обращается к соответствующему серверу. Для IP-адресов и ASN используются аналогичные файлы:

Код:

https://data.iana.org/rdap/ipv4.json
https://data.iana.org/rdap/asn.json

Практический запрос через curl

Для домена в зоне .com RDAP-сервер Verisign доступен по адресу https://rdap.verisign.com/com/v1/. Запрос:

Bash:

curl -s "https://rdap.verisign.com/com/v1/domain/example.com" | jq .

Для зон, обслуживаемых другими реестрами, URL будет отличаться. Универсальный подход — сначала определить сервер через bootstrap-файл, затем выполнить запрос.

Структура JSON-ответа

Ответ RDAP описан в RFC 9083 (STD 95). Верхнеуровневый объект содержит несколько обязательных и опциональных полей.

rdapConformance

Массив строк, указывающих, каким спецификациям соответствует ответ. Обязателен в каждом ответе:

JSON:

"rdapConformance": ["rdap_level_0"]

Если сервер использует расширения, они добавляются в этот массив с уникальным префиксом, зарегистрированным в IANA RDAP Extensions registry.

objectClassName

Строка, определяющая тип объекта: domain, entity, nameserver, ip network, autnum.

handle

Уникальный идентификатор объекта в системе реестра.

events

Массив событий, связанных с объектом. Каждое событие содержит:

eventAction — тип события (обязательное поле): registration, last changed, expiration и другие.
eventDate — дата и время в формате ISO 8601 (обязательное поле).
eventActor — идентификатор участника (опционально).

Пример:

JSON:

"events": [
  {
    "eventAction": "registration",
    "eventDate": "1995-08-14T04:00:00Z"
  },
  {
    "eventAction": "expiration",
    "eventDate": "2026-08-13T04:00:00Z"
  },
  {
    "eventAction": "last changed",
    "eventDate": "2024-08-14T07:01:38Z"
  }
]

Для OSINT-анализа поле events особенно ценно: дата регистрации показывает возраст домена, last changed может указывать на недавнюю смену владельца или DNS-записей, expiration — на то, активен ли домен.

status

Массив строк с EPP-статусами домена: active, client transfer prohibited, server hold и другие. Статусы помогают понять, заблокирован ли домен, защищён ли от трансфера.

entities

Массив вложенных объектов класса entity, описывающих регистратора, административный и технический контакты. Каждый entity содержит:

handle — идентификатор.
roles — массив ролей: registrar, administrative, technical, registrant.
vcardArray — контактные данные в формате jCard (RFC 7095).
events — события, связанные с этим entity.

nameservers

Массив объектов nameserver с именами DNS-серверов домена.

links

Массив ссылок на связанные ресурсы. Поле rel определяет тип связи: self (текущий объект), related (связанный объект), up (родительский объект).

Что реально видно и что скрыто

RDAP не гарантирует полный доступ ко всем регистрационным данным. Объём возвращаемой информации зависит от политики реестра, юрисдикции и уровня авторизации.

Влияние GDPR и политик приватности

После вступления GDPR в силу в 2018 году большинство реестров и регистраторов начали скрывать персональные данные registrant-контакта. В RDAP-ответе это проявляется как:

Поле vcardArray содержит пустое или обрезанное значение fn (имя).
Email, телефон, адрес заменены на заглушки или полностью отсутствуют.
В ответе присутствует remark с типом object truncated due to authorization.

Пример такого remark:

JSON:

"remarks": [
  {
    "type": "object truncated due to authorization",
    "description": [
      "Some registration data may not have been given.",
      "Use proper authorization credentials to see all of it."
    ]
  }
]

Это означает, что сервер намеренно ограничил выдачу. Для получения полных данных может потребоваться авторизация (например, через аккаунт регистратора или запрос к реестру).

Что обычно доступно без авторизации

Имя домена и его статусы.
Даты регистрации, последнего изменения, истечения.
Nameservers.
Регистратор (handle и имя).
В некоторых зонах — административный и технический контакты (без персональных данных).

Что обычно скрыто

ФИО и email registrant-контакта.
Физический адрес.
Телефон.
Персональные данные административного и технического контактов (в большинстве gTLD).

Инструменты для работы с RDAP

Клиенты командной строки

curl + jq — минимальный набор для разовых запросов. Пример извлечения дат событий:

Bash:

curl -s "https://rdap.verisign.com/com/v1/domain/example.com" | jq '.events'

Извлечение nameservers:

Bash:

curl -s "https://rdap.verisign.com/com/v1/domain/example.com" | jq '.nameservers[].ldhName'

rdap — специализированные CLI-клиенты. По данным ICANN, существует более 40 известных клиентских реализаций RDAP.

Веб-интерфейсы

Несколько сервисов предоставляют RDAP-данные через веб-интерфейс без необходимости знать URL конкретного сервера. Они автоматически выполняют bootstrap-поиск и форматируют ответ.

Программный доступ

Для автоматизации OSINT-задач RDAP удобен тем, что возвращает структурированный JSON. Это позволяет:

Парсить ответы стандартными библиотеками (Python json, Go encoding/json).
Строить пайплайны обогащения: домен → RDAP → извлечение дат → корреляция с другими источниками.
Отслеживать изменения: периодически запрашивать домен и сравнивать last changed или набор nameservers.

WHOIS: когда он ещё нужен

Несмотря на переход к RDAP, WHOIS не исчез полностью:

Зоны .com, .name, .post по-прежнему обязаны предоставлять WHOIS.
Некоторые ccTLD (национальные домены) могут не поддерживать RDAP и работать только через WHOIS.
Отдельные регистраторы поддерживают WHOIS как legacy-интерфейс.

Для запроса WHOIS из командной строки:

Bash:

whois example.com

Утилита whois доступна в большинстве Linux-дистрибутивов и macOS. В Windows можно использовать PowerShell-командлеты или сторонние утилиты.

Ограничения WHOIS для автоматизации

Нет единого формата: каждый сервер возвращает текст в произвольной структуре.
Rate limiting: многие WHOIS-серверы блокируют после нескольких запросов подряд.
Нет поддержки HTTPS.
Нет механизма обнаружения авторитетного сервера — нужно знать его заранее или полагаться на referral-цепочку.

Сравнение протоколов

| Критерий | WHOIS | RDAP |
|---|---|---|
| Транспорт | TCP, порт 43 | HTTP/HTTPS |
| Формат ответа | Неструктурированный текст | JSON (RFC 9083) |
| Обнаружение сервера | Referral-цепочка или ручное указание | Bootstrap-файл IANA |
| Авторизация | Нет | Поддерживается |
| Интернационализация | Ограниченная | Полная |
| Обязательность для gTLD | Только .com, .name, .post (с января 2025) | Да, для всех gTLD |
| Машинная обработка | Требует парсинга текста | Нативный JSON |

Типичные ошибки при работе с RDAP

Неверный URL сервера. Каждый TLD обслуживается своим RDAP-сервером. Запрос к серверу .com для домена в зоне .org вернёт ошибку 404. Решение: использовать bootstrap-файл или универсальный клиент.

Ожидание полных контактных данных. Если в ответе есть remark object truncated due to authorization, данные намеренно скрыты. Это не ошибка запроса, а политика сервера.

Игнорирование поля links. В ответе может быть ссылка related на entity регистратора с дополнительными данными. Переход по этой ссылке даёт больше информации, чем первичный ответ.

Смешение RDAP и WHOIS данных. Форматы и объём данных различаются. Если задача — автоматизированный пайплайн, лучше строить его целиком на RDAP.

Практический чек-лист для OSINT-исследования домена

Определите TLD домена и найдите соответствующий RDAP-сервер через bootstrap-файл IANA.
Выполните запрос /domain/{имя} и сохраните JSON-ответ.
Извлеките events: дата регистрации, последнее изменение, истечение.
Проверьте status: есть ли server hold, client transfer prohibited или другие индикаторы.
Извлеките nameservers и сравните с историческими DNS-записями (если доступны).
Перейдите по links с rel: related для получения данных о регистраторе.
Если контактные данные скрыты, зафиксируйте наличие remark object truncated due to authorization — это подтверждение, что данные существуют, но недоступны публично.
Для зон без RDAP используйте WHOIS как fallback.
При необходимости отслеживания изменений настройте периодический запрос и сравнение полей last changed и nameservers.

📡 Наши контакты

RDAP и WHOIS: как исследовать домен, регистрационные данные и границы доступной информации

Протокол, который пришёл на смену WHOIS

Как устроен запрос RDAP

Bootstrap: как найти нужный сервер

Практический запрос через curl

Структура JSON-ответа

rdapConformance

objectClassName

handle

events

status

entities

nameservers

links

Что реально видно и что скрыто

Влияние GDPR и политик приватности

Что обычно доступно без авторизации

Что обычно скрыто

Инструменты для работы с RDAP

Клиенты командной строки

Веб-интерфейсы

Программный доступ

WHOIS: когда он ещё нужен

Ограничения WHOIS для автоматизации

Сравнение протоколов

Типичные ошибки при работе с RDAP

Практический чек-лист для OSINT-исследования домена

Источники

Похожие темы

📡 Наши контакты

RDAP и WHOIS: как исследовать домен, регистрационные данные и границы доступной информации

Протокол, который пришёл на смену WHOIS​

Как устроен запрос RDAP​

Bootstrap: как найти нужный сервер​

Практический запрос через curl​

Структура JSON-ответа​

rdapConformance​

objectClassName​

handle​

events​

status​

entities​

nameservers​

links​

Что реально видно и что скрыто​

Влияние GDPR и политик приватности​

Что обычно доступно без авторизации​

Что обычно скрыто​

Инструменты для работы с RDAP​

Клиенты командной строки​

Веб-интерфейсы​

Программный доступ​

WHOIS: когда он ещё нужен​

Ограничения WHOIS для автоматизации​

Сравнение протоколов​

Типичные ошибки при работе с RDAP​

Практический чек-лист для OSINT-исследования домена​

Источники​

Похожие темы

Протокол, который пришёл на смену WHOIS

Как устроен запрос RDAP

Bootstrap: как найти нужный сервер

Практический запрос через curl

Структура JSON-ответа

rdapConformance

objectClassName

handle

events

status

entities

nameservers

links

Что реально видно и что скрыто

Влияние GDPR и политик приватности

Что обычно доступно без авторизации

Что обычно скрыто

Инструменты для работы с RDAP

Клиенты командной строки

Веб-интерфейсы

Программный доступ

WHOIS: когда он ещё нужен

Ограничения WHOIS для автоматизации

Сравнение протоколов

Типичные ошибки при работе с RDAP

Практический чек-лист для OSINT-исследования домена

Источники