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

Майже кожен, хто хоч раз купував домен або намагався з’ясувати, кому належить підозрілий сайт, стикався зі словом WHOIS. А ось абревіатуру RDAP світ дізнався відносно недавно, приблизно тоді, коли старий добрий WHOIS для доменів верхнього рівня офіційно відправили на пенсію. Це не косметична заміна і не ребрендинг – це зміна поколінь: один протокол з’явився в епоху, коли інтернет вміщався в записник, інший створено відповідно до вимог GDPR, автоматизації та машинної взаємодії.

Що ж, давайте детально розберемося з цією темою, з її історією, технічними аспектами, юридичними нюансами та практикою, включаючи специфіку української зони .ua.

Навіщо взагалі існують WHOIS і RDAP

Почати потрібно з простої думки: глобальна доменна система – це спільний ресурс, яким одночасно користується весь світ. Наприклад, доменне ім’я hostingi.net.ua (на якому побудований наш улюблений рейтинг українських хостингів) у всьому інтернеті є лише одне. І оскільки ресурс спільний, має бути спосіб дізнатися дві речі: хто відповідає за це ім’я та як це ім’я технічно підключено до мережі. WHOIS та RDAP – це й є той самий спосіб. По суті, обидва протоколи вирішують одне завдання – дають відповідь на питання «що відомо про цей домен (або IP-адресу) і до кого за ним звертатися». Усе інше – надбудови над цією ідеєю.

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

Купівля та перевірка домену

Найпоширеніший випадок. Перш ніж купити домен, ви хочете знати: чи він вільний, чи зайнятий, а якщо зайнятий – коли закінчується термін реєстрації. Дата закінчення (Expiration Date) – ключова: за нею ловлять імена, що звільняються, планують перекупку, оцінюють, чи варто чекати. Якщо ви купуєте домен з рук, перевірка даних про реєстрацію – це елементарна й необхідна обачність: чи не перебуває ім’я у статусі pendingDelete, чи не точиться щодо нього судовий спір, чи справді продавець ним розпоряджається. Без цієї перевірки легко купити кота в мішку.

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

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

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

Це суто інженерний аспект, і він нікуди не зник навіть після того, як контакти закрили. Коли щось ламається – пошта не «працює», сайт не вирішується, домен «зник» не туди, – насамперед перевіряють сервери імен (NS) та статуси домену. Довідник показує, на які DNS-сервери делеговано ім’я, чи підписана зона DNSSEC, чи не встановлено на домені блокування перенесення. Для адміністратора це відправна точка розслідування: зрозуміти, де саме рветься ланцюжок.

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

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

Боротьба зі зловживаннями

Якщо з якогось домену розсилається спам, поширюється шкідливе ПЗ або працює фішингова копія вашого банку – куди подавати скаргу? Довідник історично надавав контакт для звернень щодо зловживань (abuse) та вказував реєстратора, до якого можна звернутися. Фахівці з кібербезпеки використовують реєстраційні дані для атрибуції – спроби пов’язати різні шкідливі домени в одну інфраструктуру за загальними ознаками (один реєстрант, одні сервери імен, близькі дати створення). Саме через ці сценарії так болісно сприйняли закриття даних після GDPR: знеособлений запис розслідування не зупиняє, але помітно уповільнює його.

Захист брендів та інтелектуальної власності

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

Робота правоохоронців та держорганів

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

Окремо варто підкреслити, що довідник працює не тільки з доменами, а й з IP-адресами та автономними системами – цим займаються регіональні інтернет-реєстратури (RIPE, ARIN та інші). Коли ви бачите в логах підозрілу атаку з конкретної IP-адреси й хочете зрозуміти, якому провайдеру вона належить і куди надсилати звіт про зловживання (abuse-report), – це той самий механізм реєстраційних даних, просто для іншого типу об’єктів.

Якщо звести все до однієї фрази, то сенс сервісів 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, ніякої автентифікації. Будь-хто між вами та сервером міг прочитати і запит, і відповідь. Плюс сам механізм перетворював базу контактів на відкритий буфет для спамерів: адреси електронної пошти реєстрантів були у відкритому доступі, і боти роками їх викачували, щоб завалити власників доменів рекламою та фішингом.

І четверта, найтонша проблема – неможливість розмежувати доступ. 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-сервер – структуровані дані щодо доменів зони у форматі 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-реєстри дають передбачувану маршрутизацію запитів.