DNS over HTTPS і DNS over TLS: приватність без порушення роботи корпоративних мереж

Що ви насправді змінюєте, вмикаючи DoH/DoT

Класичний DNS переважно працює по UDP/53 (плюс TCP/53 для великих відповідей, DNSSEC і передач зон). Він швидкий, повсюдний
і болісно спостережуваний. Спостережуваність працює в обидва боки: ваш провайдер бачить, куди ви йдете, і будь‑хто в шляху з пакетним захопленням і недобрим наміром теж.

DoT (DNS over TLS) загортає DNS у TLS, зазвичай на порт 853. DoH (DNS over HTTPS) загортає DNS у HTTP/2 або HTTP/3 поверх TLS,
зазвичай на порт 443. Обидва шифрують питання й відповідь. Обидва захищають від пасивних спостерігачів в мережі.
Жоден з них не робить DNS автоматично «коректним» у сенсі «правильного» — це все ще питання цілісності резольвера,
валідації DNSSEC і не розміщення всієї інфраструктури на відчуттях.

У корпоративних мережах DNS — це більше ніж просто резолюція імен:

• Ідентифікаційний зв’язок: внутрішнє виявлення сервісів, AD, Kerberos і SSO‑флоу.
• Точка політик: блок‑лайсти, sinkhole‑и, категорійна фільтрація та контролі витоку даних.
• Телеметрія: логи DNS — це недорогий ранній сигнал тривоги.
• Сегментація: split‑horizon DNS — як ви тримаєте внутрішні імена внутрішніми.

Шифруйте DNS без плану — і ви не просто «підвищите приватність». Ви мовчки обходите власні контролі.
Потім вперше, коли хтось не може дістатися до внутрішнього хоста, бо його ноут питає публічний резольвер,
ви почуєте фразу, яка мала б бути заборонена в регульованих галузях: «Але у мене це працює на домашньому Wi‑Fi».

Факти та історія, які важливі в операціях

• DNS з’явився у 1983 році (ера RFC 882/883). Він був створений для більш доброзичливої мережі, де «шифрування повсюди» не було стандартом.
• DNSSEC почався наприкінці 1990‑х і дозрів у 2000‑х. Він захищає автентичність, а не приватність. Люди постійно це плутають.
• Підпис кореневої зони запрацював у 2010, що зробило валідацію DNSSEC значущою наскрізно для багатьох доменів, якщо ваш резольвер дійсно валідує.
• DoT стандартизовано у 2016 (RFC 7858). Він простий, прямий і помітний у мережі: TLS на порт 853 зазвичай вирізняється.
• DoH стандартизовано у 2018 (RFC 8484). Він ховається всередині звичайного HTTPS — у цьому сенс і оперативна головний біль.
• Firefox увімкнув DoH за замовчуванням у деяких регіонах близько 2019–2020 через rollout TRR. Підприємства відкрили його «цікавим» способом: отримавши тікети.
• EDNS0 розширив DNS, щоб відповіді могли перевищувати 512 байт по UDP, зменшуючи fallback на TCP — добре для продуктивності, складно для middlebox‑ів, які ніколи не навчились.
• QNAME minimization став кращою практикою для зменшення витоків даних до авторитетних серверів. Це допомагає приватності навіть без DoH/DoT, але залежить від поведінки резольвера.
• Encrypted ClientHello (ECH) — наступний фронтир: воно може приховати SNI. Коли ECH стане поширеним, «блокувати DoH по SNI» швидко стане слабким заходом.

Індустрія не прокинулася одного ранку і не вирішила шифрувати DNS заради забави. Це реакція на повсюдний моніторинг,
ISP‑рівневе спотворення DNS і на те, що незашифрований DNS — це маячок для відстеження з чудовою доступністю.

Модель загроз: кого ви захищаєте і від чого

«Приватність» — це не функція; це рішення щодо супротивників. Для корпоративних мереж зазвичай є три категорії:

1) Пасивні спостерігачі в недовірених мережах

Кав’ярні, готелі, аеропорти. DoH/DoT дуже допомагають тут. Якщо у вас є віддалені працівники і немає завжди‑включеного VPN,
шифрований DNS — один з небагатьох контролів, що працює, коли мережа ворожа.

2) Маніпуляції на шляху

Captive portal‑и, шкідливе програмне забезпечення, що інжектує NXDOMAIN, «допомога» провайдера, що перенаправляє помилки на рекламні сторінки.
TLS усуває більшість цього. DNSSEC також допомагає, але його розгортання нерівномірне, і багато stubs не валідують; резольвери роблять це.

3) Ваші власні корпоративні контролі (так, ви тут — супротивник)

Ви логируєте DNS для виявлення. Ви блокуєте відомі зловмисні домени. Ви спрямовуєте внутрішні зони на внутрішні сервери.
Шифрований DNS може обійти ці контролі, якщо не надати санкціонований зашифрований резольвер і не змусити клієнтів ним користуватися.

Справжня корпоративна мета — не «відключити DoH». Мета — «зробити так, щоб шифрований DNS проходив через наш резольвер, де йому місце».
Блокування — це грубий інструмент. Іноді необхідний, але рідко достатній.

Одна перефразована ідея, яка переслідує операції десятиліттями: надія — це не стратегія — приписують Едсгеру В. Дейкстрі (перефразовано, не дослівно).
Якщо ви «сподіваєтеся», що клієнти не будуть використовувати публічні DoH‑ендпоїнти, ви вже відстаєте.

DoH vs DoT: практичні відмінності (не маркетинг)

Транспорт і видимість

• DoT: TLS на порті 853. Легко ідентифікується і піддається політиці на фаєрволі. Також легко зламати випадково, якщо правила egress суворі.
• DoH: HTTPS на порті 443. Важче відрізнити від звичайного веб‑трафіку без TLS‑інспекції, endpoint‑контролю або списків відомих ендпоїнтів.

Операційні точки контролю

Якщо ви керуєте кінцевими точками (MDM/GPO), DoH контрольований: ви можете встановити системні резольвери, налаштувати політики «secure DNS»,
і прив’язати їх до вашого резольвера. Якщо ви не керуєте кінцевими точками, DoH стає «функцією браузера, яка тепер — ваша проблема у мережі».

Характеристики продуктивності

DoH може їхати по існуючих HTTPS‑з’єднаннях, повторно використовувати TCP/TLS і добре поводитися по HTTP/2. В деяких середовищах це швидше,
особливо на мережах із втратою пакетів. В інших додає накладних витрат і складнощі з проксіями. DoT простіший: одна TLS‑сесія до резольвера,
багато запитів.

Middlebox‑и і проксі

Корпоративні проксі часто розуміють HTTP; вони не розуміють «семантику DNS всередині HTTPS». Проксі може охоче форвардити DoH,
поки ваша команда безпеки втрачає видимість DNS — це як зачинити вхідні двері, але прибрати стіни.

Жарт №1: DNS — це єдина система, де ви можете бути «вниз», «вгору» і «працює так, як задумано» одночасно, залежно від того, хто питає.

Як корпоративний DNS ламається: split‑horizon, проксії та «допоміжні» middlebox‑и

Split‑horizon DNS і чому DoH/DoT можуть його обходити

Split‑horizon означає, що внутрішні клієнти отримують внутрішні відповіді для внутрішніх імен, а зовнішні — зовнішні відповіді.
Це використовується для:

• Імен, що доступні лише всередині (наприклад, git.corp)
• Різних відповідей залежно від місця (всередині vs ззовні)
• Безпеки: не розкривати внутрішню топологію

Якщо ноут використовує публічний DoH (наприклад, резольвер в інтернеті) під час роботи через VPN — або ще гірше, будучи в офісі —
він може:

• Не вміти резолвити внутрішні імена (інцидент доступності)
• Резолвити на публічні адреси (ризик витоку даних, неправильна маршрутизація)
• Витікати патерни внутрішніх запитів зовнішній стороні (приватність та конфіденційність)

DNS‑базовані засоби безпеки і що з ними робить шифрований DNS

Якщо ви блокуєте шкідливі домени на резольвері, і клієнти обходять цей резольвер, ви просто обміняли «попередити» на «виявити пізніше»
(якщо взагалі зможете). І багато організацій цього не можуть. Вони запускають правила SIEM, що припускають наявність логів DNS.

Шифрування не є ворогом. Ненадмірене шифрування є.

Middlebox‑и, які неправильно обробляють сучасні фічі DNS

Навіть з простим DNS middlebox‑и можуть ламати речі:
EDNS0, DNSSEC, фрагментований UDP, fallback на TCP. З DoT/DoH режим відмов змінюється:
TLS‑інспекційні коробки, що блокують невідомий SNI, HTTP‑проксі, що таймаутять довго живі з’єднання,
та egress‑NAT‑и, що швидко міняють порти настільки, що резольвери виглядають ненадійними.

Рекомендована архітектура для підприємства: приватні резольвери + політика + контрольоване шифрування

Північна зірка

Забезпечте корпоративний сервіс резольвера, який підтримує:

• Внутрішні зони (авторитетні або переспрямовані)
• Валідацію рекурсії (DNSSEC вкл.)
• Політи загроз (RPZ або еквівалент) з контролем змін
• Шифровані endpoint‑и (DoT і/або DoH) для клієнтів
• Логування з урахуванням приватності та обмеженням зберігання
• Високу доступність (anycast або принаймні резервні сайти)

Де термінувати шифрування

Термінацію DoH/DoT робіть на своїх резольверах, а не на випадковому периферійному боксі, що не має контексту DNS.
Тримайте резольвери максимально близько (мережево) до клієнтів; затримка має значення.
Тоді ваш резольвер може спілкуватися з upstream‑резольверами або авторитетними серверами використовуючи:

• Простий DNS (прийнятно в контрольованих мережах, але менш приватно)
• DoT до upstream (хороший компроміс)
• DNS over QUIC (новинка; ставте в тест‑лаб, поки не впевнені)

Стратегія контролю клієнтів

• Керовані кінцеві точки: налаштуйте на рівні ОС DoH/DoT на ваші резольвери; зафіксуйте в браузері «secure DNS» на системний резольвер або корпоративний endpoint.
• Некеровані / BYOD: можуть знадобитися мережеві контроли (фільтрація egress, політики captive portal, NAC) і документ «як отримати доступ — використовуйте наш DNS».

Не плутайте «блокувати публічний DoH» зі «вирішенням проблеми»

Блокування відомих DoH‑ендпоїнтів за IP або SNI — це whack‑a‑mole. Воно може швидко знизити ризик, але не є сталим,
оскільки інтернет рухається до ECH і провайдери хостять DoH за CDN. Довгострокова стратегія — політика на кінцевих точках і
надання кращого шляху: вашого власного захищеного резольвера з порівнянною продуктивністю.

Жарт №2: Найпростіший спосіб знайти недокументовану залежність — увімкнути DoH і спостерігати, які внутрішні додатки почнуть одразу кричати.

Три міні‑історії з корпоративного життя

Міні‑історія 1: Інцидент через неправильне припущення

Середня компанія розіслала мемо про «покращення приватності»: «Увімкніть Secure DNS у браузері». Здавалося безпечно.
Команда безпеки підтримала ідею. Хелпдеск теж — бо звучало як менше проблем з Wi‑Fi.
Ніхто не спитав, який саме резольвер буде використовуватися.

За тиждень внутрішні веб‑додатки почали падати для віддалених працівників на VPN. Відмова була дивно вибірковою:
дехто міг дістатися intranet.corp, інші отримували таймаути, а кілька людей переадресовувалися на публічну сторінку.
Мережна команда перевірила split‑tunnel маршрути і налаштування DNS у VPN. Все виглядало добре.

Неправильне припущення було простим: «Якщо ви в VPN, ви муcите використовувати корпоративний DNS». Не правда.
Браузери надсилали DoH‑запити до публічних резольверів через тунель VPN (або іноді поза ним, залежно від маршрутизації клієнта),
обходячи внутрішні DNS‑погляди. Внутрішні імена не були доступні публічно, отже вони падали. Деякі імена, що існують зовні,
резолвилися на публічні сервіси — що ще гірше.

Виправлення не було «вимкнути DoH». Виправлення було у наданні корпоративного DoH‑ендпоїнта, налаштуванні керованих браузерів на його використання
і примусі на кінцевих точках, щоб «secure DNS» використовував корпоративні резольвери. Тоді внутрішні зони стали консистентними,
а команда безпеки відновила DNS‑телеметрію — на резольвері, а не на мережі.

Міні‑історія 2: Оптимізація, що обернулася проти

Велике підприємство вирішило знизити затримку DNS, розгорнувши локальний шар кешування на маршрутизаторах філій.
Ідея: агресивний кеш, менше upstream‑трафіку, швидші завантаження сторінок. Хтось зробив TTL‑параметр рекомендацією.
Раптом поширені SaaS‑домени кешувалися «достатньо довго».

Потім великий SaaS‑провайдер перемістив деякі ендпоїнти під час власного інциденту. Підприємство продовжувало відповідати застарілими
A/AAAA записами. Користувачі бачили періодичні відмови в залежності від філії. Логи резольвера виглядали чистими.
Захоплення пакетів теж. Все було «вірно», окрім реальності.

Ситуація погіршилася з DoH: браузери, прив’язані до публічного DoH‑резольвера, отримували свіжі відповіді, а керовані пристрої,
що використовували кеш філії, — застарілі. Дві реальності, одна компанія. Кожна нитка дебагу починалася з «У мене працює».
Цю фразу варто вважати небезпечною.

Виправлення було нудним: поважати TTL, тримати розумні розміри кешу і перестати випереджати авторитетних операторів.
Додайте моніторинг резольвера на неприродно високі співвідношення cache hit для швидкозмінних доменів.
Продуктивність важлива, але коректність — це функція.

Міні‑історія 3: Сумна, але правильна практика, що врятувала день

Фінансова організація мала правило: кожна зміна DNS мусила проходити через тест‑резольверну пару, з канарі‑групою клієнтів
і попередньо затвердженим шляхом відкату. Ніхто цього не любив. Здавалося б, паперова тяганина для пакетів.

Вони впровадили DoT для керованих кінцевих точок, завершуючи на своїх внутрішніх резольверах, і залишили простий DNS як відкат для старих пристроїв.
Під час rollout‑у upstream‑проблема з’єднання спричинила періодичні TLS‑збій‑хендшейків з одного дата‑центру до DoT‑слухачів.
Канарі‑група побачила це першою — малий радіус ураження, гучні тривоги.

Оскільки у них була інструментація щодо затримки резольвера, частоти помилок TLS‑хендшейків і розподілу клієнтів по сайтах,
вони швидко локалізували проблему до конкретного оновлення політики фаєрвола, що впливало на довго живі TLS‑сесії.
Вони відкатили ту конкретну політику, а не весь rollout DoT. Користувачі майже не помітили.

Нічого героїчного не трапилось. Саме тому це спрацювало. Коли ви робите зміни DNS нудними, ви можете спати спокійно.

Практичні завдання: команди, виводи та рішення, які ви ухвалюєте

Найшвидший спосіб припинити суперечки про DoH/DoT — зібрати докази. Нижче наведено польові завдання, які можна виконати на Linux‑хостах
(або в контейнерах для налагодження) та що робити з результатами. Підлаштуйте імена хостів і IP під ваше середовище.

Завдання 1: Підтвердити, яким саме резольвером користується хост

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53 10.20.0.54
        DNS Domain: corp.example

Значення: Системний резольвер вказує на 10.20.0.53/10.20.0.54. Якщо користувачі стверджують «DoH зламав DNS», але ОС вказує на корпоративні резольвери, обхід, ймовірно, відбувається в додатку (браузер) або VPN‑клієнті.

Рішення: Якщо DNS‑сервера публічні або несподівані — спочатку виправте призначення DNS через DHCP/VPN. Якщо вони вірні — досліджуйте обхід на рівні додатків (DoH).

Завдання 2: Спостерігати живий DNS‑трафік, щоб зрозуміти, чи використовується UDP/53

cr0x@server:~$ sudo tcpdump -ni any '(udp port 53 or tcp port 53 or tcp port 853)' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
12:01:11.120345 eth0  Out IP 10.20.10.15.38422 > 10.20.0.53.53: 1234+ A? intranet.corp.example. (38)
12:01:11.121004 eth0  In  IP 10.20.0.53.53 > 10.20.10.15.38422: 1234* 1/0/0 A 10.50.1.20 (54)
10 packets captured

Значення: Відбувається простий (plain) DNS. Якщо ви не бачите нічого на 53/853, а запити відбуваються, ймовірно в справі DoH (443).

Рішення: Якщо потрібно примусити корпоративний DNS — переходьте до політик на кінцевих точках/браузерах або впроваджуйте мережеве виявлення патернів DoH.

Завдання 3: Перевірити резолюцію явно через корпоративний резольвер

cr0x@server:~$ dig @10.20.0.53 intranet.corp.example A +noall +answer
intranet.corp.example. 60 IN A 10.50.1.20

Значення: Корпоративний резольвер може резолвити внутрішнє ім’я. Якщо користувачі не можуть — проблема на шляху клієнта, а не у серверних даних.

Рішення: Якщо це працює, а додатки користувача — ні, перевіряйте split‑DNS налаштування, обхід DoH або відмінності в search domain.

Завдання 4: Порівняти з публічним резольвером, щоб виявити витік split‑horizon

cr0x@server:~$ dig @1.1.1.1 intranet.corp.example A +noall +comments +answer
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22110

Значення: Публічний резольвер не знає внутрішнього імені. Якщо кінцеві точки використовують публічний DoH, внутрішні імена не працюватимуть.

Рішення: Надайте корпоративний DoH/DoT для керованих клієнтів; блокуйте або обмежуйте публічний шифрований DNS там, де політика це вимагає.

Завдання 5: Перевірити, чи systemd‑resolved налаштований для DoT

cr0x@server:~$ grep -R 'DNSOverTLS\|DNSSEC\|DNS=' /etc/systemd/resolved.conf /etc/systemd/resolved.conf.d 2>/dev/null
/etc/systemd/resolved.conf:DNS=10.20.0.53 10.20.0.54
/etc/systemd/resolved.conf:DNSOverTLS=opportunistic
/etc/systemd/resolved.conf:DNSSEC=allow-downgrade

Значення: Opportunistic DoT означає, що він намагатиметься використовувати DoT, але впаде назад. Це безпечніше для сумісності, слабкіше для «обов’язкового шифрування».

Рішення: Для корпоративних керованих мереж віддавайте перевагу «strict» лише коли ваші резольвери стабільно доступні і моніторяться.

Завдання 6: Перевірити DoT‑з’єднання до вашого резольвера

cr0x@server:~$ openssl s_client -connect dns.corp.example:853 -servername dns.corp.example -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = dns.corp.example
Verification: OK

Значення: TLS‑хендшейк пройшов, сертифікат верифіковано. Якщо ні — DoT‑клієнти впадуть назад (opportunistic) або зламаються (strict).

Рішення: Якщо верифікація не проходить — виправте сертифікати/SAN/ланцюжок. Якщо з’єднання не встановлюється — перевірте фаєрвол/NAT/MTU.

Завдання 7: Підтвердити, що резольвер слухає на 853 та/або 443

cr0x@server:~$ sudo ss -lntp | egrep '(:53|:853|:443)\s'
LISTEN 0      4096      0.0.0.0:53        0.0.0.0:*    users:(("unbound",pid=1442,fd=6))
LISTEN 0      4096      0.0.0.0:853       0.0.0.0:*    users:(("unbound",pid=1442,fd=8))
LISTEN 0      4096      0.0.0.0:443       0.0.0.0:*    users:(("caddy",pid=1310,fd=5))

Значення: Unbound на 53/853 і веб‑сервер на 443 (часто використовується як DoH‑фронтенд). Якщо 853 не слухає — DoT не працюватиме.

Рішення: Переконайтеся, що слухачі відповідають плану rollout; не оголошуйте «DoT доступний», якщо це не так.

Завдання 8: Виміряти затримку резольвера та виявити симптоми втрати пакетів

cr0x@server:~$ dig @10.20.0.53 www.example.com A +stats +tries=1 +timeout=1
;; Query time: 8 msec
;; SERVER: 10.20.0.53#53(10.20.0.53) (UDP)
;; WHEN: Tue Dec 31 12:05:22 UTC 2025
;; MSG SIZE  rcvd: 56

Значення: 8ms — здорово для сусіднього резольвера. Якщо ви бачите таймаути або стрибки 800ms+, у вас проблеми з мережею, перевантаження або повільний upstream.

Рішення: Якщо піки затримки корелюють з rollout DoT/DoH, перевірте наклад TLS‑хендшейків, повторне використання з’єднань і пропускну здатність таблиці стану фаєрвола.

Завдання 9: Подивитися, чи клієнти використовують публічні DoH‑ендпоїнти (перспектива Linux‑хоста)

cr0x@server:~$ sudo ss -tnp | awk '$4 ~ /:443$/ {print $5}' | head
34.120.54.55:443
104.16.249.249:443
1.1.1.1:443

Значення: З’являються з’єднання до IP з відомих CDN‑діапазонів і відомих резольверів. Це не доказ DoH (443 — це все), але це зачіпка.

Рішення: Якщо ви бачите повторювані довго живі з’єднання до відомих DoH‑провайдерів під час проблем з DNS, перевірте налаштування secure DNS у браузерах і політики підприємства.

Завдання 10: Перевірити поведінку локального stub‑резольвера і кешування

cr0x@server:~$ resolvectl statistics
Transactions: 18234
Cache Hits:  12011
Cache Misses: 6223
DNSSEC Verdicts: secure=0 insecure=0 bogus=0 indeterminate=0

Значення: Високі cache hits — нормальне явище. Нуль DNSSEC verdicts може свідчити, що stub не валідує або валідація вимкнена upstream.

Рішення: Вирішіть, де має відбуватися валідація DNSSEC (зазвичай на корпоративних рекурсивних резольверах). Переконайтеся, що вона увімкнена саме там, а не на кожному endpoint.

Завдання 11: Перевірити DNSSEC на корпоративному резольвері (з клієнта)

cr0x@server:~$ dig @10.20.0.53 dnssec-failed.org A +dnssec +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1512

Значення: Валідаційний резольвер має повертати SERVFAIL для свідомо зламаних DNSSEC зон.

Рішення: Якщо ви отримуєте нормальний A‑запис, ваш резольвер не валідує DNSSEC. Для багатьох підприємств це неприпустимо — вирішіть, чи треба змінювати.

Завдання 12: Виявити, чи проксі втручається в DoH (типово в корпоративних мережах)

cr0x@server:~$ curl -I --connect-timeout 3 https://dns.corp.example/dns-query
HTTP/2 405
server: caddy
date: Tue, 31 Dec 2025 12:07:11 GMT

Значення: Ви дісталися до DoH‑ендпоїнта. 405 може бути нормальним для невідповідності GET/HEAD залежно від реалізації; головне, що TLS+HTTP працюють енд‑ту‑енд.

Рішення: Якщо це таймаутить або повертає сторінку блокування проксі, виправте allowlist проксі або правила оминання для корпоративного DoH‑ендпоїнта.

Завдання 13: Перевірити політику egress‑фаєрвола для DoT

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain output {
    type filter hook output priority 0; policy accept;
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
    tcp dport { 53, 853, 443 } accept
  }
}

Значення: Forward‑лан дозволяє 853. Якщо 853 не дозволений від клієнтських VLAN до VIP резольверів, DoT не працюватиме.

Рішення: Дозволяйте 853 лише до ваших резольверів, а не в інтернет, якщо вам не подобаються сюрпризні обходи.

Завдання 14: На резольвері перевірити насичення (CPU, сокети, відкриті файли)

cr0x@server:~$ sudo pidstat -p $(pgrep -x unbound) 1 3
Linux 6.8.0 (dns01) 	12/31/2025 	_x86_64_	(8 CPU)

12:08:01 PM   UID       PID    %usr %system  %CPU  Command
12:08:02 PM  unbound   1442    38.00   6.00 44.00  unbound
12:08:03 PM  unbound   1442    41.00   7.00 48.00  unbound

Значення: Якщо ваш резольвер тримає 50% CPU постійно — ви ще в порядку, поки не вийдете з ладу. Раптові сплески під час rollout DoH можуть свідчити про наклад TLS‑термінації або флуд запитів.

Рішення: Масштабуйте горизонтально (більше інстансів резольвера), ввімкніть повторне використання з’єднань на DoH‑фронтендах і застосуйте rate‑limit на зловмисні клієнти, а не карайте всіх.

Завдання 15: Підтвердити, що логи показують очікувану підмережу/джерело (NAT ховає гріхи)

cr0x@server:~$ sudo tail -n 5 /var/log/unbound/unbound.log
[1735646910] unbound[1442:0] info: 10.20.10.15 www.example.com. A IN
[1735646911] unbound[1442:0] info: 10.20.10.15 intranet.corp.example. A IN
[1735646912] unbound[1442:0] info: 10.20.10.15 api.vendor.example. AAAA IN

Значення: Ви можете прив’язати запити до IP клієнтів. Якщо все йде від NAT‑шлюзу, ваша судово‑розшукова цінність падає.

Рішення: По можливості уникайте NAT між клієнтами та резольверами. Якщо неможливо — додавайте ідентифікатори клієнтів на DoH‑рівні (обережно) або використовуйте пер‑сайт резольвери.

Швидкий план діагностики

Коли DoH/DoT беруть участь, звична схема налагодження DNS не спрацьовує, бо ви більше не бачите запитів на UDP/53.
Цей план розрахований на чергового: знайдіть вузьке місце за хвилини, а не пишіть роман в інцидент‑каналі.

Перше: визначте, чи клієнт обходить корпоративний DNS

• Перевірте налаштування ОС‑резольвера (resolvectl status або еквівалент для ОС).
• Перевірте політику secure DNS у браузері (керований vs користувачем увімкнений).
• Пошукайте відсутність UDP/53 запитів, поки перегляд сайту «резолвиться» (ознака DoH).

Чому: Якщо клієнт не використовує ваш резольвер — все інше не має значення.

Друге: підтвердьте доступність і здоров’я TLS до корпоративного зашифрованого endpoint

• Для DoT: openssl s_client -connect ...:853 (верифікація сертифіката, час хендшейку).
• Для DoH: curl -I https://... (HTTP‑відповідь, втручання проксі).

Чому: Більшість корпоративних збоїв DoT не є «помилками DNS». Це проблеми TLS/сертифікатів/egress‑політик.

Третє: перевірте коректність резольвера та поведінку upstream

• dig @resolver internal.name та dig @resolver external.name
• Перевірте сплески SERVFAIL; протестуйте DNSSEC на відомо‑пошкодженому домені
• Перегляньте CPU резольвера та ліміти дескрипторів файлів

Чому: Якщо резольвер перевантажений або неправильно налаштований, шифрування лише ускладнює виявлення відмови.

Четверте: ізолюйте мережеві проблеми (MTU, таблиці стану, проксі)

• Проблеми MTU проявляються як TLS‑хендшейк‑збої або періодичні затримки.
• Виснаження стану фаєрвола проявляється як випадкові відмови в багатьох клієнтів.
• Таймаути проксі бачаться як відмови DoH лише в мережі.

Типові помилки (і як вони відмовляють у продакшні)

1) Симптом: Внутрішні імена не працюють тільки в браузерах; інструменти ОС працюють

Корінь: У браузері увімкнено DoH до публічного резольвера; ОС все ще використовує корпоративний DNS.

Виправлення: Примусіть політику браузера: «використовувати системний резольвер» або «використовувати корпоративний DoH‑ендпоїнт». Надайте корпоративний DoH, що працює off‑VPN і on‑VPN.

2) Симптом: Випадкові DNS‑збої після ввімкнення DoT у режимі «strict»

Корінь: Несумісність сертифіката (неправильний SAN), відсутній проміжний ланцюг або фаєрвол блокує 853 періодично.

Виправлення: Виправте PKI спочатку. Потім дозволяйте 853 лише до своїх резольверів. Додайте моніторинг успішності TLS‑хендшейків.

3) Симптом: Деякі сайти завантажуються повільно; затримка резольвера виглядає нормально

Корінь: DoH через проксі додає head‑of‑line блокування або хендшейк‑чорг; HTTP/2‑повторне використання не працює; проксі інспектує і затримує.

Виправлення: Обходьте проксі для корпоративного DoH‑ендпоїнта. Забезпечте keepalive і HTTP/2. Розгляньте DoT, якщо проксі неминучі.

4) Симптом: Команда безпеки вночі втрачає видимість DNS

Корінь: Клієнти мовчки переключилися на публічний DoH (оновлення браузера, опція ОС), обходячи корпоративні резольвери та логи.

Виправлення: Керування кінцевими точками: вимкніть публічний DoH, налаштуйте корпоративний DoH/DoT. Мережа: обмежте egress до відомих DoH‑ендпоїнтів як тимчасовий захід.

5) Симптом: Split‑horizon відповіді непослідовні між підмережами

Корінь: Багато стеків резольверів (кеші філій, центральні резольвери, публічний DoH) з різними правилами форвардингу і кешами.

Виправлення: Консолідуйте політику: один сервіс резольвера з консистентними поглядами; зберігайте філійні резольвери, але централізовано керуйте ними; припиніть «креативне» кешування.

6) Симптом: Високий рівень SERVFAIL тільки до зовнішніх доменів

Корінь: Помилки валідації DNSSEC через зламані upstream‑домени, неправильний час або блокування UDP‑фрагментів/ TCP‑fallback.

Виправлення: Дозвольте TCP/53 вихідний з резольверів. Перевірте NTP на резольверах. Використовуйте розумні налаштування DNSSEC; не вимикайте валідацію глобально через один поламаний домен.

7) Симптом: DoH працює поза мережею, але ламається в корпоративному LAN

Корінь: SSL‑інспекція або проксі блокують DoH‑ендпоїнт, або captive portal перехоплює 443 у деяких сегментах.

Виправлення: Додайте корпоративний DoH‑ендпоїнт до allowlist або налаштуйте обхід інспекції. Якщо ви мусите інспектувати — завершуйте коректно й зберігайте семантику, або прийміть, що ви порушуєте приватність.

8) Симптом: Навантаження CPU резольвера зросло після ввімкнення DoH

Корінь: Наклад TLS‑термінації перейшов на резольвер без планування потужностей; або DoH‑ендпоїнт не повторно використовує з’єднання і відкриває забагато сесій.

Виправлення: Виносьте TLS на виділений фронтенд з keepalive; масштабируйте пул резольверів; впровадьте rate‑limit і квоти для клієнтів.

Чеклісти / покроковий план

Крок 1: Визначте позицію підприємства (запишіть)

• Чи надаєте ви корпоративний зашифрований DNS‑сервіс? (варто.)
• Чи вимагаєте шифрування поза мережею? На мережі?
• Які логи ви зберігаєте і навіщо? Хто має до них доступ?
• Які внутрішні зони не повинні ніколи пропливати назовні?

Крок 2: Будуйте сервіс резольвера як залежність рівня‑0

• Резольвери з резервуванням по сайтах чи регіонах.
• Послідовні правила форвардингу і split‑horizon.
• Валідація DNSSEC на рекурсивних резольверах.
• RPZ/фіди загроз з контролем змін і відкатом.
• Тести ємності: QPS, TLS‑хендшейки, кількість з’єднань.

Крок 3: Додайте DoT і/або DoH‑ендпоїнти — усвідомлено

• DoT на 853 для керованих клієнтів, простіше для розуміння.
• DoH на 443 для ворожих мереж і середовищ з проксі, але зробіть його першим сервісом (моніторте).
• Сертифікати від довіреного внутрішнього/публічного CA; вказати коректні SAN.
• Зробіть ендпоїнти доступними з VPN і з інтернету, якщо віддалені працівники потребують цього (з урахуванням DDoS).

Крок 4: Примусьте політику на кінцевих точках

• На рівні ОС: вкажіть корпоративні резольвери.
• На рівні браузера: примусіть «secure DNS» до корпоративного endpoint або системного резольвера.
• Запобігайте переопределенню користувачем, якщо ваша модель ризику це потребує (регульовані середовища).

Крок 5: Мережеві контроли (використовуйте помірно, але будьте готові)

• Дозволяйте DoT (853) лише до корпоративних резольверів; блокуйте в інтернет, якщо політика вимагає.
• Для DoH віддавайте перевагу контролю на кінцевих точках; використовуйте мережеве виявлення як підстраховку.
• Документуйте винятки (гостьовий Wi‑Fi, BYOD, лабораторії).

Крок 6: Моніторинг, що вловлює реальні збої

• Резольвер: QPS, затримка, SERVFAIL/NXDOMAIN‑рівні, співвідношення cache hit, RTT upstream.
• DoT: частота помилок TLS‑хендшейків, кількість сесій, оповіщення про закінчення сертифікатів.
• DoH: розподіл HTTP‑статусів, p95 затримка, коди помилок проксі, метрики повторного використання з’єднань.
• Досвід клієнта: синтетичні запити для внутрішніх і зовнішніх імен з кожного сайту.

Крок 7: План rollout‑у з урахуванням blast radius

• Канарі‑група (IT + кілька просунутих користувачів).
• Поступове розширення по сайтах/регіонах.
• Відкат: чіткі кроки для скасування політик endpoint і маршрутизації.
• Рунбук інциденту: включіть «чи клієнт обходить резольвер?» як першу перевірку.

Поширені запитання

1) Чи повинні підприємства дозволяти DoH взагалі?

Так, але не як «хай кожен використовує будь‑який резольвер, який подобається браузеру». Надайте корпоративний DoH‑ендпоїнт і керуйте клієнтами, щоб ним користуватися.
Якщо ви не можете керувати клієнтами, можливо, доведеться обмежити публічний DoH, щоб зберегти split‑horizon та контролі безпеки.

2) Чи DoT простіший ніж DoH для корпоративних мереж?

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

3) Чи шифрований DNS зупинить шкідливе ПЗ?

Ні. Він захищає від пасивних спостерігачів, що читають DNS‑трафік. Шкідливе ПЗ все ще може резолвити домени — можливо надійніше.
Ваше пом’якшення — політика на резольвері (коли клієнти його використовують), захист кінцевих точок і контроли виходу в інтернет.

4) Якщо ми робимо DNSSEC, чи потрібні DoH/DoT?

DNSSEC і DoH/DoT вирішують різні проблеми. DNSSEC автентифікує відповіді; DoH/DoT приховують питання й відповіді від спостерігачів.
Потрібна валідація DNSSEC на ваших резольверах незалежно від шифрування.

5) Чи можна блокувати публічний DoH по SNI?

Іноді — сьогодні. Менш надійно завтра через ECH і CDN‑фронтинг. Розглядайте блокування SNI як тимчасовий захід, а не довгострокову стратегію.

6) Хіба DoH не порушує наші DNS‑логи?

Він порушує логування на шляху (on‑path), на яке не варто покладатися. Він не порушує логування резольвера, якщо клієнти використовують ваш резольвер.
Перенесіть видимість на рівень резольвера і тримайте періоди зберігання логів відповідними політикам безпеки/операцій.

7) А гості у Wi‑Fi і BYOD?

Визначте, на що ви оптимізуєте. Якщо гості не повинні мати доступ до внутрішніх ресурсів, їх можна допустити до публічного DNS/DoH.
Якщо їм потрібен доступ до внутрішніх ресурсів — розгляньте їх як керованих або примусіть через контроль доступу (NAC/VDI/VPN).

8) Як запобігти витоку внутрішніх доменів через публічні резольвери?

Надійна відповідь — налаштування кінцевих точок: забезпечте, щоб внутрішні суфікси резолвилися через корпоративні резольвери, і налаштуйте DoH/DoT на ваші ендпоїнти.
Мережеве блокування допомагає, але ніколи не буде досконалим, якщо клієнти можуть тунелювати через 443.

9) Чи ризиковано мати свій DoH‑ендпоїнт?

Це продакшн‑сервіс, отже так. Але це також точка контролю, на якій ви вже покладаєтесь (DNS). Якщо ви його не запустите,
хтось інший зробить це на користь ваших кінцевих точок — без вашого split‑horizon і без можливостей реагування на інциденти.

10) Який «найменш поганий» дефолт для змішаного середовища?

Корпоративні рекурсивні резольвери з валідацією DNSSEC, форвардингом внутрішніх зон і DoT в режимі «opportunistic» для керованих кінцевих точок,
плюс корпоративний DoH‑ендпоїнт для браузерів і ворожих мереж. Потім звужуйте до «strict», де моніторинг доводить безпечність.

Висновок: наступні кроки, які вас не підведуть

DoH і DoT — це не просто перемикачі приватності. Вони переміщують вашу DNS‑контрольну площину з мережі на кінцеві точки і резольвер.
Якщо ви не надасте корпоративний зашифрований DNS‑сервіс, ваші користувачі приймуть його випадково — через оновлення браузера,
перемикач ОС або ентузіастичний блог‑пост — і ви будете відлагоджувати це о 2‑й ранку з половиною телеметрії відсутньою.

Практичні наступні кроки:

1. Інвентар: визначте, де DNS зараз резолвиться (ОС, браузери, VPN‑клієнти, кеші філій).
2. Побудова: розгорніть резервні корпоративні рекурсивні резольвери з валідацією DNSSEC і консистентними split‑horizon правилами.
3. Шифрування: додайте DoT і/або DoH‑ендпоїнти з реальним моніторингом (частота хендшейків, затримка, коди помилок).
4. Контроль: примусіть політики на кінцевих точках і в браузерах використовувати корпоративний зашифрований DNS, а не публічні ендпоїнти.
5. Контейнмент: використовуйте мережеві блоки помірно для публічного DoT і цільових DoH‑ендпоїнтів, коли політика вимагає, але не прикидайтеся, що це назавжди.
6. Репетиція: відпрацьовуйте сценарії відмов — прострочений сертифікат, перевантаження резольвера, upstream‑відмова — щоб перший раз не стався в продуктиві.

Якщо зробити все правильно, користувачі отримають приватність у ворожих мережах, команди безпеки збережуть корисну DNS‑видимість,
а внутрішні додатки не впадуть. Мета — не «перемогти» шифрування. Мета — керувати мережею, де шифрування нормальне, а ваші контролі все ще працюють.