Домен, DNS і хостинг: шлях від сайту до відповідальної особи
За кожним сайтом стоять щонайменше чотири різні суб'єкти. Плутанина між ними — причина того, що запит іде не туди, а час втрачено.
- назвати, хто саме володіє потрібними вам даними: реєстрант, реєстратор, реєстр чи хостер;
- прочитати запис WHOIS і зрозуміти, чому дані приховані та що з цим робити;
- розпізнати, що IP-адреса сайту веде на CDN, а не на сервер;
- зафіксувати вебсторінку так, щоб фіксацію не розвалили посиланням на копію без оригіналу.
Ім'я, адреса і DNS між ними
Мережа працює з адресами (заняття 1), люди — з іменами.
DNS — розподілена система, яка перетворює ім'я example.com.ua на IP-адресу.
Розподілена означає, що єдиної бази не існує: запит послідовно проходить кореневі
сервери, сервери зони .ua, далі сервери, які вказав власник домену.
Ім'я читається справа наліво. У shop.example.com.ua крайнє праве
ua — національний домен верхнього рівня; com.ua — публічний домен
другого рівня; example — те, що реєструють; shop — піддомен, який
власник створює сам, без жодної реєстрації. Це має практичне значення: піддомени в
реєстрі не фігурують, і сотні різних сайтів можуть жити на піддоменах одного домену.
Ключові записи в зоні: A і AAAA — IP-адреса вузла (IPv4 і IPv6); NS — які сервери відповідають за зону; MX — куди йде пошта домену. Записи змінюються за хвилини. Тому «IP-адреса сайту» без дати й часу фіксації — величина, яка нічого не значить.
За кожним рівнем — свій розпорядник і свій адресат запиту. Дані про реєстранта веде реєстратор; технічну базу зони — адміністратор публічного домену; вміст сайту — хостер, який може не мати жодного відношення до перших двох.
Чотири суб'єкти, яких плутають
Реєстрант — особа, яка користується доменом і розпоряджається ним. Це той, кого
ви шукаєте. Реєстратор — суб'єкт господарювання, який надає реєстранту послуги
реєстрації й технічного забезпечення домену; саме він має договір і дані реєстранта.
Адміністратор публічного домену веде базу для зони: для .UA це
Hostmaster LLC, який забезпечує роботу домену, підтримує DNSSEC, IDN і RDAP і працює з
реєстраторами. Хостер — компанія, на серверах якої фізично лежить сайт; вона
володіє логами доступу й самим вмістом.
Правила домену .UA прямо визначають розподіл: для отримання повної
інформації про реєстранта потрібно звертатися до реєстратора, а будь-яка інша інформація
про доменне ім'я надається адміністратором публічного домену за письмовим мотивованим
запитом. Достовірність даних у базі гарантують реєстрант і реєстратор за своїми
договорами; адміністратор за правдивість цих даних не відповідає — він відповідає за їх
зберігання й публічну доступність. Практичний висновок: запис WHOIS — це те, що
заявив реєстрант, а не перевірений факт.
WHOIS і RDAP: що видно і чому приховано
WHOIS — публічний запит до бази реєстру. Він показує реєстратора, дати реєстрації й завершення, NS-сервери, статуси домену. Дані реєстранта у 2020-х майже завжди приховані: у полях стоїть redacted for privacy, not published або технічна адреса на кшталт b98cc…@withheldforprivacy.com. Причини дві: вимоги захисту персональних даних і платні privacy-сервіси реєстраторів.
RDAP — сучасніший протокол із тією самою функцією, структурованою відповіддю і розмежуванням доступу. Для правоохоронця важливо, що приховані поля не означають «даних немає»: вони є в реєстратора, і шлях до них — процесуальний.
Окремий механізм, про який часто не знають: у домені .UA діє процедура
вирішення спорів, у межах якої реєстратор на запит верифікації блокує доменне ім'я
й надає витребувану інформацію протягом двох робочих днів. Це не інструмент досудового
розслідування, але корисно знати, що технічна можливість швидкого блокування існує й
використовується.
| Суб'єкт | Які дані має | Рівень | Підстава / шлях |
|---|---|---|---|
| Публічний WHOIS / RDAP | реєстратор, дати, NS, статуси | акаунт | відкрито, без дозволу |
| Реєстратор домену | договір, ПІБ або назва, контакти, платіжні дані, IP входів у панель | особа | тимчасовий доступ, ухвала слідчого судді (гл. 15 КПК) |
| Адміністратор публічного домену (.UA — Hostmaster LLC) | історія записів у базі, зміни NS і контактів | акаунт | письмовий мотивований запит; для таємниці — ухвала |
| Хостер | файли сайту, бази, логи доступу, IP адміністратора, договір | особа | ухвала; для зарубіжного — міжнародний запит |
| CDN / реверс-проксі | IP реального сервера походження, логи запитів | зона | як правило зарубіжна компанія: міжнародний запит |
| Реєстратор ТМ / ЄДР | хто стоїть за назвою бренду на сайті | особа | відкриті реєстри |
| Платіжний провайдер на сайті | реквізити отримувача коштів, ідентифікація мерчанта | особа | ухвала; часто найкоротший шлях до особи |
| Сертифікат TLS | кому виданий, коли, інші домени в тому самому сертифікаті | акаунт | відкрито; публічні журнали прозорості сертифікатів |
| Записи MX | де обслуговується пошта домену | зона | відкрито |
| Реверсний перегляд по IP | які ще домени на тому самому сервері | зона | відкриті сервіси; на спільному хостингу малоінформативно |
| Код сторінки | ідентифікатори аналітики й реклами, спільні для мережі сайтів | акаунт | відкрито; сильний зв'язок між ресурсами |
| Архіви вебсторінок | вміст у минулому, попередні контакти в WHOIS | акаунт | відкрито; дата індексації ≠ дата розміщення |
| Соцмережі й месенджери, вказані на сайті | акаунти адміністраторів | акаунт | див. заняття 5 |
Чому IP сайту зазвичай не є адресою сервера
Більшість помітних сайтів працює через CDN або реверс-проксі: користувач з'єднується з
вузлом мережі доставки контенту, а той уже — зі справжнім сервером. Наслідок для
розслідування: A-запис веде на інфраструктуру CDN, найчастіше зарубіжної
компанії, і «встановити хостинг» через ping не вийде. Ознаки
CDN: адреса належить діапазону відомої платформи (перевіряється через RIPE за
методом заняття 1), а NS-записи вказують на її сервери.
Що працює замість цього: запис MX (пошту через CDN проксують рідко); історичні DNS-записи, зроблені до підключення CDN; журнали прозорості сертифікатів; ідентифікатори аналітики, спільні з іншими ресурсами тієї самої групи; і платіжні реквізити на сайті. Останнє на практиці дає результат частіше за все технічне разом.
Фіксація вебсторінки: де падають такі докази
Оригінал і копія електронного доказу: практика Верховного Суду
- 29.03.2021Постанова ОП ККС ВС у справі № 554/5090/16-к (провадження № 51-1878кмо20): аналізується співвідношення оригіналу й копії електронного доказу та правова оцінка тверджень щодо цілісності.
- 25.09.2023Постанова ОП ККС ВС у справі № 208/2160/18 — друге ключове рішення, на яке спираються суди при оцінці допустимості електронних доказів.
- і даліСудді ККС ВС публічно фіксують, що поки триває законотворчий процес, питання допустимості електронних доказів урегульовує судова практика.
З матеріалів практики видно типовий аргумент: різницю у форматі запису захист подавав як можливість умисного технічного втручання й підробки електронного доказу. У частині випадків суди з цим погоджувалися й визнавали доказ недопустимим. Тобто оспорюють не зміст сторінки, а те, як її отримали й чи можна перевірити цілісність.
Він переносить акцент із «що було на сайті» на «чи можемо ми довести, що саме це було на сайті». Скриншот у документі Word — найслабша форма фіксації: немає ні оригіналу, ні способу перевірити цілісність, ні прив'язки до часу. Це стосується не лише вебсторінок, а всього, що ви вилучаєте в цифровій формі, — тому саме тут закладається робоча звичка.
- У чому питання
- КПК не містить окремого визначення «електронного доказу» й вичерпних вимог до фіксації вебсторінки. Тому мінімально достатня форма визначається практикою й відрізняється між судами: десь достатньо огляду з протоколом і носієм, десь вимагають залучення спеціаліста або експертизи.
- Чому це важливо
- Помилка виявляється не одразу, а в суді через рік, коли повторно зафіксувати сторінку вже неможливо: ресурс змінено або вилучено.
- Що перевірити
- Чинну редакцію ст. 99 КПК щодо документів; згадані постанови ОП ККС ВС у Єдиному державному реєстрі судових рішень (reyestr.court.gov.ua) за номерами справ; і практику апеляційного суду свого регіону за останній рік — саме вона визначить, що приймуть у вас.
Чекліст фіксації вебсторінки
- дата, час і часова зона фіксації; хто фіксував;
- повна адреса сторінки, а не лише назва сайту;
- збереження сторінки цілком, а не зображення екрана: HTML з ресурсами або PDF-версія плюс вихідний код;
- окремо — службові дані: IP, на який тоді вказував домен, і WHOIS на дату фіксації;
- контрольна сума (хеш) файлів і зазначення алгоритму в протоколі;
- запис носія, який долучається як оригінал, і те, що саме на ньому;
- відео процесу фіксації, якщо ресурс імовірно зникне;
- пояснення, чому копія відповідає оригіналу, — заздалегідь, а не у відповідь на заперечення.
Як провести це заняття з групою
- Вправа 1 (10 хв). Один домен на екрані. Група має розписати чотири адресати запиту й що просити в кожного. Перевірка розуміння — чи не пішли всі в реєстратора по логи сайту.
- Вправа 2 (10 хв). Візьміть WHOIS із прихованими даними. Питання: які три речі все одно можна встановити з цього запису і що з них корисне.
- Вправа 3 (15 хв). Розберіть спосіб фіксації, яким підрозділ користується зараз, за чеклістом вище. Зафіксуйте письмово, які пункти не виконуються, — це і є перелік ризиків у справах, які вже в суді.
Порядок роботи з вебресурсом
- Спершу зафіксуйте, потім досліджуйте. Ресурс може зникнути за годину. Фіксація за чеклістом — перша дія, не остання.
- Розберіть ім'я на рівні й визначте, що піддомен, а що зареєстрований домен: адресат запиту різний.
- Зробіть WHOIS / RDAP і збережіть відповідь із датою. Через тиждень запис може бути іншим.
- Перевірте, чи це CDN: діапазон адреси через RIPE, NS-записи. Якщо так — технічний шлях до сервера довгий, ідіть паралельно через платежі й сертифікати.
- Розішліть запити паралельно, а не послідовно: реєстратор — дані договору; хостер — логи й вміст; платіжний провайдер — отримувача коштів.
- У документі розділяйте рівні. «Реєстрантом домену за даними реєстратора є Х» — це особа щодо реєстрації домену, і водночас не доказ, що Х наповнював сайт. Наступний крок — заняття 3: прив'язка до апарата й абонента.
Чотири питання на розрізнення
1. У WHOIS домену .UA дані
реєстранта приховані, вказано лише реєстратора. Що це означає?
Ні. Приховування в публічній базі не означає відсутності даних. Правила домену .UA прямо вказують: повну інформацію про реєстранта отримують у реєстратора.
Так, обидві частини. Достовірність даних гарантують реєстрант і реєстратор за договором; адміністратор зони відповідає за зберігання й доступність, а не за правдивість. Тому отримані дані ще треба перевіряти.
Ні. Приховування контактів — законна практика, пов'язана із захистом персональних даних і платними privacy-сервісами.
Ні, хоч частково логічно. Адміністратор надає іншу інформацію про доменне ім'я за письмовим мотивованим запитом, але дані реєстранта повністю — у реєстратора. Запит не тому адресату — це втрачені тижні.
2. Ви встановили, що домен зареєстрований на громадянина Х. На сайті — оголошення про збут заборонених речовин. Що встановлено?
Ні. Реєстрація домену й наповнення сайту — різні дії різних людей у більшості випадків. Домени купують, перепродають, реєструють на підставних осіб.
Ні. «Щонайменше причетний» — це не рівень ідентифікації, а припущення. У документі воно перетвориться на твердження, якого ви не доведете.
Так. І зверніть увагу, що найсильніший доказ тут — не домен, а логи входів у панель хостингу з прив'язкою до IP і часу, тобто повернення до методу заняття 1.
Ні. Реєстранта встановлено — це реальний результат. Помилка в іншу сторону: недооцінити наявний рівень так само шкідливо, як завищити його.
3. A-запис домену вказує на адресу,
яка за RIPE належить великій зарубіжній платформі доставки контенту. Що робити?
Частково правильно, але це не перший крок. Платформа зарубіжна, шлях — міжнародний запит, місяці. Спершу вичерпайте те, що дає результат швидше.
Ні, це груба помилка. Ви зафіксуєте вузол мережі доставки, а не сервер. У документі це буде хибне твердження про факт.
Так. Пошта й історія DNS часто «протікають» повз CDN, а платіжні реквізити ведуть до особи швидше за будь-яку технічну лінію.
Ні. CDN зарубіжна, сервер походження може бути в тому самому місті, що й підозрюваний. Одне з іншого не випливає.
4. Сторінку зафіксовано скриншотом, вставленим у довідку. Ресурс через тиждень видалено. Наскільки це проблема?
Ні. Підпис не робить зображення екрана перевірним. З практики видно, що захист успішно ставив під сумнів цілісність саме таких матеріалів.
Ні. Достатньо аргументу про неможливість перевірити цілісність та співвідношення оригіналу й копії — експертиза для цього не потрібна.
Так. Правильна реакція — не сперечатися, а негайно шукати альтернативні носії вмісту й фіксувати їх належно. І змінити практику фіксації на майбутнє.
Ні, хоч архів і корисний. Архівний знімок — окреме джерело зі своєю датою індексації, яка не збігається з датою розміщення вмісту. Він доповнює, а не «відновлює» неналежну фіксацію.
Блок I завершено. Далі — заняття 3: мобільний абонент і апарат, чотири номери, які плутають між собою, і межі точності локалізації за мережею.