Пошук WHOIS пояснено: Повний технічний посібник на 2025 рік
Протокол WHOIS lookup — це протокол запиту та відповіді, який використовується для отримання реєстраційних даних, пов’язаних з доменним іменем, IP-адресою або номером автономної системи (ASN) з загальнодоступної бази даних. Результат включає ідентифікаційні дані реєстранта, адміністративні контакти, дати реєстрації та закінчення терміну дії, сервери імен і реєстратора запису — все це є критично важливим для управління доменами, розслідування зловживань і мережевої діагностики.
Для будь-якого системного адміністратора, дослідника безпеки або власника домену WHOIS — це не просто інструмент пошуку, а фундаментальний рівень інфраструктури прозорості інтернету. Розуміння того, як він працює на рівні протоколу, які дані розкриває (і чому деякі з них тепер приховані), і як ефективно використовувати його в різних середовищах — це необхідні знання для будь-кого, хто керує активами, доступними з інтернету.
Яку інформацію повертає WHOIS lookup?
Дані, що повертаються запитом WHOIS, залежать від реєстру, TLD (домену верхнього рівня) та політики конфіденційності реєстратора. У повністю нередагованому записі можна очікувати такі поля:
Інформація про реєстранта
- Повне юридичне ім’я або назва організації
- Поштова адреса
- Електронна адреса та номер телефону
- Країна реєстрації
Адміністративні та технічні контакти
- Окремі контактні записи для адміністративних і технічних ролей
- Використовуються для авторизації передачі домену, перевірки змін DNS та ескалації зловживань
Деталі реєстрації домену
- Дата створення: Початкова мітка часу реєстрації (UTC)
- Дата оновлення: Остання зміна запису
- Дата закінчення терміну дії: Дата, коли домен стає недійсним, якщо його не поновити — критично важливо для стратегій перехоплення доменів
Записи серверів імен
- Авторитетні DNS-сервери для домену
- Дані серверів імен ніколи не редагуються, навіть відповідно до GDPR, оскільки вони є операційно необхідними
Інформація про реєстратора
- Акредитований ICANN реєстратор, що керує доменом (наприклад, GoDaddy, Namecheap, Tucows)
- IANA Registrar ID для перехресного посилання
Коди статусу домену
- EPP-коди статусу, такі як `clientTransferProhibited`, `serverHold` або `pendingDelete` — їх часто ігнорують, але вони мають важливе операційне значення
Як працює протокол WHOIS: під капотом
WHOIS працює через TCP-порт 43, використовуючи просту модель запиту-відповіді у відкритому тексті, визначену в RFC 3912. Він передує сучасному вебу і залишається одним із найстаріших активних інтернет-протоколів, що досі широко використовується.
Ось повний цикл запиту:
- Клієнт ініціює TCP-з’єднання з WHOIS-сервером на порту 43
- Клієнт передає рядок запиту (наприклад, `example.comrn`) у відкритому тексті
- WHOIS-сервер виконує пошук у базі даних за своїми реєстровими даними
- Сервер повертає запис у вигляді потоку відкритого тексту та закриває з’єднання
Для загальних TLD (gTLD), таких як `.com` та `.net`, запит спочатку потрапляє на тонкий WHOIS-сервер Verisign, який повертає лише дані реєстратора та серверів імен. Потім другий запит надсилається на власний товстий WHOIS-сервер реєстратора для отримання повного запису реєстранта. Ця дворівнева архітектура пояснює, чому деякі інструменти показують неповні дані, якщо вони не виконують обидва запити автоматично.
Для доменів верхнього рівня з кодом країни (ccTLD), таких як `.de`, `.uk` або `.fr`, реєстр сам часто керує товстим WHOIS-сервером із власною схемою та політикою доступу.
WHOIS проти RDAP: сучасний наступник
Протокол доступу до реєстраційних даних (RDAP) — це стандартизована IETF заміна WHOIS, визначена в RFC 7480–7484. На відміну від WHOIS, RDAP повертає структуровані JSON-відповіді, підтримує автентифікацію для багаторівневого доступу та нативно обробляє інтернаціоналізовані доменні імена (IDN).
| Функція | WHOIS (RFC 3912) | RDAP (RFC 7480+) |
|---|
| — | — | — |
|---|
| Формат відповіді | Неструктурований відкритий текст | Структурований JSON |
|---|
| Підтримка автентифікації | Відсутня | Так (багаторівневий доступ) |
|---|
| Інтернаціоналізовані імена | Слабка/непослідовна | Повна підтримка Unicode |
|---|
| Транспорт HTTPS | Ні (TCP-порт 43) | Так (HTTPS) |
|---|
| Стандартизовані назви полів | Ні (залежить від реєстру) | Так (визначені IANA) |
|---|
| Контроль доступу з урахуванням GDPR | Ні | Так |
|---|
| Автоматичне виявлення bootstrap | Вручну | Автоматично через IANA |
|---|
| Заголовки обмеження частоти запитів | Ні | Так |
|---|
ICANN зобов’язав підтримку RDAP для всіх реєстрів і реєстраторів gTLD починаючи з серпня 2019 року. Однак WHOIS продовжує працювати паралельно і залишається домінуючим методом, що використовується інструментами командного рядка та застарілими системами. Для нових інструментів RDAP має бути пріоритетним протоколом.
Типи WHOIS lookup
WHOIS lookup домену
Найпоширеніший тип. Запитує бази даних реєстру та реєстратора для конкретного домену другого рівня (наприклад, `alexhost.com`). Повертає повний запис реєстрації, як описано вище.
WHOIS lookup IP-адреси
Запитує бази даних регіональних інтернет-реєстрів (RIR) — ARIN (Північна Америка), RIPE NCC (Європа/Близький Схід), APNIC (Азіатсько-Тихоокеанський регіон), LACNIC (Латинська Америка) або AFRINIC (Африка) — для ідентифікації організації, якій належить конкретний IP-блок. Це незамінно для звітування про зловживання, перевірки геолокації та усунення несправностей BGP.
WHOIS lookup ASN
Номер автономної системи (ASN) ідентифікує сукупність IP-префіксів маршрутизації під єдиним адміністративним доменом. Запит ASN розкриває мережевого оператора, його політику маршрутизації та IP-діапазони, які він оголошує. Це використовується в аналізі BGP, рішеннях щодо пірингу та атрибуції джерел DDoS.
Зворотний WHOIS lookup
Менш відома, але надзвичайно цінна техніка: замість запиту за доменом або IP, ви запитуєте за іменем реєстранта, електронною адресою або організацією. Це повертає всі домени, зареєстровані під цією організацією — потужний інструмент для захисту бренду, розслідування шахрайства та конкурентної розвідки. Такі інструменти, як DomainTools і ViewDNS.info, підтримують це. Стандартні WHOIS-сервери — ні.
Як виконати WHOIS lookup: всі методи
Метод 1: Інтерфейс командного рядка (рекомендовано для системних адміністраторів)
Команда `whois` доступна нативно в Linux і macOS. У середовищі VPS Hosting під управлінням Debian або Ubuntu пакет може потребувати встановлення:
“`bash
sudo apt install whois -y
“`
Базовий пошук домену:
“`bash
whois example.com
“`
Запит до конкретного WHOIS-сервера безпосередньо (корисно, коли сервер за замовчуванням повертає тонкі дані):
“`bash
whois -h whois.verisign-grs.com example.com
“`
Пошук IP-адреси:
“`bash
whois 93.184.216.34
“`
Пошук ASN:
“`bash
whois AS15169
“`
У Windows нативний `whois.exe` від Microsoft Sysinternals є найзручнішим варіантом:
“`powershell
whois.exe example.com
“`
Порада для системних адміністраторів: При написанні скриптів для масових WHOIS-запитів завжди впроваджуйте обмеження частоти запитів (мінімум 1–2 секунди між запитами). Більшість WHOIS-серверів застосовують жорсткі обмеження частоти і тимчасово заблокують вашу IP-адресу за агресивні запити. Для великих обсягів запитів RDAP із належними заголовками HTTP-кешування є кращим архітектурним вибором.
Метод 2: Онлайн-інструменти WHOIS
Для разових запитів без доступу до термінала існує кілька авторитетних веб-інструментів:
- ICANN Lookup (`lookup.icann.org`) — канонічне джерело; запитує як WHOIS, так і RDAP
- ARIN WHOIS (`search.arin.net`) — для даних IP та ASN Північної Америки
- База даних RIPE NCC (`apps.db.ripe.net`) — для IP-ресурсів Європи та Близького Сходу
- DomainTools — комерційна платформа із зворотним WHOIS, історичними записами та моніторингом
- MXToolbox — корисний для поєднання WHOIS із DNS та перевірками чорних списків в одному робочому процесі
Метод 3: Інтеграція WHOIS у cPanel
Якщо ви керуєте доменами через панель управління, більшість інтеграцій реєстраторів відображають дані WHOIS безпосередньо. На VPS з cPanel інтерфейс WHM надає утиліти пошуку доменів у розділі DNS Functions, що дозволяє адміністраторам перевіряти делегування серверів імен і статус реєстрації, не виходячи з панелі.
Метод 4: Програмний доступ через API
Для автоматизованих конвеєрів моніторингу доступні кілька RDAP та WHOIS API:
“`python
import requests
domain = "example.com"
response = requests.get(f"https://rdap.org/domain/{domain}")
data = response.json()
print(data["ldhName"]) # Domain name
print(data["events"]) # Creation, expiration, last changed
print(data["nameservers"]) # Authoritative nameservers
“`
Сервіс bootstrap `rdap.org` автоматично направляє ваш запит до правильного RDAP-ендпоінту реєстру, усуваючи необхідність жорсткого кодування адрес серверів.
Інтерпретація EPP-кодів статусу: що більшість посібників пропускає
EPP-коди статусу (Extensible Provisioning Protocol) у записі WHOIS часто неправильно розуміють. Вони безпосередньо впливають на те, які операції можна виконувати з доменом:
| EPP-код статусу | Значення | Операційний вплив |
|---|
| — | — | — |
|---|
| `clientTransferProhibited` | Реєстратор заблокував домен від передачі | Не може бути передано іншому реєстратору без розблокування |
|---|
| `clientDeleteProhibited` | Домен не може бути видалений на рівні реєстратора | Захищає від випадкового або зловмисного видалення |
|---|
| `serverTransferProhibited` | Блокування передачі на рівні реєстру | Для зняття потрібні дії реєстру; поширено для нових реєстрацій |
|---|
| `serverHold` | Домен призупинено на рівні реєстру | DNS не вирішується; часто через несплату або зловживання |
|---|
| `pendingDelete` | Домен перебуває в черзі на видалення | Буде звільнено для публічної реєстрації приблизно через 5 днів (для gTLD) |
|---|
| `redemptionPeriod` | Домен закінчився і перейшов у пільговий період відновлення | Може бути відновлено початковим реєстрантом за підвищену плату |
|---|
| `ok` | Без обмежень; нормальний робочий стан | Всі операції дозволені |
|---|
Домен, що показує лише статус `ok` без блокувань передачі, є ризиком безпеки — ініціювати несанкціоновану передачу надзвичайно легко. Завжди переконуйтеся, що `clientTransferProhibited` встановлено для виробничих доменів.
Конфіденційність даних WHOIS, GDPR та система SSAD
Загальний регламент захисту даних (GDPR), що набрав чинності у травні 2018 року, докорінно змінив публічну доступність даних WHOIS для реєстрантів у Європейському економічному просторі. Вплив поширився глобально, оскільки більшість великих реєстраторів застосували політику редагування повсюдно, а не на основі географічного розташування кожного реєстранта.
Що змінилося:
- Персональні дані реєстранта (ім’я, електронна адреса, телефон, адреса) замінюються на `REDACTED FOR PRIVACY` або перенаправляються через службу проксі конфіденційності
- Проксі-адреси електронної пошти, надані реєстратором (наприклад, `abc123@proxy.registrar.com`), замінюють прямі контактні адреси
- Дані серверів імен, ідентифікатор реєстратора та EPP-коди статусу залишаються публічно видимими
Що залишається невирішеним:
Система стандартизованого доступу/розкриття (SSAD) ICANN була запропонована як механізм, що дозволяє перевіреним сторонам (правоохоронним органам, юристам з інтелектуальної власності, дослідникам кібербезпеки) отримувати доступ до непублічних даних WHOIS через централізований шлюз. Станом на 2025 рік впровадження SSAD залишається незавершеним, що створює значний пробіл у робочих процесах розслідування зловживань. Команди безпеки часто повідомляють, що відстеження фішингової інфраструктури та спам-кампаній стало суттєво складнішим після GDPR через відсутність функціонального механізму розкриття інформації.
Практичний наслідок: Коли ви стикаєтеся з повністю редагованим записом WHOIS, шлях ескалації для повідомлення про зловживання проходить через контакт реєстратора з питань зловживань (завжди вказаний, ніколи не редагується) або через систему звітування про зловживання реєстру. Реєстратор зобов’язаний за контрактом відповідно до політики ICANN пересилати скарги на зловживання реєстранту.
Чому важливі WHOIS lookup: реальні випадки використання
Придбання домену та належна перевірка
Перед купівлею домену на вторинному ринку WHOIS lookup розкриває дату закінчення терміну дії, поточного реєстратора та статус блокування передачі. Перевірка історичних записів WHOIS домену (через DomainTools або Wayback Machine) може виявити попереднє використання для розсилки спаму або розповсюдження шкідливого програмного забезпечення, що могло призвести до внесення до чорних списків.
Усунення несправностей DNS
Коли домен не вирішується коректно, поля серверів імен WHOIS є першою діагностичною контрольною точкою. Невідповідність між серверами імен, зазначеними в WHOIS, і фактичними авторитетними серверами в ланцюжку делегування DNS є поширеною першопричиною збоїв вирішення. Це особливо актуально при міграції хостингу між провайдерами — наприклад, перехід на середовище Dedicated Server вимагає оновлення як записів серверів імен у реєстратора, так і конфігурації DNS-зони.
Перевірка видачі SSL-сертифіката
Центри сертифікації, що виконують перевірку домену (DV), можуть звертатися до даних WHOIS. Якщо для вашого домену увімкнено захист конфіденційності, переконайтеся, що проксі-служба вашого реєстратора коректно пересилає листи для перевірки. Неправильні конфігурації тут є поширеною причиною невдалої видачі SSL-сертифіката, особливо для wildcard та мультидоменних сертифікатів.
Розслідування фішингу та зловживань
Команди з безпеки використовують WHOIS для кореляції шкідливих доменів із відомими зловмисниками. Спільні електронні адреси реєстрантів, шаблони серверів імен і кластери часу реєстрації є індикаторами скоординованої інфраструктури. Навіть при редагуванні відповідно до GDPR дані серверів імен і реєстратора часто надають достатні точки для подальшого аналізу.
Захист бренду та захист торгових марок
Юридичні команди використовують WHOIS для ідентифікації кіберсквотерів і подання скарг UDRP (Єдина політика вирішення спорів щодо доменних імен) до ICANN. Проксі-контактна адреса реєстранта є достатньою для ініціювання офіційних процедур.
Конкурентний моніторинг доменів
Відстеження того, коли домени конкурентів реєструються, поновлюються або передаються, може виявити стратегічні сигнали. Перехід домену до нового реєстратора або провайдера серверів імен може свідчити про міграцію платформи або зміну інфраструктури.
Приклад виводу WHOIS: з анотаціями
Нижче наведено репрезентативний запис WHOIS з анотаціями, що пояснюють значення кожного поля:
“`
Domain Name: EXAMPLE.COM
Registry Domain ID: 2336799_DOMAIN_COM-VRSN ← Verisign registry ID
Registrar WHOIS Server: whois.registrar.com
Registrar URL: https://www.registrar.com
Updated Date: 2024-08-15T10:22:00Z ← Last record modification
Creation Date: 2000-01-01T00:00:00Z ← Original registration
Registry Expiry Date: 2026-01-01T00:00:00Z ← Renewal deadline
Registrar: Example Registrar, Inc.
Registrar IANA ID: 1234
Registrar Abuse Contact Email: abuse@registrar.com ← Always public
Registrar Abuse Contact Phone: +1.8005551234
Domain Status: clientDeleteProhibited ← Transfer/delete locks
Domain Status: clientTransferProhibited
Domain Status: clientUpdateProhibited
Name Server: NS1.EXAMPLEHOST.COM ← Authoritative DNS
Name Server: NS2.EXAMPLEHOST.COM
DNSSEC: unsigned ← No DNSSEC — potential risk
“`
Поле `DNSSEC: unsigned` варте особливої уваги. Домен без DNSSEC вразливий до атак отруєння кешу DNS. Для будь-якого домену, що обробляє фінансові транзакції або конфіденційні дані користувачів, підписання DNSSEC слід вважати обов’язковим.
WHOIS для перевірки поштової інфраструктури
Менш відоме застосування WHOIS — перевірка легітимності відправляючих доменів у робочих процесах безпеки електронної пошти. При налаштуванні Email Hosting або аналізі вхідної пошти перехресна перевірка віку реєстрації WHOIS відправляючого домену відносно його обсягу електронної пошти може виявити нещодавно зареєстровані домени (менше 30 днів тому), які є непропорційно активними — це сильний індикатор спамової або фішингової інфраструктури.
Агенти передачі пошти та антиспам-платформи дедалі більше включають дані про вік WHOIS у свої моделі оцінювання поряд із перевіркою SPF, DKIM та DMARC.
Матриця технічних рішень: вибір методу WHOIS
| Сценарій | Рекомендований метод | Примітки |
|---|
| — | — | — |
|---|
| Разова перевірка домену | Веб-інструмент ICANN Lookup | Авторитетний; запитує як WHOIS, так і RDAP |
|---|
| Масовий аудит доменів | CLI `whois` з обмеженням частоти або RDAP API | Скрипт з інтервалами очікування; використовуйте RDAP для структурованого виводу |
|---|
| Автоматизований конвеєр моніторингу | RDAP JSON API | Структуровані дані; підтримує HTTP-кешування |
|---|
| Розслідування зловживань IP | Веб-інтерфейс RIR (ARIN/RIPE) | Використовуйте правильний RIR для географічного розподілу IP |
|---|
| Дослідження історичних даних реєстранта | DomainTools або SecurityTrails | Комерційний; доступні історичні записи до GDPR |
|---|
| Середовище панелі управління | DNS Functions у cPanel або портал реєстратора | Інтегрований; CLI не потрібен |
|---|
| Аналіз ASN та BGP | `whois AS[number]` або RIPE Stat | Поєднуйте з BGP looking glass для повної картини |
|---|
Практичний контрольний список: найкращі практики WHOIS для власників доменів
- Увімкніть блокування передачі реєстратора (`clientTransferProhibited`) для всіх виробничих доменів одразу після реєстрації
- Встановіть захист конфіденційності WHOIS, щоб запобігти розкриттю персональних даних, але переконайтеся, що проксі-служба вашого реєстратора коректно пересилає листи для перевірки зловживань і валідації
- Відстежуйте дати закінчення терміну дії за допомогою автоматичних сповіщень — більшість реєстраторів пропонують це, але додатковий інструмент моніторингу забезпечує резервування
- Перевіряйте точність серверів імен у WHOIS після будь-якої міграції DNS; поширення може тривати до 48 годин, але запис WHOIS має оновитися протягом кількох хвилин
- Перевіряйте статус DNSSEC і вмикайте підписання, якщо ваш реєстратор і DNS-провайдер підтримують це
- Регулярно переглядайте EPP-коди статусу — несподівані зміни статусу можуть свідчити про несанкціонований доступ до облікового запису
- Для доменів, зареєстрованих через сервіси Domain Registration, переконайтеся, що контакт реєстратора з питань зловживань є відповідальним ще до виникнення інциденту
- Після будь-якого інциденту безпеки перехресно перевіряйте запис WHOIS вашого домену в базах даних чорних списків для оцінки репутаційного впливу
FAQ
У чому різниця між тонким і товстим записом WHOIS?
Тонкий запис WHOIS, що повертається реєстром (наприклад, Verisign для `.com`), містить лише назву реєстратора, сервери імен і коди статусу. Товстий запис WHOIS, що повертається власним WHOIS-сервером реєстратора, включає повні контактні дані реєстранта. Більшість інструментів пошуку виконують обидва запити автоматично, але прямий запит до сервера реєстру поверне лише тонкі дані.
Чому WHOIS lookup показує “REDACTED FOR PRIVACY” замість контактних даних?
Після GDPR більшість реєстраторів у всьому світі застосовують редагування конфіденційності до персональних даних реєстранта за замовчуванням або як послугу за вибором. Контакт реєстратора з питань зловживань залишається видимим. Щоб зв’язатися з власником домену, використовуйте проксі-адресу електронної пошти або контактну форму, зазначену в записі.
Чи можна використовувати дані WHOIS як юридичний доказ права власності на домен?
Записи WHOIS самі по собі не є юридично авторитетним доказом права власності — вони відображають реєстраційні дані, а не право власності. У провадженнях UDRP та судових справах записи WHOIS використовуються як підтверджуючі докази поряд із записами облікових записів реєстратора, які є авторитетним джерелом. Для отримання даних облікового запису реєстратора потрібен офіційний юридичний запит.
Як часто оновлюються дані WHOIS після змін?
Бази даних WHOIS реєстраторів зазвичай відображають зміни протягом кількох хвилин або кількох годин після модифікації. Дані на рівні реєстру (сервери імен, коди статусу) поширюються на WHOIS-сервер реєстру протягом кількох хвилин. Однак сторонні агрегатори WHOIS та кешуючі проксі можуть надавати застарілі дані протягом 24–48 годин.
Що означає статус “pendingDelete” і чи можна ще відновити домен?
`pendingDelete` означає, що домен пройшов пільговий період після закінчення терміну дії та період відновлення і поставлений у чергу на видалення реєстром. Для доменів `.com` та `.net` ця фаза триває приблизно 5 днів. Протягом цього періоду початковий реєстрант не може відновити домен — він може бути зареєстрований будь-ким після звільнення. Статус `redemptionPeriod`, що передує `pendingDelete`, є останнім вікном для відновлення, як правило, за значну додаткову плату, що стягується реєстратором.
