DoH налаштування: де DNS-запити йдуть назовні відкритим текстом
Розв'язування імен — найнепомітніший канал витоку в корпоративній мережі. Робоча станція за замовчуванням надсилає запит відкритим текстом на 53-й порт — він виходить за периметр раніше, ніж установлюється захищена сесія із сайтом.
Усередині зашифрованого з'єднання спостерігач бачить лише домен, а відкритий DNS-трафік віддає весь список імен, до яких звертався співробітник.
Що саме дістається спостерігачеві на каналі: провайдеру, транзитному оператору, точці доступу в коворкінгу або готелі. За послідовністю запитів відновлюється карта інфраструктури — внутрішні сервіси, системи моніторингу, файлові сховища, сервіси підрядників.
Час і частота запитів видають графік роботи, розподіл за підрозділами та моменти активності проєктів.
Окремий клас — перехоплення відповідей розпізнавання імен. Спостерігач устигає підмінити відповідь розпізнавання раніше за легітимну, і резолвер кладе підставний запис у кеш. Далі співробітник потрапляє на копію сторінки входу або на порожню відповідь. Підпис зони (DNSSEC) закриває частину випадків, але не працює там, де зона її не публікує.
DoH налаштування починається не з клієнта, а з політики вихідного трафіку. 53-й порт закривається для всіх, крім внутрішніх резолверів, а робочі станції та сервери виходять назовні лише через закріплений набір адрес DoH і DoT.
Тоді витік DNS-запитів закривається, відповіді приходять лише від довіреного резолвера, а сам канал стає керованим і спостережуваним. Розбираємо, як це розгортається на практиці.
Що дає шифрування DNS: приватність, контроль, стійкість
Без шифрування кожен запит на розв'язування імені йде відкритим текстом: посередник на маршруті бачить і саме ім'я, і адресу джерела, а за послідовністю запитів відновлює поведінку пристрою та його власника.
DoH пакує запит у звичайний захищений веб-сеанс, DoT — у виділений канал на окремому порту, і для зовнішнього спостерігача залишається лише адреса резолвера та обсяг трафіку. Приватність розпізнавання імен перестає бути декларацією і стає властивістю транспорту.
Другий ефект — частка підмінених відповідей. Перехоплений запит дешево повернути з підставної адреси, і до появи шифрування це відбувалося непомітно для клієнта.
Шифрування транспорту в зв'язці з перевіркою підпису на резолвері прибирає клас атак цілком: запит не можна прочитати й підмінити в дорозі, а відповідь без валідного підпису відкидається.
У журналах резолвера залишаються спроби втручання, а частка відповідей, що не пройшли перевірку, падає до нуля.
Контроль вихідних запитів з'являється як побічний, але найпрактичніший результат. Поки клієнт може звернутися до будь-якого публічного резолвера — наприклад, до Cloudflare — корпоративна фільтрація обходиться одним перемиканням у налаштуваннях мережі на пристрої.
Правило на периметрі закриває це: прямий DNS назовні заборонений, дозволені лише корпоративні точки DoH/DoT, і тоді всі імена видно в одному журналі, а політики застосовуються централізовано, а не за принципом «у кого як налаштовано».
Стійкість каналу імен — третій вимірюваний ефект. Зміна резолвера перестає бути правкою на кожному пристрої: це зміна адреси точки в конфігурації, яка роз'їжджається парками за один цикл оновлення.
Постійні сесії та кеш на клієнті й на резолвері тримають затримку розв'язування на попередньому рівні, а перемикання між кількома точками за відмови однієї проходить без участі користувача.
Підсумок вимірюється трьома показниками: видимість імен для зовнішнього спостерігача, частка підмінених відповідей і частка запитів, що пройшли корпоративні політики.
Порівняння режимів: DoH, DoT, локальний резолвер і гібрид
Вибір режиму визначається не рівнем «безпеки», а тим, які канали доступні у клієнтів, де живуть внутрішні зони і як швидко потрібно повернутися в робочий стан у разі збою.
На одному підприємстві зазвичай співіснують усі чотири схеми: офісний парк, віддалені співробітники, гостьовий доступ і внутрішні сервісні записи поводяться по-різному, і одна політика на всіх ламається на першому ж обмеженні.
Нижче — робоча матриця: варіант, умови застосовності та те, чим він обмежує супровід.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Шифрування поверх веб-протоколу | Публічні та гостьові мережі, де дозволено лише звичайний веб-трафік; браузери й мобільні пристрої | Трафік не відрізняється від звичайного, тому фільтрацію та розбір на периметрі налаштовують окремо; частина застосунків ігнорує системні параметри |
| Виділений шифрований канал імен | Керований парк, де потрібен передбачуваний канал і зрозуміла точка відмови | Окремий порт легко блокується в партнерських і гостьових мережах, потрібен відкритий вихідний доступ |
| Локальний резолвер | Внутрішні зони, сервісні записи, запити, чутливі до затримки; коли назовні йде один вузол | Ділянка «клієнт — резолвер» залишається відкритою; відмовостійкість і масштабування лягають на інфраструктуру |
| Гібридна схема | Змішаний парк: офіс, віддалені співробітники, гості, окремі застосунки зі своїми налаштуваннями | Дві політики та два контури моніторингу; порядок відкату доводиться описувати заздалегідь, інакше розбіжність конфігурацій накопичується |
Практичний висновок: режим за замовчуванням закріплюють за більшістю клієнтів, а решту схем вмикають точково — під конкретні зони або групи пристроїв.
Перед перемиканням перевіряємо сумісність із поточними фільтрами, внутрішніми зонами та сценарієм повернення до попередніх налаштувань, щоб збій одного вузла не залишав парк без розв'язування імен.
DoH налаштування: етапи впровадження в корпоративній мережі
Порядок робіт тут задає не зручність налаштування, а те, що шифрування переносить точку, де видно вміст запиту. Якщо спочатку увімкнути DoH на клієнтах, мережа втрачає видимість розв'язування імен, а фільтрація та журнали перестають узгоджуватися між собою.
Тому етапи йдуть від інвентаризації до передачі в експлуатацію, і на кожному є свій критерій готовності.
- Аудит схеми розпізнавання. Збираємо перелік резолверів, локальних зон, статичних записів у конфігураціях і застосунків, які вже ходять шифрованими запитами в обхід корпоративного шляху. Результат — карта запитів із зазначенням ініціатора та того, який сегмент куди звертається.
- Проєктування схеми. Визначаємо, де залишається єдина точка виходу, а куди йде резервний шлях. Для керованих пристроїв зазвичай підходить DoT, для роумінгу — DoH поверх стандартного захищеного порту, який пропускають майже всі гостьові мережі.
- Налаштування шифрованого каналу. Профілі на резолверах і клієнтах, довірені сертифікати, перевірка імені сервера, вимкнення незашифрованого резервного запиту або явне правило, коли він допускається.
- Закриття обходу. Блокуємо сторонні шифровані точки на периметрі — інакше політику фільтрації обходять зміною одного налаштування в браузері.
- Перевірка після впровадження. Розв'язування імен у всіх сегментах, додана затримка, поведінка за недоступності резолвера, повнота журналів і кореляція подій.
- Передача в експлуатацію. Регламент оновлення сертифікатів, оповіщення, інструкція з відкату на попередню схему, навчання чергової зміни.
Конфігурації, схеми та регламенти: що залишається на руках
Сенс передачі — у тому, щоб через день після завершення робіт схему можна було змінювати без нас. Тому до комплекту входять не лише налаштовані вузли, а й усе, що описує їхню поведінку: файли конфігурації в репозиторії, топологія, правила та порядок узгодження правок. Нижче — перелік артефактів, які залишаються у вашої команди.
- Конфігурації вузлів — робочі профілі резолверів і шлюзів DoH/DoT, шаблони під різні майданчики, параметри кешу та правила випуску сертифікатів з автоматичним продовженням.
- Схема мережі — топологія з точками перехоплення та виходу запитів, адресація слухачів, маршрути до вищестоящих резолверів і порядок деградації за відмови одного з них.
- Регламент змін — хто і як править конфігурацію, обов'язковий прогін перевірок, вікна робіт, порядок повернення до попередньої ревізії та критерії успішної правки.
- Політики доступу — які команди та сервіси звертаються до вузлів, за якими ознаками розрізняються внутрішні та зовнішні клієнти, як видаються й відкликаються облікові дані.
- Документація інфраструктури — опис компонентів, залежностей і точок відмови, інструкції з типових операцій: додавання майданчика, зміна сертифіката, виведення вузла з експлуатації.
- Моніторинг і оповіщення — метрики затримки відповіді, частки відмов і влучань у кеш, пороги спрацювання та перелік сигналів, що потребують втручання чергового.
- Процедура поетапного відкату — як за хвилини повернути клієнтів до попереднього способу розв'язування імен, не втративши доступність і не розіславши зіпсований кеш.
Кейс: переведення офісної мережі на шифрований DNS
Що було до проєкту
Запити імен з офісної мережі йшли назовні відкритим текстом: їх читав будь-який вузол на шляху, а відповідь можна було непомітно підмінити.
За квартал зафіксували кілька підтверджених випадків — співробітники потрапляли на підставні сторінки авторизації, а розбір кожного інциденту займав години: спочатку довести саму підміну, потім знайти уражені сегменти.
Частка незашифрованих запитів становила 100%, відновлення після збою розв'язування імен — до кількох годин силами чергової зміни.
Що змінили
Шифрування розгорнули у два шари: на робочих станціях — системними політиками та налаштуваннями браузерів, на резолверах підрозділів — на транспортному рівні. Основним зробили Cloudflare, резервний резолвер незалежний, з автоматичним перемиканням за недоступності основного.
Розгортання йшло поетапно: пілотний сегмент, тиждень спостереження за метриками, потім решта офісів — так збій на одній ділянці не перетворювався на загальний.
Результат
Частка відкритих запитів упала зі 100% до 2-3% — залишилися пристрої без підтримки шифрування, винесені в окремий сегмент з обмеженим доступом.
Підтверджених інцидентів із підміною відповідей після переведення немає, а незашифрований запит тепер автоматично вважається приводом для розбору, а не фоном.
Час відновлення за відмови основного вузла скоротився з кількох годин до хвилин: перемикання відбувається без участі чергового, а старі записи продовжують віддаватися з локального кешу, поки резервний резолвер не увійде в роботу.
Чим DoH відрізняється від DoT і коли достатньо одного
Різниця не в стійкості шифрування, а в тому, як трафік виглядає для того, хто дивиться на периметр.
DoH пакує запити всередину звичайної захищеної веб-сесії, тому зовні вони не відрізняються від завантаження сторінки — їх складно вибірково блокувати, але так само складно враховувати в правилах.
DoT іде окремим захищеним каналом на своєму порту: трафік видно як окремий сервіс, зате передбачувано дозволяється, обмежується за адресами та потрапляє в журнали як самостійний потік. Звідси й практичне правило вибору режиму шифрування — за сценарієм, а не за «краще/гірше».
На робочих станціях вирішує не протокол, а те, хто керує налаштуванням. Сучасні браузери вміють вмикати DoH самі, і тоді запити йдуть повз корпоративний резолвер: внутрішні імена перестають розв'язуватися, а картина звернень розпадається.
Робоча схема — вимкнути вбудований режим політикою та направити машини на свій вузол, який уже шифрує трафік назовні.
У серверному сегменті зазвичай достатньо DoT. З'єднання там довгоживучі, навантаження передбачуване, а адміністратору важливо бачити, який вузол куди звертається: окремий канал простіше прив'язати до внутрішнього резолвера та закрити на периметрі.
DoH тут виправданий, якщо сервіс виходить назовні через зворотний проксі і ви не хочете відкривати зайвий порт.
Мобільні пристрої та гостьові мережі дають зворотну картину. Телефони й ноутбуки підтримують обидва режими через штатні профілі, але під час переходу між мережами захищена сесія перевстановлюється, і DoT переживає це важче — помітні паузи під час першого запиту після перемикання.
У гостьових мережах логічніше DoH: він не вимагає публікувати окремий порт назовні, а гостьовий трафік залишається в загальному веб-потоці.
На практиці майже завжди виходить гібрид: DoT усередині периметра, DoH для браузерів і гостьових сегментів, і явна політика, що забороняє клієнтам обирати резолвер самостійно.
Сумісність, відкат і перевірка: технічні сумніви
Перш ніж вмикати шифрування на весь парк, технічні команди перевіряють три речі: як воно уживається з фільтрацією, що відбувається під час відкату і як переконатися, що трафік справді зашифрований. Нижче — відповіді на сумніви, які найчастіше виникають на узгодженні.
Чи не зламає DoH наявну фільтрацію трафіку?
Ні, поки політика залишається на внутрішньому резолвері: клієнт шифрує лише ділянку до нього, а категорії та чорні списки працюють як раніше. Схема ламається там, де застосунки обходять корпоративний резолвер і йдуть на зовнішній — такі випадки закриваємо правилами на периметрі.
Що робити з внутрішніми зонами?
Внутрішні імена мають розв'язуватися лише через корпоративний резолвер, інакше частина сервісів просто перестане відкриватися. Перевіряємо це окремим набором тестів до розгортання на всіх.
Як відкочуються зміни?
Порядок відкату фіксується заздалегідь: клієнтські профілі повертаються на попередні адреси резолверів, правила на периметрі знімаються, конфігурація відкочується до попередньої версії. Той самий сценарій програємо на пілотній групі.
Чи можна увімкнути часткове шифрування?
Так, розгортання йде за групами пристроїв і майданчиками — починаємо з підрозділу, де простіше зібрати зворотний зв'язок. У разі проблем група повертається в попередній режим, решта продовжують працювати.
Як перевірити, що шифрування реально працює?
Дивимося на вихідний трафік: незашифровані запити назовні мають зникнути, а відповіді приходити від корпоративного резолвера. Додатково звіряємо журнали резолвера та тестові домени.
Обговоримо задачу: які дані потрібні для оцінки та плану
Щоб оцінка та план робіт з'явилися після однієї розмови, а не трьох ітерацій уточнень, нам потрібен зріз інфраструктури. Чим точніші вихідні дані, тим менше припущень у проєкті та тим передбачуваніші терміни розгортання шифрування запитів.
- Перелік сегментів і майданчиків: офіси, філії, віддалені підключення співробітників, гостьові мережі, серверні — за кожним важливо розуміти, хто і як виходить в інтернет.
- Поточна схема розпізнавання: які резолвери використовуються всередині, куди звертаються клієнтські пристрої, чи є локальні кешувальні сервери і як вони отримують відповіді.
- Вимоги до журналювання: що потрібно фіксувати (джерело, час, домен, вердикт політики), скільки зберігати і в кого є доступ до вивантажень.
- Правила фільтрації сьогодні: списки й категорії, хто їх веде, як часто вони змінюються і що обов'язково має зберегтися після переходу.
- Інвентар клієнтів під розгортання: операційні системи, мобільні пристрої, обладнання філій, автоматизовані системи та сервісні облікові записи.
- Порядок управління доступом: як видаються права на зміну мережевих налаштувань, чи є окремий контур і хто погоджує правки.
- Обмеження та вікна робіт: внутрішні вимоги безпеки, галузеві норми та періоди, коли допустимо змінювати маршрут запитів.
Цього набору достатньо, щоб повернутися з оцінкою та планом: пілотний сегмент, послідовність розгортання, точки відкату та метрики, за якими перевірятимемо результат. Якщо частина даних недоступна — опишіть, що є, решту зберемо разом.
