Що таке RDAP (Registration Data Access Protocol)

Стаття також доступна російською (перейти до перегляду).

Щодня у світі реєструються мільйони доменних імен та до них розподіляються IP-адреси. Інтернет регульований так, що до кожного з них є реєстраційні дані, тобто інформація про те хто, коли реєструвався і за що відповідає. Ця інформація зберігається в спеціальних базах даних.

При пошуку за доменом вони включають відомості про:

• Власника (Registrant) – організацію або особу, яка зареєструвала домен;

• Контактні дані: email, телефон, адреса;

• Реєстратора – компанію, через яку зареєстровано домен;

• Дати:

  • created — дата регистрации;
  • updated — дата последнего изменения;
  • expires — дата окончания регистрации.

• Name servers – DNS-сервери, які обслуговують цей домен;

• Статус – активний, заблокований, на передачу тощо;

• Адміністративні та технічні контакти – хто відповідає за роботу домену.

Для IP-адрес база включає дані про:

• Організацію-власника – кому виділено цей блок IP-адрес;

• Тип організації – провайдер, хостинг, корпорація;

• Географічне розташування – країна, місто;

• Діапазон IP-адрес – який блок IP належить організації;

• Контактну інформацію для технічних питань;

• Номер автономної системи (ASN).

Системним адміністраторам ці дані необхідні для налагоджування мережевих проблем, фахівцям з кібербезпеки – для розслідування інцидентів та виявлення зловмисних активностей, а бізнес-аналітикам – для дослідження ринку та перевірки доступності доменів. Але як отримати доступ до цієї інформації? Для цього існують певні протоколи. 

Що таке протокол WHOIS

WHOIS (від англ. «Who is?» – «Хто це?») – це один із найстаріших протоколів Інтернету, який був створений ще в 1982 році. Він розроблявся як простий інструмент для пошуку контактної інформації про людей та організації, які використовують мережеві ресурси.

Принцип роботи WHOIS

Протокол використовує TCP-з’єднання на порту 43 та базується на текстовому форматі обміну даними. Процес запиту виглядає так:

1. Клієнт встановлює TCP-з'єднання з WHOIS-сервером на порту 43;

2. Надсилає текстовий запит (наприклад, назву домену або IP-адресу), завершений символом нового рядка;

3. Сервер обробляє запит і повертає всю доступну інформацію у вигляді неструктурованого тексту;

4. З’єднання закривається.

Протокол був популярний десятиліттями через його простоту в реалізації як на стороні сервера, і на стороні клієнта. Не потрібні складні бібліотеки чи парсери, достатньо базових можливостей роботи з TCP-сокетами. Таке рішення також було дуже універсальним – WHOIS працює практично з будь-якими мережевими ресурсами: доменами всіх рівнів (.com, .org, національні домени), IP-адресами (IPv4 та IPv6), автономними системами (ASN). 

Але протокол не пережив еволюції Інтернету – з розвитком технологій та посиленням вимог до захисту даних він виявився вже не таким привабливим способом отримати потрібні дані. Насамперед користувачам не подобались:

• відсутність стандартизації відповідей;

• проблеми з автоматизацією обробки даних;

• відсутність підтримки міжнародних символів (IDN);

• неможливість надійної аутентифікації;

• невідповідність сучасним нормам конфіденційності, таким як GDPR.

Саме тому йому на заміну прийшов RDAP – протокол, що розроблявся з метою розв’язати проблеми попередника.

Що таке протокол RDAP та як він працює 

Назва протоколу RDAP (Registration Data Access Protocol) чітко відображає його призначення: надавати структурований доступ до інформації про реєстрацію доменів, IP-адрес та автономних систем. Він має той самий базовий функціонал, що й WHOIS, але робить процес набагато ефективніше, безпечніше та зручніше для сучасних потреб.

Робота над його створенням почалась у 2010-х в Інженерній раді Інтернету (IETF). А вже з 2015 року протокол активно впроваджується реєстрами та реєстраторами по всьому світу. ICANN (Internet Corporation for Assigned Names and Numbers) офіційно рекомендує перехід на RDAP, і багато великих реєстрів вже надають його повноцінну підтримку.

RDAP базується на HTTP/HTTPS і JSON-форматі видачі, що робить його набагато зручнішим для представлення реєстраційних даних. Робота з ним виглядає так:

1. Клієнт (наприклад, браузер або RDAP-клієнт) надсилає HTTP/HTTPS-запит до RDAP-сервера реєстру або реєстратора. Зазвичай він має структуру типу: https://<rdap-server>/<object-type>/<query-value>, наприклад, https://rdap.example.net/domain/example.com. Тобто в URL зазначається тип об’єкта (domain, ip, autnum, nameserver, entity) і сам об’єкт для пошуку.

2. Сервер знаходить відповідний запис у своїй базі і формує структуровану відповідь у JSON-форматі.

Оскільки різні реєстри відповідають за різні домени/адреси, RDAP використовує систему bootstrapping, визначену IANA (Internet Assigned Numbers Authority). Клієнт може спочатку звернутися до спеціального bootstrap сервера, щоб дізнатися, який саме RDAP-сервер обслуговує запитану зону (.com, .ua, .org тощо).

Головну роль в процесі грає структурована відповідь у форматі JSON, який може легко читатися машиною.Кожна відповідь містить набір обов’язкових та опціональних полів, що визначені специфікацією RFC 7483. Основними елементами відповіді на запит RDAP про реєстраційні дані є такі блоки.

Главную роль в процессе играет структурированный ответ в формате JSON, которая легко читается машиной.Каждый ответ содержит набор обязательных и опциональных полей, определенных спецификацией RFC 7483. Основными элементами RDAP-ответа о регистрационных данных являются следующие блоки.

{
"objectClassName": "domain",
"handle": "EXAMPLE-COM",
"ldhName": "example.com",
"unicodeName": "example.com"
}

Базовые поля объекта содержат:

• objectClassName – тип объекта (domain, ip network, пустой, сущность, сервер имен);

• handle – уникальный идентификатор объекта в реестре;

• ldhName – имя в LDH-форме (Letters, Digits, Hyphen) для доменов;

• unicodeName – Unicode-представление (для интернационализированных доменов).

Події

[
  {
    "eventAction": "registration",
    "eventDate": "1995-08-14T04:00:00Z"
  },
  {
    "eventAction": "expiration",
    "eventDate": "2025-08-13T04:00:00Z"
  },
  {
    "eventAction": "last changed",
    "eventDate": "2024-08-14T07:15:30Z"
  }
]

Вони вказують на важливі дати: реєстрацію, останню зміну, термін дії тощо.

Статуси

[
  "active",
  "client transfer prohibited",
  "server delete prohibited"
]

Показують поточний стан об'єкта. Основні статуси:

• active – активний;

• inactive – неактивний;

• locked – заблокований;

• pending delete – очікує видалення;

• client/server transfer prohibited – заборона передачі.

Пов’язані сутності

[
  {
    "objectClassName": "entity",
    "handle": "EXAMPLE-REG",
    "roles": ["registrant"],
    "vcardArray": [
      "vcard",
      [
        ["version", {}, "text", "4.0"],
        ["fn", {}, "text", "Example Corporation"],
        ["email", {}, "text", "contact@example.com"]
      ]
    ]
  }
]

Ці дані описують організації та осіб, пов’язаних з об’єктом:

• registrant – власник;

• administrative – адміністративний контакт;

• technical – технічний контакт;

• billing – контакт для білінгу (автоматизованої системи розрахунків);

• registrar – реєстратор.

Контактна інформація зберігається у форматі vCard (RFC 6350).

Name servers (актуально для доменів)

[
  {
    "objectClassName": "nameserver",
    "ldhName": "ns1.example.com",
    "ipAddresses": {
      "v4": ["192.0.2.1"],
      "v6": ["2001:db8::1"]
    }
  }
]

Обробка помилок

Оскільки в протоколі використовується HTTP/S, то і коди статусу видаються стандартизовані. Запит RDAP може видати:

• 200 OK – успішно;

• 404 Not Found – об'єкт не знайдено;

• 400 Bad Request – невірний формат запиту;

• 429 Too Many Requests – перевищено ліміт запитів;

• 500 Internal Server Error – помилка сервера;

• 403 Forbidden – доступ заборонено.

При помилках сервер може повернути JSON з детальною інформацією чому так сталося.

Ключові переваги над WHOIS

Оскільки протокол RDAP є «роботою над помилками» свого попередника, то йому притаманні значні переваги над WHOIS.

Стандартизований формат результату

Це найзручніша перевага, адже замість довільного тексту, який кожен реєстр форматував на свій розсуд, RDAP видає відповідь у JSON. Тут у кожного поля є чітко визначена назва, тип та структура.

Його легко парсити будь-якою сучасною мовою програмування без необхідності писати складні регулярні вирази для кожного реєстру окремо. Це породжує легке керування результатами (paging/sorting), можливість автоматизації запитів та високу сумісність з додатками.

RESTful API

Протокол RDAP побудований на принципах REST (Representational State Transfer) та використовує стандартний HTTP/HTTPS протокол (а отже і безпечне з’єднання TLS) замість спеціалізованого порту 43. Тому він може користуватись стандартними веб-механізмами:

• автентифікацією;

• авторизацією;

• редиректорами;

• пагінацією;

• кешуванням.

У WHOIS такого функціоналу немає. RDAP дозволяє легко інтегруватися з наявною веб-інфраструктурою, не відкриваючи додаткових портів у фаєрволах.

Інтернаціоналізація: підтримка Unicode та різних мов

WHOIS був обмежений ASCII-символами, що створювало проблеми з доменами на кирилиці, китайською, арабською та інших мовах. Нативна підтримка Unicode (UTF-8) у RDAP дозволяє коректно відображати:

• інтернаціоналізовані доменні імена в міжнародних символах (IDN);

• контактну інформацію будь-якими мовами;

• назви організацій у національних алфавітах.

Крім того, багатомовність підтримується через механізм альтернативних представлень одних і тих самих даних різними мовами.

Безпека: обов’язкове шифрування 

На відміну від WHOIS, який передає дані відкритим текстом, RDAP вимагає використання HTTPS. Це гарантує шифрування і зменшення можливостей перехоплення інформації. З’єднання не відбувається, якщо автентичність сервера не підтверджена через SSL/TLS сертифікати.

Також протокол RDAP відповідає GDPR (Загальному регламенту про захист даних), що був введений у 2018 році. А от WHOIS показував персональні дані всім без розбору, порушуючи європейське законодавство.

Аутентифікація: можливість контролю доступу до даних

RDAP підтримує різні механізми аутентифікації, що дозволяє диференційований доступ до даних. На ньому можна реалізувати:

• анонімний доступ;

• API ключі та OAuth 2.0;

• рольовий доступ (RBAC);

• rate limiting з диференціацією.

Це неможливо було в WHOIS через його примітивну архітектуру.

Приклади CURL-запитів до RDAP для отримання даних по доменах та IP адресах

Як це реалізується на практиці? Найпростішим способом отримати потрібні дані є використання RDAP через командний рядок. Базова команда – це curl. Часто використовують публічний редиректор (він перенаправить запит на авторитетний RDAP-сервер):

# Приклад: домен
curl -Ls -H "Accept: application/rdap+json" "https://rdap.org/domain/example.com" | jq
# Приклад: IP-адреса
curl -Ls -H "Accept: application/rdap+json" "https://rdap.org/ip/8.8.8.8" | jq
Але запит RDAP можна виконати і напряму, одразу звертаючись до регіонального/авторитетного сервера:
# RIPE (IP example)
curl -s "https://rdap.db.ripe.net/ip/2001:67c:2e8::1" | jq
# DENIC (DE domains)
curl -s "https://rdap.denic.de/domain/example.de" | jq
Тут -L – слідувати редиректам, -s (silent) – не показувати прогрес завантаження, -S (show errors) – показувати помилки, якщо вони є,
 jq – зручне форматування/фільтрація JSON.

Серед інших варіантів запиту RDAP:

• перевірка статусу домену:

curl -s "https://rdap.org/domain/google.com" | jq '.status, .events[] | select(.eventAction=="expiration")'

• отримання інформації про IP-адресу – знайти, до якого регіонального інтернет-реєстру (RIR) належить IP і хто власник блоку:

curl -s "https://rdap.org/ip/8.8.8.8" | jq '.handle, .name, .country'

• виявлення змін:

curl -s "https://rdap.org/domain/example.com" -o current.json
diff previous.json current.json

RDAP – це сучасний, безпечний і стандартизований протокол доступу до реєстраційних даних, який поступово витісняє застарілий WHOIS. Завдяки використанню HTTP(S) та формату JSON він забезпечує зручну інтеграцію з веб сервісами, автоматизацію перевірок доменів і IP-адрес, а також кращий захист персональних даних.

FREEhost.UA допоможе своїм клієнтам легко користуватися перевагами протоколу, отримуючи перевірені дані, щоб швидше реагувати на будь-які зміни. Завдяки цьому робота з доменами стане більш прозорою, безпечною та комфортною.