Що таке запис whois насправді
Whois — одна з найстаріших речей, які досі працюють в інтернеті. Протокол описали 1982 року в RFC 812, і він майже демонстративно простий: відкрити TCP-з'єднання на порт 43, надіслати рядок тексту, прочитати те, що прийшло, роз'єднатися. Ні схеми, ні переліку полів, ні домовленості про те, як має виглядати рядок. Кожен реєстр відповідає у власному форматі, власною мовою і з власним уявленням про те, які подробиці важливі.
Саме ця простота дала протоколу сорок років життя — і саме через неї його зараз згортають. Людина прочитає відповідь будь-якого реєстру. Програма — ні: надійно, для всіх реєстрів і без поломки при наступній правці шаблону не вийде.
Друге, що варто знати до читання будь-якого запису: тут дві цілком окремі системи, і їх постійно плутають між собою.
- Записи про домени ведуть доменні реєстри й реєстратори. Вони відповідають на питання «хто тримає це ім'я, через кого і до якого числа».
- Записи про адреси ведуть п'ять регіональних інтернет-реєстрів. Вони відповідають на інше: «якій організації виділено цей блок IP-адрес і хто розбирає скарги на нього».
Різні оператори, різні бази, різні правила — зокрема різні правила приватності, і це найважливіша відмінність. Саме через неї доменний запит сьогодні часто виглядає порожнім, а запит про адресу лишається таким само докладним, як був завжди.
RDAP: заміна, яка вже відбулася
RDAP — Registration Data Access Protocol — робить ту саму роботу через HTTPS і відповідає у форматі JSON зі стандартними назвами полів. Його описали 2015 року в RFC 7480–7484, а документи про запити й відповіді переписали 2021-го як RFC 9082 і RFC 9083. Крім формату, він дав три речі, яких у порту 43 не було ніколи: дані з явно оголошеним кодуванням, машинозрозумілий спосіб сказати «це поле приховано», і бутстрап — реєстр в IANA, який підказує клієнту, який сервер відповідає за конкретне ім'я, адресу чи номер автономної системи. Тобто власний список «зона → сервер whois» більше не потрібен нікому.
Хронологія пояснює, чому різні інструменти зараз розходяться у відповідях. ICANN зробив RDAP обов'язковим для загальних доменів у серпні 2019 року, кілька років обидва протоколи працювали паралельно, а на початку 2025-го вимогу тримати живим порт 43 скасували. Частина операторів досі підтримує його добровільно, дедалі більша частина — ні. Національні домени живуть власним життям: у когось є RDAP, у когось лише порт 43, а дехто пропонує виключно вебформу.
Ця сторінка спершу питає RDAP і переходить на порт 43 лише для зон, де RDAP не опубліковано. Це не любов до нового: RDAP дає названі поля, які ми можемо підписати вашою мовою, а відповідь порту 43 показати можна тільки тим шматком тексту, яким вона прийшла.
Чому доменні записи тепер порожні і що в них лишилося
До 2018 року доменний запит повертав ім'я власника, поштову адресу, пошту й телефон — кожному, хто спитав, без обліку й без обмежень. Коли набув чинності GDPR, ICANN ухвалив тимчасову специфікацію, яка вимагала ці дані приховати, і приховування згодом стало постійною політикою. Замість імені ви тепер бачите рядок про нерозкриття плюс вебформу або пересилальну адресу, яка передає лист, не показуючи одержувача.
Те, що пережило приховування, корисніше, ніж прийнято думати:
- Реєстратор і його номер IANA
- Через яку компанію тримають домен. Це той, з ким говорять про сам домен, і той, від кого йшла б передача.
- Дати створення, зміни й закінчення
- Вік домену — один із небагатьох по-справжньому інформативних сигналів у всьому записі. «Компанія», домен якої створено одинадцять днів тому, цим уже щось про себе сказала.
- Статуси
- Коди EPP, про які нижче. Вони описують, що реєстр зараз дозволяє, і саме в них видає себе прострочений або заблокований домен.
- Сервери імен і стан DNSSEC
- Які сервери є авторитетними для зони і чи підписане делегування. Порівняйте це з тим, що віддає DNS насправді, — розбіжність між ними і є знайденою поломкою.
Записи про адреси приховування такого штибу не торкнулося, бо власник блоку адрес — це зазвичай організація, а не людина. Тому контакт для скарг на адресу досі працює, і тому довідка про адресу каже про власника мережі значно більше, ніж доменний запит каже про власника сайту.
Статуси: те, що пропускають, а потім шукають
Коди EPP — це власний машинозрозумілий опис становища домену від реєстру. Кілька з них пояснюють більшість питань «сайт раптом перестав працювати»:
clientTransferProhibited- Замок реєстратора. Нормальний, здоровий стан для домену, який комусь потрібен: без розблокування передачу не почати. Побачити його — добра новина.
ok- Жодних обмежень. Для особистого домену це нормально; для робочого означає, що між зловмисником із доступом до кабінету й передачею домену не стоїть нічого.
clientHold/serverHold- Домен прибрано з DNS цілком — зона більше не публікується, тож не працює нічого. Ставить реєстратор або сам реєстр, зазвичай за несплату, непідтверджені контакти чи скаргу. Одночасно гасне весь сайт і пошта, тому це виглядає як катастрофа.
autoRenewPeriod- Дата закінчення минула, домен продовжили автоматично. Реєстратор ще певний час може це скасувати, тож несплачений домен якийсь час тихо стоїть тут, перш ніж станеться щось помітне.
redemptionPeriod- Домен видалено. Відновити ще можна, але лише попередньому власнику й лише за окрему плату, навмисно значно більшу за продовження.
pendingDelete- Остання стадія. Через п'ять днів ім'я звільниться. Саме цього коду чекають ті, хто полює на покинуті домени.
Практична арифметика: прострочений домен зазвичай лишається недоступним близько сімдесяти п'яти днів — до сорока п'яти днів автопродовження, тридцять днів відновлення і ще п'ять до видалення. «Він учора закінчився, зараз зареєструю» — майже завжди помилка.
Тонкі й товсті реєстри, або чому два запити розходяться
Одні реєстри зберігають повний запис, інші — майже нічого. Реєстри .com і
.net тонкі: вони тримають реєстратора, сервери імен і дати, і більше
нічого. Усе про власника живе в реєстратора. Більшість нових загальних доменів і чимало
національних — товсті, у них повний запис лежить централізовано.
Тому запит іноді відповідає майже нічим, крім «цим доменом опікується реєстратор X» — це справді все, що реєстр знає. Звідси й друга річ: реєстр і реєстратор можуть одночасно показувати різні дані, і кожен авторитетний у своїй половині — реєстр щодо делегування й дат, реєстратор щодо всього, що стосується клієнта.
Як читати запис про адресу чи автономну систему
Адресний простір роздають п'ять регіональних реєстрів: ARIN — Північна Америка, RIPE NCC — Європа, Близький Схід і Центральна Азія, APNIC — Азійсько-Тихоокеанський регіон, LACNIC — Латинська Америка й Карибський басейн, AFRINIC — Африка. Запис від будь-якого з них зазвичай містить:
- Діапазон і його назву. Точний блок і мітка, яку дав йому власник. У назвах провайдерських мереж часто зашите місто або тип послуги — маленька, але надійна підказка, до якої жодна база геолокації не причетна.
- Власника й країну. Країна тут — де блок зареєстровано, а не де стоїть обладнання. Німецький провайдер може зареєструвати блок, який працює виключно в Польщі, і в записі про це не буде ні слова.
- Батьківське виділення. Чи це блок, який провайдер отримав від реєстру напряму, чи менший шматок, переданий одному з його клієнтів. Коли треба зрозуміти, дивитесь ви на хостинг-компанію чи на її орендаря, відповідь дає саме це поле.
- Контакт для скарг. Скринька, яку власник публікує спеціально для звернень. Її читають значно частіше, ніж прийнято думати, і на коротке фактичне повідомлення з часовими позначками й рядками логів реагують.
Чого запис whois сказати не може
Він не скаже, хто стоїть за сервісом приватності, чи небезпечний сайт і де фізично хтось перебуває. Його також не можна вважати правильним за замовчуванням: реєстри перевіряють дуже небагато з того, що їм вписують, тож блок адрес легко може носити назву компанії, яка припинила існувати роки тому, а доменний запис — ім'я реєстратора, який відтоді продав бізнес. Запис — це свідчення про те, що подали, а не доказ того, що є.
Користуйтеся ним для того, у чому він сильний, — дати, делегування, статуси й адреса для скарги, — і поєднуйте з перевірками, які дивляться на дійсність напряму: що насправді відповідає DNS, що насправді віддає сервер і що про адресу думають поштові системи.