RDAP и WHOIS: два протокола, которые решают одну задачу по-разному

Почти каждый, кто хоть раз покупал домен или разбирался, кому принадлежит подозрительный сайт, сталкивался со словом WHOIS. А вот аббревиатуру RDAP мир узнал относительно недавно, примерно тогда, когда старый добрый WHOIS для доменов верхнего уровня официально отправили на пенсию. Это не косметическая замена и не ребрендинг — это смена поколений: один протокол родился в эпоху, когда интернет умещался в записной книжке, другой создан под требования GDPR, автоматизации и машинного взаимодействия.

Что ж, давайте подробно разберёмся с этой темой, с её историей, техникой, юридическими нюансами и практикой, включая специфику украинской зоны .ua.

Зачем вообще существуют WHOIS и RDAP

Начать нужно с простой мысли: глобальная доменная система – это общий ресурс, которым одновременно пользуется весь мир. Например, доменное имя hostingi.net.ua (на котором построен наш любимый рейтинг украинских хостингов) во всём интернете ровно одно. И раз ресурс общий, должен быть способ узнать две вещи: кто за это имя отвечает и как это имя технически подключено к сети. WHOIS и RDAP – это и есть тот самый способ. По сути, оба протокола решают одну задачу – дают ответ на вопрос «что известно про этот домен (или IP-адрес) и к кому по нему обращаться». Всё остальное – надстройки над этой идеей.

А теперь по конкретным сценариям, потому что «справочник» звучит абстрактно, а нужен он совершенно разным людям и по очень земным поводам.

Покупка и проверка домена

Самый массовый случай. Прежде чем купить домен, вы хотите знать: свободен он или занят, а если занят – когда истекает регистрация. Дата окончания (Expiration Date) – ключевая: по ней ловят освобождающиеся имена, планируют перекупку, оценивают, стоит ли ждать. Если вы покупаете домен с рук, проверка данных о регистрации – это элементарная и необходимая осмотрительность: не находится ли имя в статусе pendingDelete, не висит ли на нём судебный спор, действительно ли продавец им распоряжается. Без этой проверки легко купить кота в мешке.

Оценка доверия к сайту

Возраст домена и имя регистратора – это грубый, но рабочий сигнал добросовестности. Магазин, зарегистрированный три дня назад через регистратора, известного попустительством к мошенникам, заслуживает совсем другого отношения, чем домен с историей в десять лет. Антифрод-системы, банки, платёжные сервисы автоматически смотрят на дату регистрации именно поэтому: свежесозданные домены статистически чаще оказываются фишингом.

Техническая диагностика

Это чисто инженерная сторона, и она никуда не делась даже после того, как контакты позакрывали. Когда что-то ломается – почта не «ходит», сайт не резолвится, домен «увели» не туда, – первым делом смотрят на серверы имён (NS) и статусы домена. Справочник показывает, на какие DNS-серверы делегировано имя, подписана ли зона DNSSEC, не стоит ли на домене блокировка переноса. Для админа это отправная точка расследования: понять, где именно рвётся цепочка.

Перенос домена между регистраторами и хостингами

Статусы вроде clientTransferProhibited напрямую говорят, можно ли сейчас утащить домен к другому регистратору или он заблокирован. Без этой информации трансфер превращается в гадание.

Борьба со злоупотреблениями

Если с какого-то домена рассылается спам, раздаётся вредоносное ПО или крутится фишинговая копия вашего банка – куда писать жалобу? Справочник исторически давал контакт для abuse-обращений и указывал регистратора, которому можно эскалировать. Специалисты по кибербезопасности используют регистрационные данные для attribution – попытки связать разные вредоносные домены в одну инфраструктуру по общим признакам (один регистрант, одни серверы имён, близкие даты создания). Именно ради этих сценариев так болезненно восприняли закрытие данных после GDPR: обезличенная запись расследование не убивает, но заметно замедляет его.

Защита брендов и интеллектуальной собственности

Юристы и бренд-менеджеры мониторят регистрации, похожие на их торговую марку. Появился, к примеру, pypal-secure.com – это потенциальный киберсквоттинг или фишинг под PayPal, и по регистрационным данным готовят претензию или запускают процедуру UDRP (арбитраж по доменным спорам ICANN). Без справочника доказательная база для такого спора собирается куда труднее.

Работа правоохранителей и госорганов

Расследования киберпреступлений, мошенничества, распространения запрещённого контента почти всегда упираются в вопрос «кто стоит за доменом». Именно для таких законных запросов к закрытым данным и сделали шлюз RDRS, о котором шла речь выше.

Отдельно стоит подчеркнуть, что справочник работает не только по доменам, но и по IP-адресам и автономным системам – этим заведуют региональные интернет-регистратуры (RIPE, ARIN и другие). Когда вы видите в логах подозрительную атаку с конкретного IP и хотите понять, какому провайдеру он принадлежит и куда слать abuse-репорт, – это тот же самый механизм регистрационных данных, просто для другого типа объектов.

Если свести всё к одной фразе, то смысл сервисов RDAP и WHOIS состоит в подотчётности и координации в сети, у которой нет единого хозяина. Домены и адреса раздают тысячи независимых организаций по всему миру, а работать всё это должно как единое целое. Публичный справочник регистрационных данных – это тот «клей», который позволяет чужим друг другу людям договариваться, чинить поломки, ловить злоумышленников и разрешать споры, не имея над собой общего начальника. WHOIS делал это грубо и открыто, RDAP делает тоньше и избирательнее – но задача под обоими протоколами одна и та же, с самого 1982 года.

С чего всё началось: WHOIS как ровесник интернета

Чтобы понять, зачем понадобился RDAP, нужно сначала честно посмотреть на WHOIS – не как на «устаревший функционал», а как на инструмент, который десятилетиями держал на себе всю справочную инфраструктуру доменов.

Первые версии WHOIS появились в начале 1980-х годов (RFC 812, позже RFC 954), а современное описание классического протокола содержится в RFC 3912. Это была эпоха, когда сеть ARPANET насчитывала пару сотен машин, а всех администраторов можно было при желании обзвонить лично. Логика была простая: есть центральный справочник, ты отправляешь запрос с именем и получаешь текст с контактами ответственного лица. Никакой авторизации, никакого шифрования, никакой структуры. Просто вопрос и ответ открытым текстом.

Технически WHOIS работает поверх TCP на 43 порту. Клиент открывает соединение, отправляет строку запроса, сервер возвращает поток текста и закрывает соединение. Всё. Именно эта предельная простота одновременно и достоинство, и корень почти всех проблем.

Типичный ответ WHOIS выглядел примерно так:

Domain Name: EXAMPLE.COM
Registrar: Example Registrar, LLC
Creation Date: 1998-05-14T04:00:00Z
Registry Expiry Date: 2026-05-13T04:00:00Z
Name Server: NS1.EXAMPLE.COM
Registrant Name: John Doe
Registrant Email: john@example.com

Человек это прочитает без труда. А вот программа с трудом. Здесь и кроется первая большая беда WHOIS: у него нет стандартизированного формата вывода. Каждый регистратор и каждый реестр форматировали ответ так, как считали нужным. Где-то поле называется Registrant Name, где-то Holder, где-то owner-c. Порядок строк, разделители, отступы, даже кодировка – всё плавало. Для парсера это кошмар: под каждый реестр приходилось писать отдельные регулярные выражения и постоянно их чинить, когда кто-то менял шаблон.

Вторая беда – интернационализация. WHOIS исторически жил в мире ASCII. Имя на кириллице, арабской вязи или иероглифами в ответе могло превратиться в мусор, потому что единого стандарта кодировки в протоколе не было заложено.

Третья беда – безопасность. Порт 43 работает открытым текстом. Никакого TLS, никакой аутентификации. Кто угодно между вами и сервером мог прочитать и запрос, и ответ. Плюс сам механизм превращал базу контактов в открытый буфет для спамеров: e-mail регистрантов лежали в публичном доступе, и боты годами их выкачивали, чтобы завалить владельцев доменов рекламой и фишингом.

И четвёртая, самая тонкая проблема – невозможность разграничить доступ. WHOIS отвечает всем одинаково. Он физически не умеет показать полицейскому одно, а анонимному прохожему – другое. Либо данные открыты для всех, либо закрыты для всех. Как мы увидим дальше, именно об этот камень протокол в итоге и споткнулся.

Точка перелома: GDPR и кризис 2018 года

Долгие годы недостатки WHOIS терпели, потому что альтернативы под рукой не было, а привычка сильнее логики. Всё изменилось 25 мая 2018 года, когда в Евросоюзе вступил в силу Общий регламент по защите данных – GDPR.

GDPR устроен просто и жёстко: персональные данные нельзя публиковать без законного основания, а «так исторически сложилось» основанием не является. И тут выяснилась неудобная правда: публичный WHOIS с открытыми именами, адресами, телефонами и почтой миллионов частных регистрантов – это ровно то, что GDPR запрещает. Причём под удар попали не только европейцы: реестры и регистраторы работают глобально, а регламент экстерриториален.

Разразился настоящий кризис. ICANN – организация, координирующая систему доменных имён, – оказалась между молотом собственных договоров, требовавших открытого WHOIS, и наковальней европейского закона, грозившего штрафами до 4% глобального оборота. В качестве срочной меры почти все регистраторы просто замазали персональные поля. Вместо имени и почты в ответе стало появляться что-то вроде REDACTED FOR PRIVACY или Data Protected.

С точки зрения приватности это можно было считать победой. С точки зрения тех, кто реально пользовался WHOIS для дела (расследование киберпреступлений, защита брендов, борьба с мошенничеством), – половина ценности испарилась. Открытый справочник превратился в анкету с зачёркнутыми графами. Стало окончательно ясно: нужен протокол, который умеет то, чего WHOIS не умел никогда, – отдавать разные данные разным запрашивающим в зависимости от их прав. Так политическая необходимость встретилась с уже готовым техническим решением.

Что такое RDAP и зачем он придуман

RDAP расшифровывается как Registration Data Access Protocol – протокол доступа к регистрационным данным. Он разработан Инженерным советом Интернета (IETF) и предлагает по сравнению с WHOIS ряд преимуществ: поддержку интернационализации, безопасный доступ к данным, авторитетное обнаружение сервиса и возможность выдавать дифференцированный доступ к регистрационным данным.

Важно понимать: RDAP – не надстройка над WHOIS и не «WHOIS 2.0» в смысле улучшенного текста. Это принципиально другая архитектура, построенная на технологиях современного веба.

Спецификация RDAP – это набор документов RFC. Первая волна вышла ещё в 2015 году силами рабочей группы WEIRDS: RFC 7480 описывает использование HTTP, RFC 7481 – сервисы безопасности, RFC 7482 – формат запроса, RFC 7483 – JSON-ответы, а RFC 7484 – механизм поиска авторитетного сервера. В 2023 году спецификацию консолидировали и обновили: актуальная версия описана в RFC 9082 и RFC 9083, а также RFC 9224 для механизма начальной загрузки. Старые RFC при этом формально помечены как замещённые более новыми – например, RFC 7483 объявлен устаревшим и заменён на RFC 9083.

Ключевой факт для понимания всей истории: RDAP появился не вчера. Аккредитованные ICANN регистраторы и реестры gTLD обязаны были поддерживать RDAP параллельно с WHOIS ещё с 2019 года. То есть к моменту «official launch» протокол уже несколько лет тихо работал в фоне. Просто до определённого дня он был необязательной опцией, а не заменой.

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

Здесь и начинается самое интересное для инженеров. RDAP берёт всё лучшее из современной веб-разработки и применяет к скучной задаче справочника доменов.

Транспорт – это HTTP/HTTPS, а не самодельный порт 43

RDAP-сервер – это, по сути, RESTful HTTP API. RDAP построен на веб-службах RESTful API, использующих протокол HTTPS. Значит, из коробки вы получаете TLS-шифрование, привычные HTTP-заголовки, кэширование, редиректы, коды состояния и весь зрелый инструментарий, который человечество отладило за тридцать лет веба. Запрос – это обычный GET на URL. Например, чтобы узнать про домен, вы обращаетесь по адресу вида https://rdap.example/domain/example.com. Ответ приходит с медиатипом application/rdap+json.

Ответ – структурированный JSON, а не свободный текст

Это, пожалуй, главное практическое отличие. В отличие от WHOIS, RDAP отдаёт данные в машиночитаемом формате JSON. Больше не нужно угадывать, как назвали поле в этом конкретном реестре. Структура ответа единая и описана в стандарте: объекты домена, серверов имён, контактов (сущностей), у каждого – предсказуемый набор членов. RFC зарегистрировал в IANA отдельный медиатип application/rdap+json и реестр допустимых JSON-значений. Программе больше не нужен полк регулярных выражений – достаточно распарсить JSON и обратиться к полю по имени.

Пример фрагмента RDAP-ответа даёт почувствовать разницу:

{
  "objectClassName": "domain",
  "ldhName": "example.com",
  "status": ["client transfer prohibited", "server delete prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "1998-05-14T04:00:00Z" },
    { "eventAction": "expiration", "eventDate": "2026-05-13T04:00:00Z" }
  ],
  "nameservers": [
    { "objectClassName": "nameserver", "ldhName": "ns1.example.com" }
  ],
  "secureDNS": { "delegationSigned": true }
}

Именно здесь становится понятным, почему индустрия так активно переходит на RDAP. Если раньше разработчикам приходилось писать и постоянно поддерживать отдельные парсеры под текстовые ответы каждого реестра и регистратора, то теперь достаточно один раз реализовать поддержку стандартизированного JSON. Это значительно упростило разработку систем мониторинга доменов, сервисов Threat Intelligence, антифрод-платформ и других инструментов, автоматически анализирующих регистрационные данные.

Контакты передаются в формате jCard

Информация о людях и организациях в RDAP оформлена не произвольным текстом, а по стандарту. Контактные данные передаются в формате jCard – это JSON-представление формата vCard, а роли (регистрант, административный, технический контакт) заданы в спецификации. То есть визитка регистранта имеет ту же структуру, что и контакт в вашем телефоне, только в JSON.

Статусы стандартизированы через EPP

Те самые status-коды вроде clientTransferProhibited или pendingDelete – это не случайные строки. IANA определяет набор статусов, сопоставленных с кодами EPP согласно RFC 8056. Благодаря этому один и тот же статус означает одно и то же в любом реестре мира.

Интернационализация встроена, а не приклеена

Кодировка ответов RDAP по умолчанию – UTF-8, и в стандарте предусмотрена корректная обработка интернационализированных доменных имён. Кириллический или китайский домен больше не рискует превратиться в кашу из знаков вопроса.

Поиск нужного сервера – через bootstrap-реестр IANA

У WHOIS вечно была морока: на какой из тысяч серверов слать запрос? RDAP решает это элегантно. Bootstrap-реестры RDAP, описанные в RFC 7484, опубликованы как JSON-объекты, которые можно получить по HTTP из мест, указанных IANA; каждый реестр содержит метаданные и массив services с самими записями. Клиент один раз скачивает эту «карту», понимает, что домены .com обслуживает такой-то сервер, IP-адреса – региональные интернет-регистратуры, и дальше ходит напрямую по адресу. Существуют и агрегаторы-посредники вроде RDAP.org, которые сами разруливают маршрутизацию, но они знают только о тех RDAP-серверах, что зарегистрированы в IANA, и накладывают ограничения по частоте запросов – при их превышении возвращается код 429.

И, наконец, дифференцированный доступ – то, ради чего всё затевалось

Раз RDAP живёт поверх HTTP, поддерживает механизмы аутентификации и авторизации через через этот протокол. Сервер может узнать, кто спрашивает, и на этом основании показать анонимному пользователю обезличенную запись, а проверенному правоохранителю – полные контакты. WHOIS так не мог в принципе; RDAP закладывал эту возможность с первого дня.

День X: 28 января 2025 года

Годы подготовки завершились конкретной датой. Ещё на заседании 30 апреля 2023 года совет директоров ICANN утвердил глобальные поправки к базовым договорам с реестрами и регистраторами, которые предписывали переход на RDAP и назначали закат обязательств по WHOIS на 28 января 2025 года.

С 28 января 2025 года RDAP стал официальным источником регистрационной информации по доменам верхнего уровня общего пользования (gTLD) вместо закрытого WHOIS. Формально это значит вот что: после 28 января 2025 года, когда ICANN официально завершила переход на RDAP, дальнейшее использование WHOIS стало полностью добровольным – никаких санкций за отключение сервиса не предусмотрено.

Обратите внимание на слово «добровольным». WHOIS не запретили и не выключили рубильником в один день. С реестров и регистраторов просто сняли обязанность его поддерживать. Многие продолжили держать порт 43 включённым ради обратной совместимости – но уже по доброй воле, а не по договору.

Насколько быстро индустрия отреагировала? Довольно бодро. В феврале 2025, в течение месяца после даты X, 74 реестра gTLD выключили свой WHOIS-сервис, а к сентябрю 2025 года WHOIS отключили уже 374 gTLD. Более того – произошёл символический перелом: в июне 2025 года объём RDAP-запросов впервые превысил объём WHOIS-запросов. Старый протокол окончательно уступил лидерство.

Приватность в RDAP: меньше данных, чем кажется

Здесь стоит развеять частое и довольно распространённое заблуждение. Многие думают, что RDAP «вернёт» открытые данные о владельцах. Это не так. RDAP – это способ доставки, а не отмена законов о приватности.

Персональные данные регистранта, которые в WHOIS сейчас скрываются, точно так же не будут показаны и в ответах RDAP, поскольку GDPR и другие законы о приватности применяются к нему в равной мере. Иными словами, публичный RDAP-ответ на анонимный запрос выглядит примерно так же обезличенно, как и поздний WHOIS.

Более того, изменились и сами правила сбора данных. Политика регистрационных данных ICANN вступила в силу 21 августа 2025 года после годичного переходного периода и принесла два больших изменения: административные, биллинговые и технические контакты больше не собираются, а регистраторы обязаны вычистить исторические данные из этих полей – отныне ведётся только набор данных регистранта, по принципу минимально необходимого объёма в духе GDPR. На практике это означает, что типичный RDAP-запрос в 2026 году показывает регистратора, даты, серверы имён, коды статусов и обезличенную запись регистранта, тогда как полные данные хранятся у регистратора, но не отдаются в публичный вывод.

А как быть тем, кому персональные данные действительно нужны по закону? Для этого ICANN сделала отдельный шлюз. Работает Служба запросов регистрационных данных (RDRS), предназначенная для тех, у кого есть законный интерес к непубличным данным: правоохранителей, специалистов по интеллектуальной собственности, защитников прав потребителей, специалистов по кибербезопасности и государственных служащих. На практике единственный способ получить закрытые данные – запросить их напрямую у регистратора либо через RDRS и надеяться, что регистратор сочтёт запрос достаточно обоснованным. Гарантий выдачи нет – решение остаётся за держателем данных.

WHOIS против RDAP: короткая сводка отличий

Если свести всё к практике, то разница выглядит так: WHOIS – это открытый текст на 43 порту, без шифрования, без единого формата, без интернационализации, показывает всем одинаково. RDAP – это HTTPS с TLS, структурированный JSON, единая схема полей, нативный UTF-8, стандартные EPP-статусы, автоматическое обнаружение авторитетного сервера через bootstrap IANA и возможность дифференцированного доступа. С точки зрения человека, который просто хочет глянуть дату регистрации, разница почти незаметна. С точки зрения разработчика, который строит мониторинг или антифрод, разница колоссальна: одно дело латать парсеры под каждый реестр, другое – читать предсказуемый JSON.

ccTLD и особый случай зоны .ua

Вся история с обязательным переходом касается gTLD, т.е. доменов вроде .com, .net, .org, .info. А вот с национальными доменами (ccTLD) картина иная и куда интереснее.

Домены с кодом страны, например, .uk, .de или .cn,  управляются собственными регуляторами и пока не обязаны переходить на RDAP, поэтому для них WHOIS остаётся в ходу, что добавляет сложности всем, кто отслеживает регистрационные данные. ICANN над ними власти в этом смысле не имеет: каждый национальный реестр решает сам. Итог закономерен: и WHOIS, и RDAP будут сосуществовать в обозримом будущем, и работать приходится в среде двух протоколов сразу.

Украинская зона .ua – хороший пример реестра, который двигается в ногу со временем добровольно. Администратор публичного домена .ua – компания «Хостмастер». Регламент публичного интернет-сервиса RDAP версии 1.0 у них датирован 1 января 2025 года – прямо к моменту глобального перехода. При этом регламент WHOIS-сервиса версии 1.3 от 2019 года у них продолжает действовать параллельно. То есть в зоне .ua работают оба сервиса одновременно.

Технически всё сделано по канону. Запросы по доменам .UA и другим объектам реестра отправляются на сервер https://rdap.hostmaster.ua, а обращение к https://rdap.hostmaster.ua/help выдаёт информацию о самом сервисе RDAP. Классический же WHOIS для зоны живёт по адресу whois.ua. Сервер .ua возвращает стандартный набор кодов: 302 – если запрос перенаправлен на другой авторитетный RDAP-сервер, 404 – если объект не зарегистрирован, 429 – если превышен лимит запросов, 403 – если клиент заблокирован за злоупотребление. Роли в ответе – тоже стандартные: registrant, administrative, technical. Важная оговорка от самого реестра: оператор реестра предоставляет услугу RDAP исключительно в информационных целях.

Практический вывод для владельцев украинских доменов: если вам нужно проверить .ua, у вас есть оба пути – привычный whois.ua и современный rdap.hostmaster.ua, и структурированный JSON от RDAP удобнее, если вы автоматизируете проверки.

Как всё это выглядит на практике

Обычному пользователю глубоко залезать в протоколы не нужно. Самый простой путь – это воспользоваться официальным инструментом. ICANN рекомендует пользоваться сервисом поиска на базе RDAP по адресу lookup.icann.org, а также открытым консольным клиентом из GitHub. Этот сервис хорош тем, что возвращает структурированные RDAP-данные без рекламы и регистрации, а EPP-коды статусов показывают реальное состояние домена.

Хорошая новость для тех, у кого уже есть домены: паниковать не нужно. Если вы владеете доменом, от вас никаких прямых действий переход на RDAP не требует. Для среднего пользователя смена WHOIS на RDAP почти ничего не меняет: посмотреть регистрационную информацию по-прежнему можно через сервис ICANN на lookup.icann.org, а многие регистраторы ещё какое-то время продолжат давать и WHOIS-доступ, хотя уже не обязаны.

А вот для тех, кто строит на этих данных сервисы – мониторинг доменов, антифрод, защиту брендов, threat intelligence, – совет обратный: имеет смысл переводить свои интеграции на RDAP уже сейчас. Причин несколько. Во-первых, WHOIS для gTLD теперь держится на честном слове, и любой реестр вправе выключить его в любой момент. Во-вторых, парсить JSON надёжнее, чем ловить изменения текстовых шаблонов. В-третьих, тот же RDAP.org и bootstrap-файлы IANA дают предсказуемую маршрутизацию. Единственное, о чём нужно помнить при промышленном использовании, – лимиты частоты: публичные агрегаторы ограничивают клиентов, и при слишком частых запросах вернётся 429, поэтому серьёзным потребителям лучше использовать полноценный RDAP-клиент, работающий напрямую с bootstrap-файлами.

Что осталось нерешённым

К сожалению, как оказалось, у новой системы есть свои «болевые точки».

Первое – фрагментация ccTLD. Пока сотни национальных зон живут по своим правилам, любой глобальный инструмент вынужден поддерживать два протокола и держать в голове десятки исключений. Единого мира RDAP пока нет; есть островки RDAP в океане, где кое-где ещё плещется WHOIS.

Второе – приватность против расследований. RDRS решает проблему доступа к закрытым данным лишь отчасти: решение о выдаче остаётся субъективным, процесс небыстрый, и специалисты по безопасности жалуются, что раскрытие информации о злоумышленниках стало заметно медленнее, чем в эпоху открытого WHOIS. Баланс между правом человека на приватность и потребностью общества ловить мошенников всё ещё нащупывается.

Третье – историческая инерция. Огромное число скриптов, панелей и хостинговых интеграций по-прежнему заточены под текстовый WHOIS. Переписывать их никто не торопится, пока порт 43 где-то работает. Это создаёт ложное ощущение, что «WHOIS жив», хотя формально его уже похоронили для gTLD.

Итог

WHOIS был отличным инструментом для интернета, где все друг друга знали. Он честно прослужил больше сорока лет и заслужил уважительные проводы. RDAP – это тот же справочник, но переосмысленный под реальность, где данные регулируются законами, запросы делают машины, а доступ должен зависеть от того, кто спрашивает. Формально эстафета передана 28 января 2025 года, но по духу переход растянется ещё надолго, и, прежде всего, из-за национальных зон. Практический смысл для владельца сайта простой: домен от смены протокола не пострадает, а если вы автоматизируете работу с регистрационными данными, стройте её на RDAP – за ним будущее, и оно уже наступило.

---

Источники и полезные ссылки

Официальные ресурсы организаций и сервисов, упомянутых в статье.

Координация доменной системы

• ICANN – координирует систему доменных имён, автор поправок о переходе на RDAP;
• ICANN Lookup – официальный поиск регистрационных данных на базе RDAP, без рекламы и регистрации;
• RDRS – шлюз для законных запросов к закрытым (не публичным) регистрационным данным.

Стандартизация протоколов

• IETF – Инженерный совет Интернета, разработчик спецификаций RDAP;
• Рабочая группа WEIRDS – готовила первые RFC по RDAP (7480–7484);
• RFC Editor – тексты стандартов: RFC 9082, 9083, 9224 и более ранние 7480–7484.

Имена, адреса и bootstrap-реестры

• IANA – ведёт корневые данные и bootstrap-реестры RDAP;
• Каталог bootstrap-файлов RDAP – JSON-«карта» авторитетных RDAP-серверов для клиентов;
• RDAP.org – агрегатор-посредник, разруливающий маршрутизацию запросов к нужному серверу.

Региональные интернет-регистратуры (IP и AS)

• RIPE NCC – Европа, Ближний Восток и Центральная Азия (регион Украины);
• ARIN – Северная Америка;
• APNIC – Азиатско-Тихоокеанский регион;
• LACNIC – Латинская Америка и Карибский бассейн;
• AFRINIC – Африканский регион.

Украинская зона .ua

• «Хостмастер» – администратор публичного домена .ua;
• RDAP-сервер .ua – структурированные данные по доменам зоны в формате JSON;
• WHOIS – классический сервис проверки доменов украинской зоны.

Часто задаваемые вопросы о RDAP и WHOIS

Что такое WHOIS?

WHOIS – это протокол получения регистрационных данных о домене или IP-адресе, появившийся в 1982 году. Клиент подключается к серверу по TCP на порт 43, отправляет запрос и получает ответ обычным текстом. Протокол не использует шифрования, не имеет единого формата вывода и не умеет разграничивать доступ к данным.

Что такое RDAP?

RDAP (Registration Data Access Protocol) – современный протокол доступа к регистрационным данным, разработанный IETF на смену WHOIS. Он работает поверх HTTPS как RESTful-сервис, отдаёт данные в структурированном формате JSON, поддерживает UTF-8 и позволяет выдавать разным запрашивающим разный объём информации в зависимости от их прав.

Зачем вообще нужны WHOIS и RDAP?

Они отвечают на вопрос, кто отвечает за домен и как он технически подключён к сети. Эти данные нужны при покупке и проверке домена, оценке доверия к сайту, диагностике поломок DNS и почты, переносе домена между регистраторами, борьбе со спамом и фишингом, защите торговых марок и расследованиях киберпреступлений.

Чем RDAP отличается от WHOIS?

WHOIS передаёт данные открытым текстом на порту 43 без единого формата и без шифрования. RDAP работает по HTTPS с TLS, возвращает структурированный JSON с предсказуемыми полями, использует стандартизированные EPP-коды статусов, корректно обрабатывает интернационализированные домены и умеет находить нужный сервер автоматически через bootstrap-реестры IANA.

Что произошло 28 января 2025 года?

С этой даты RDAP стал официальным источником регистрационных данных для доменов верхнего уровня общего пользования, а поддержка WHOIS перестала быть обязательной для реестров и регистраторов. WHOIS не запретили – с участников рынка просто сняли обязанность его поддерживать, и дальнейшая работа сервиса стала добровольной.

Работает ли WHOIS сейчас?

Частично. Многие реестры уже отключили свои WHOIS-серверы: в течение месяца после января 2025 года это сделали 74 реестра gTLD, а к сентябрю 2025 года – уже 374. Часть регистраторов продолжает поддерживать порт 43 добровольно, ради обратной совместимости. Для национальных доменов WHOIS остаётся основным сервисом.

Покажет ли RDAP имя и контакты владельца домена?

При анонимном запросе – как правило, нет. RDAP не отменяет законы о защите персональных данных: те же поля, что скрыты в WHOIS после вступления в силу GDPR, скрыты и в RDAP. Публичный ответ обычно содержит регистратора, даты, серверы имён, коды статусов и обезличенную запись регистранта.

Как узнать владельца домена, если данные скрыты?

Есть два пути. Первый – обратиться напрямую к регистратору с обоснованием запроса. Второй – воспользоваться службой RDRS (Registration Data Request Service), созданной ICANN для тех, у кого есть законный интерес: правоохранителей, специалистов по интеллектуальной собственности и кибербезопасности, государственных служащих. Гарантий раскрытия нет – решение остаётся за регистратором.

Почему из WHOIS исчезли данные владельцев?

Из-за вступления в силу GDPR 25 мая 2018 года. Публикация персональных данных без законного основания стала нарушением, и регистраторы массово заменили имена, адреса и почту регистрантов на пометки вроде REDACTED FOR PRIVACY. Позже требования ужесточились: с августа 2025 года административные, биллинговые и технические контакты вообще перестали собираться.

Где проверить домен через RDAP?

Проще всего через официальный сервис ICANN по адресу lookup.icann.org – он работает на базе RDAP, не требует регистрации и не показывает рекламу. Для доменов украинской зоны есть отдельный сервер rdap.hostmaster.ua. Существуют также агрегаторы вроде RDAP.org, которые сами направляют запрос к нужному серверу.

Работает ли RDAP для украинских доменов .ua?

Да. Администратор публичного домена .ua – компания «Хостмайстер» – ввёл регламент RDAP-сервиса с 1 января 2025 года, при этом регламент WHOIS продолжает действовать параллельно. Запросы по доменам .ua отправляются на сервер rdap.hostmaster.ua, а информацию о самом сервисе можно получить по адресу rdap.hostmaster.ua/help.

Обязаны ли национальные домены переходить на RDAP?

Нет. Обязательный переход касается только доменов верхнего уровня общего пользования, находящихся в договорных отношениях с ICANN. Национальные домены управляются собственными регуляторами и решают этот вопрос самостоятельно, поэтому у многих из них WHOIS остаётся основным сервисом. На практике это означает сосуществование обоих протоколов на обозримое будущее.

Нужно ли владельцу домена что-то делать из-за перехода на RDAP?

Нет, переход не требует от владельца никаких действий. Домены продолжают работать как прежде, проверить регистрационную информацию по-прежнему можно через сервис ICANN. Изменения касаются в основном разработчиков и сервисов, которые автоматически получают данные о доменах.

Как RDAP находит нужный сервер для конкретного домена?

Через bootstrap-реестры IANA. Это JSON-файлы, публикуемые по HTTP, в которых указано, какой RDAP-сервер обслуживает какую зону или диапазон IP-адресов. Клиент скачивает такую «карту» и дальше обращается напрямую к нужному серверу, без посредников и без перебора адресов.

Есть ли ограничения на количество запросов к RDAP?

Да. Публичные агрегаторы и серверы реестров ограничивают частоту обращений: при превышении лимита возвращается код 429, а за систематические злоупотребления клиент может получить 403. Для промышленного использования лучше применять полноценный RDAP-клиент, который работает напрямую с bootstrap-файлами IANA.

Стоит ли переводить свои сервисы с WHOIS на RDAP?

Да, если вы автоматизируете работу с регистрационными данными – мониторинг доменов, антифрод, защиту брендов. Причин три: WHOIS для gTLD держится на добровольной основе и может быть отключён в любой момент, структурированный JSON надёжнее текстовых шаблонов, а bootstrap-реестры дают предсказуемую маршрутизацию запросов.