Руцентр готує до запуску DNS Guard — систему для раннього виявлення кіберзагроз на рівні DNS. Практична суть не в магічному щиті, а в додатковому спостереженні за доменами: сервіс має помічати зміни записів, нетипові запити й проблеми конфігурації, поки вони ще не спричинили перебої в роботі сайтів або корпоративних сервісів.

За даними дослідження Руцентра за 2026 рік, із доменними інцидентами стикалися 53,4% компаній, тоді як формалізовані правила управління доменами є у 31,5% організацій. Це контекст, який наводить розробник, а не незалежна оцінка ефективності майбутнього продукту. Методика дослідження в описі не наведена. Ці показники описують різні речі: досвід інцидентів і наявність правил. Самі по собі вони не встановлюють причинно-наслідкового зв’язку між політиками компанії та ризиком проблем із доменами.

DNS Guard має поєднати три напрями контролю: аналіз DNS-трафіку, відстеження змін доменних записів і перевірку конфігурацій DNS-зон. Також заявлено виявлення забутих піддоменів та сповіщення про критичні події. Разом це має дати ІТ-команді більше сигналів про стан доменної інфраструктури, але поки йдеться про заплановані можливості, а не про доступний для розгортання сервіс.

Записи, запити та конфігурації — окремі джерела сигналів

DNS-записи пов’язують доменні імена з потрібними сайтами та іншими сервісами. Тому їхня зміна може вплинути на доступність вебресурсу або корпоративної пошти, навіть коли самі сервери й застосунки не зазнають збою. DNS Guard має відстежувати зміни таких записів, зокрема тих, від яких залежить робота цих сервісів.

Для адміністратора важливо побачити зміну в контексті, а не просто отримати ще один запис у журналі. Однак у повідомленні не описано, як система розрізнятиме заплановані зміни та підозрілі, чи зможе встановити, хто саме їх зробив і які кроки пропонуватиме після сповіщення. Тому заявлене повідомлення про критичну подію варто розуміти як привід для перевірки, а не як готовий висновок про атаку.

Заявлений набір контролів охоплює різні питання, які в повсякденній роботі легко змішати. Зміна запису стосується стану домену, аномальний запит — активності, яку бачить система, і аудит зони — її конфігурації. Поєднання цих даних може допомогти команді розбиратися в подіях ширше, ніж за одним типом сигналу. Водночас Руцентр не описує, як саме сигнали будуть зіставлятися або чи матимуть вони спільну шкалу пріоритетів.

Інший напрям — пошук забутих піддоменів, які можуть стати цілями для захоплення зловмисниками. Тут є конкретна операційна проблема: коли доменів багато, повний перелік пов’язаних ресурсів складніше підтримувати актуальним. Піддомен, про який команда вже не пам’ятає, навряд чи сам нагадає про себе в потрібний момент — у цього класу інвентаризації гумор зазвичай закінчується швидше, ніж список записів.

Джерело не уточнює, за якими критеріями DNS Guard визначатиме, що піддомен забутий, і чи буде потрібна ручна перевірка результатів. Так само не наведено деталей щодо способу пошуку таких піддоменів. Отже, сам факт наявності цієї функції в переліку не відповідає на питання, наскільки повним буде знайдений список і як його інтегрувати в наявний облік.

Система також має виявляти аномальні DNS-запити й перевіряти конфігурації зон. Це різні типи спостереження: перший стосується активності запитів, другий — налаштувань доменної зони. Поєднання цих напрямів дає змогу дивитися на інфраструктуру з кількох боків, але аномалія сама по собі не доводить зловмисної активності. У повідомленні не наведено алгоритмів виявлення, критеріїв аномальності чи показників точності, тож оцінити кількість хибних спрацювань поки неможливо.

Для команди, яка підтримує багато доменів, важливим буде не лише факт виявлення, а й подальша робота з сигналом: перевірити його, зіставити з відомими змінами та вирішити, чи потрібне реагування. У джерелі заявлені сповіщення про критичні події, але не описані їхній формат, канали доставки або механізми автоматичного усунення проблем. Тож із наведеного опису випливає саме функція спостереження й повідомлення, а не автоматичне блокування чи виправлення.

Охоплення залежатиме від DNS-інфраструктури

Для аналізу DNS Guard використовуватиме власну DNS-інфраструктуру Руцентра. За поясненням компанії, це дасть змогу знаходити повторювані аномалії в запитах до різних DNS-зон, які вона обслуговує. Це важливе уточнення до опису можливостей: джерело говорить про зони на інфраструктурі Руцентра, а не про безумовний огляд будь-якого DNS-трафіку будь-якої організації.

Якщо домени компанії розподілені між різними провайдерами, у наданому описі немає відповіді, як саме сервіс працюватиме з такою схемою. Не наведені й технічні вимоги до підключення, перелік підтримуваних конфігурацій або спосіб додавання доменів. Це не означає, що таких варіантів не буде; їх просто поки не заявлено. Для команди, яка оцінює продукт, охоплення власних доменів — одне з питань, яке варто буде перевірити перед впровадженням.

DNS Guard орієнтований передусім на середній і великий бізнес із великою кількістю доменів. Для інтеграції з корпоративними системами інформаційної безпеки планують підтримку API. Це може бути суттєво для організацій, яким потрібно обробляти події разом з іншими даними безпеки. Але опис поки не розкриває методи API, формат подій, перелік операцій чи конкретні сценарії інтеграції, тому готовність до підключення до певної системи оцінити не можна.

Коли з’являться деталі API, для інтеграції матимуть значення не лише сам факт його наявності, а й те, які події можна отримувати та в якому вигляді. У наданому повідомленні цього контракту ще немає, тож ІТ-команді зарано оцінювати обсяг робіт із підключення. Так само поки не вказані ціна, дата запуску й умови доступу — практичні параметри, без яких рішення про впровадження не ухвалити.

У заявленому наборі функцій основний результат для адміністратора — видимість змін, запитів і стану DNS-зон, а також сповіщення про критичні події. Про автоматичне блокування запитів, змін або атак джерело не повідомляє. Це межа, яку важливо зберегти в очікуваннях: інструмент раннього виявлення може подати сигнал, але опис не обіцяє, що він сам усуне проблему чи замінить процес реагування команди.

Поки DNS Guard перебуває в розробці та готується до запуску. У повідомленні немає дати виходу, ціни, умов доступу або остаточного переліку можливостей. Тож наразі його можна оцінювати за напрямами контролю та заявленою цільовою аудиторією, але не за реальним охопленням чи роботою інтеграцій. Для майбутнього використання ключовими залишаються практичні деталі: які саме домени сервіс зможе спостерігати, як будуть описані сповіщення і що API дозволить передавати корпоративним системам.