DoH/DoT: перемога приватності, що ламає роздільний (split-horizon) DNS (виправлення всередині)

Що насправді ламається: роздільний (split-horizon) DNS проти зашифрованого DNS

Роздільний DNS — це старий, нудний трюк, який працює, бо вибір резолвера клієнтом передбачуваний. Ви публікуєте різні відповіді
для одного й того самого імені залежно від того, звідки прийшов запит. Усередині мережі app.corp.example резолвиться на адресу RFC1918.
Ззовні — на публічну адресу або NXDOMAIN. Сам по собі це не «безпека», але це важливий механізм, на який спираються багато заходів безпеки
та маршрутизаційні конструкції.

Зашифрований DNS змінює стосунки з резолвером. З DoH/DoT DNS‑трафік загортається в TLS, і — що важливіше — клієнти можуть
обирати резолвери поза вашим контролем. Це означає:

• Ваші внутрішні зони можуть ніколи не бути опитані.
• Ваші умовні пересилки (conditional forwarders) можуть ніколи не виконатися.
• Ваші DNS‑засновані контроли доступу (allow/ban‑списки, sinkhole, телеметрія безпеки) можуть нічого не побачити.
• «Надіслати ці DNS‑сервери й ці пошукові домени» від VPN стає радше рекомендацією, ніж примусовою дією.

Поширене непорозуміння: «DoH/DoT — це лише шифрування; це не змінює DNS». На практиці змінюється те, хто відповідає. Ось де відбувається злам.
Перемога приватності й операційні втрати — це один і той самий випадок.

DoH проти DoT в операційних термінах

DoT зазвичай працює поверх TCP/853 до резолвера. Це виглядає як «DNS‑протокол з TLS». Його частіше налаштовують на рівні ОС
(відомий приклад — Android «Private DNS»). Його легше ідентифікувати по порту, але перехопити відповідально — не завжди просто.

DoH працює через HTTPS (TCP/443) і використовує форм‑фактор HTTP‑запит/відповідь. Це «DNS, замаскований під веб‑трафік» — і це не образа, а суть.
Він зливається з іншими запитами HTTPS, використовує інфраструктуру вебу й середні пристрої. Також DoH обходить багато мережевих контролів, бо виглядає як звичайний веб‑запит.

Зазвичай розрив роздільного DNS походить з однієї з таких причин:

1. DoH браузера замінює DNS ОС. Ваш системний резолвер вказує на DNS VPN, але браузер відправляє запити до публічного DoH‑ендпоінту.
2. DoT на рівні ОС налаштований на публічний резолвер. Кінцевий пристрій весь час «надійно неправий».
3. Гонка між двома резолверами. Клієнт пробує кілька резолверів; публічний виграє через меншу затримку й кешує невірну відповідь.
4. Каптивний портал / інтерцепт інфраструктури створює крайові випадки. Клієнт бачить помилки TLS, відкотиться, і тепер маєте недетерміновану поведінку.

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

Факти та історія для аргументів із командою безпеки та продукту

Це не дрібниці для вікторин. Це контекст, який дає змогу прийняти рішення під час рев’ю змін без годинних дебатів.

1. Проблеми приватності в DNS існували задовго до DoH/DoT. «DNS у відкритому тексті» завжди було правдою; змінилося те, що браузери та ОС почали діяти щодо цього.
2. DoT (RFC 7858) з’явився раніше за DoH (RFC 8484). Першою відповіддю індустрії був «TLS на DNS‑специфічному порту», а не «HTTP для всього».
3. Браузери популяризували вибір резолвера як продуктову опцію. Це перемістило вибір резолвера від операторів мереж до вендорів застосунків.
4. Роздільний DNS старший за більшість нинішніх VPN‑продуктів. Техніка передує брендингу «zero trust» на значний проміжок.
5. Корпоративний DNS — це не тільки ім’я → IP. Часто це площина розповсюдження для service discovery, записів SRV і внутрішніх потоків перевірки сертифікатів.
6. DNSSEC не шифрує. Він автентифікує відповіді, але не приховує запити і не запобігає спостереженню за іменами в каналі.
7. EDNS Client Subnet (ECS) погіршив приватність для деяких користувачів. Він може пролити інформацію про мережу клієнта авторитетним серверам заради покращення маршрутизації CDN.
8. Деякі платформи впровадили «опортуністичний» зашифрований DNS. Якщо резолвер підтримує його — використовується; якщо ні — мовчки відкочується. Це створює поведінку, залежну від середовища.
9. Резолвери різні. Різні рекурсивні резолвери мають різні політики кешування, фільтрації й негативного кешування. Ви можете бачити різні відповіді для одного й того самого імені.

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

Режими відмов: як це виглядає в продакшені

1) Внутрішні імена резолвляться в публічні IP (або взагалі не резолвляться)

Класичний розрив роздільного DNS: jira.corp.example резолвиться в щось публічне, або NXDOMAIN, бо публічний резолвер не знає вашої внутрішньої зони.
Ваш внутрішній DNS повернув би 10.30.4.17. Натомість ви отримуєте нічого — або, ще гірше, публічне CDN‑ім’я, якого ви не очікували.

Це сильніше вдаряє по користувачах VPN, бо вони очікують «внутрішні імена працюють, коли VPN увімкнено». Але якщо резолвер клієнта обходить VPN,
VPN — просто гарний роутер, який не знає, яке ім’я ви ввели.

2) SSO та перевірка сертифікатів ідуть боком

Внутрішні додатки часто покладаються на внутрішні CA, внутрішні OCSP‑відповідачі, внутрішні IdP і сервіси, чиї імена існують лише всередині.
Якщо кінцевий пристрій питає зовнішній резолвер і отримує NXDOMAIN, ви побачите:

• цикли перенаправлення SSO (ім’я IdP не резолвиться)
• «Не можна перевірити сертифікат» (OCSP/CRL‑ендпоінти недоступні)
• дивні часткові збої, коли додаток завантажується, але автентифікація падає

3) DNS‑засновані контроли безпеки втрачають видимість

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

4) «Ламається тільки на деяких ноутбуках» (найгірший тип зламу)

Різноманітність кінцевих пристроїв перетворює це на кошмар. У одного користувача Android Private DNS вказаний на публічний резолвер. Інший — користується браузером з ввімкненим DoH.
Хтось на керованій збірці, де ви відключили DoH, але їхній VPN‑клієнт має власний DNS‑стек. Ви отримуєте суміш поведінок, що виглядає як ненадійна мережа.

5) Kubernetes / service mesh додають другий рівень плутанини

У кластерах у вас уже є CoreDNS, stub‑домени і внутрішнє виявлення сервісів. Якщо вузли або поди починають використовувати зовнішній DoH/DoT, ви можете отримати
резолюцію, яка відрізняється між хостом і подом, або між подами на різних вузлах. Дебаг «DNS» стає дебагом трьох DNS‑стеків одночасно.

Швидкий план діагностики (перевірте 1/2/3)

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

Перевірка 1: Визначте, який резолвер насправді використовується

• На клієнті перевірте налаштовані DNS‑сервери (інтерфейс VPN проти Wi‑Fi).
• Перевірте, чи браузер або ОС використовують DoH/DoT до зовнішнього резолвера.
• Підтвердіть це запитом, що явно таргетує ваш внутрішній резолвер, і порівняйте відповіді.

Перевірка 2: Порівняйте відповіді внутрішнього та зовнішнього резолверів

• Запитайте внутрішній резолвер для імені, яке ламається.
• Запитайте відомий публічний резолвер для того ж імені.
• Якщо відповіді відрізняються — роздільний DNS працює, але клієнт обирає неправильний горизонт.

Перевірка 3: Підтвердіть шлях і політику

• Якщо клієнт правильно використовує внутрішній DNS, перевірте пересилки, views і ACL на резолвері.
• Перевірте правила файрвола: чи дозволено клієнту досягати внутрішнього DNS по 53/udp та 53/tcp?
• Перевірте перехоплення DNS у гостьових мережах або «захисних» приладах, які переписують DNS.

Лише після цих трьох перевірок починайте копати в кешах, негативних TTL, поведінці EDNS та інших цікавинках.

Практичні завдання: команди, виводи та рішення

Це ті завдання, які я реально виконую під час інцидентів. Кожне має: команду, приклад виводу, що це означає та яке рішення вона підштовхує.
Підлаштуйте імена хостів і IP під ваше середовище.

Завдання 1: Побачити, які DNS‑сервери вважатиме systemd-resolved (Linux)

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 1.1.1.1
        DNS Domain: corp.example

Link 2 (wg0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.20.0.53
       DNS Servers: 10.20.0.53
        DNS Domain: corp.example

Значення: У вас налаштований і внутрішній резолвер (10.20.0.53), і публічний (1.1.1.1).
Навіть якщо wg0 виглядає правильно, деякі резолвери будуть конкурувати або відкотяться.

Рішення: Видаліть публічні резолвери з керованих клієнтів, коли потрібен роздільний DNS, або примусьте маршрут за доменом через локальний stub‑резолвер.

Завдання 2: Перевірити, чи systemd-resolved використовує DNS‑over‑TLS

cr0x@server:~$ resolvectl dnsovertls
Global setting: no
Link 2 (wg0): no
Link 3 (wlp0s20f3): no

Значення: Тут DoT не ввімкнено. Якщо ви все ще бачите розриви роздільного DNS, шукайте DoH у браузері або сторонній агент.

Рішення: Зосередьтеся на налаштуваннях браузера, ПЗ для безпеки кінцевих пристроїв або на функціях Private DNS Android/iOS.

Завдання 3: Порівняти відповіді від внутрішнього та публічного резолверів (dig)

cr0x@server:~$ dig +short jira.corp.example @10.20.0.53
10.30.4.17

cr0x@server:~$ dig +short jira.corp.example @1.1.1.1

Значення: Внутрішній резолвер повертає приватний IP; публічний нічого не повертає (NXDOMAIN або порожньо через політику).

Рішення: Це не інцидент «додаток впав». Це проблема вибору резолвера. Виправляйте маршрутизацію резолвера на клієнті, а не додаток.

Завдання 4: Підтвердити, чи браузер робить DoH через спостереження з’єднань (Linux)

cr0x@server:~$ sudo ss -tpn | grep -E ':443' | head
ESTAB 0 0 192.168.1.50:52114 104.16.248.249:443 users:(("firefox",pid=2148,fd=91))
ESTAB 0 0 192.168.1.50:52122 8.8.8.8:443 users:(("firefox",pid=2148,fd=93))

Значення: Браузер спілкується з публічними IP на 443. Це нормально для вебу. Питання в тому, чи будь‑хто з них — DoH‑ендпоінт.
Якщо підозрюєте DoH до конкретного провайдера, зіставте з відомими IP ендпоінтів з вашого allowlist/розвідки або інспектуйте SNI/HTTP‑шляхи в контрольованому середовищі.

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

Завдання 5: Підтвердити, що DNS‑запити потрапляють на ваш резолвер (tcpdump на резолвері)

cr0x@server:~$ sudo tcpdump -ni eth0 port 53 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:41:11.225318 IP 10.20.14.22.52433 > 10.20.0.53.53: 12345+ A? jira.corp.example. (35)
12:41:11.225902 IP 10.20.0.53.53 > 10.20.14.22.52433: 12345* 1/0/0 A 10.30.4.17 (51)

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

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

Завдання 6: Перевірити DoT‑трафік (TCP/853), що виходить з підмережі клієнтів (файрвол або хост)

cr0x@server:~$ sudo tcpdump -ni eth0 tcp port 853 -c 3
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:42:09.114220 IP 10.20.14.22.48932 > 9.9.9.9.853: Flags [S], seq 366451, win 64240, options [mss 1460,sackOK,TS val 248490 ecr 0,nop,wscale 7], length 0

Значення: Той клієнт намагається зробити DoT до публічного резолвера. Якщо ваш роздільний DNS залежить від внутрішнього DNS, це пряма причина.

Рішення: Заблокуйте вихідний трафік на 853 з корпоративних мереж (з винятками для ваших власних DoT‑сервісів) і примусьте політику на кінцевих пристроях.

Завдання 7: Перевірити вибір DNS‑серверів у Windows (PowerShell)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"
InterfaceAlias ServerAddresses
-------------- --------------
Wi-Fi          {192.168.1.1}
CorpVPN        {10.20.0.53, 10.20.0.54}

Значення: Wi‑Fi має свій DNS (часто домашній роутер), а VPN — внутрішній DNS. Windows зазвичай віддає перевагу інтерфейсу VPN для DNS, коли налаштовано правильно,
але мають значення метрики інтерфейсів і NRPT‑правила.

Рішення: Підтвердіть метрики інтерфейсів і додайте правила резолюції імен, щоб corp.example завжди використовував резолвер VPN.

Завдання 8: Перевірити таблицю політик імен Windows (NRPT)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-DnsClientNrptRule | Select-Object Namespace,NameServers,DirectAccess | Format-List"
Namespace    : .corp.example
NameServers  : {10.20.0.53, 10.20.0.54}
DirectAccess : False

Значення: Запити для *.corp.example мають йти до внутрішніх резолверів незалежно від загальної DNS‑конфігурації.

Рішення: Якщо відсутні, додайте NRPT (через GPO/MDM). Це один з найчистіших способів зберегти роздільний DNS у Windows‑парку.

Завдання 9: Підтвердити resolver domains і порядок у macOS

cr0x@server:~$ scutil --dns | sed -n '1,80p'
DNS configuration

resolver #1
  search domain[0] : corp.example
  nameserver[0] : 10.20.0.53
  nameserver[1] : 10.20.0.54
  if_index : 12 (utun3)
  flags    : Request A records
  reach    : 0x00000002 (Reachable)

resolver #2
  nameserver[0] : 192.168.1.1
  if_index : 6 (en0)
  reach    : 0x00000002 (Reachable)

Значення: Резолвер VPN прив’язаний до corp.example. Це добре. Якщо користувачі все одно падають — підозрюйте DoH на рівні застосунку або резолвер, що не підтримує scoped domains.

Рішення: Тримайте scoped резолвери; просуньте керований DoH‑профіль, якщо потрібно зашифрований DNS без втрати роздільного DNS.

Завдання 10: Перевірити, чи внутрішній резолвер може рекурсувати й форвардити правильно

cr0x@server:~$ dig +nocmd +noall +answer www.example.net @10.20.0.53
www.example.net.  300  IN  A  93.184.216.34

Значення: Внутрішній резолвер може дістатися апстрімів і відповісти на інтернет‑імена. Якщо не може — клієнти можуть «допомогти» і перемикнутися на публічні резолвери.

Рішення: Виправте egress і латентність внутрішнього резолвера. Якщо внутрішній DNS повільний або ненадійний, прийняття DoH лише множить ризики.

Завдання 11: Перевірити логіку views/ACL у BIND (named-checkconf)

cr0x@server:~$ sudo named-checkconf -z /etc/bind/named.conf
zone corp.example/IN: loaded serial 2026020401
zone 0.20.10.in-addr.arpa/IN: loaded serial 2026020401
zone example.com/IN: loaded serial 2026011502

Значення: Конфіг розбирається і зони завантажуються. Це не доводить, що правильний view відповідає клієнту, але усуває «хибну конфігурацію» як негайну причину.

Рішення: Якщо зони завантажуються, а клієнти отримують неправильні відповіді — перевірте відповідність view по IP‑джерелу і тестуйте з кількох підмереж.

Завдання 12: Перевірити Unbound forwarding і local-zone поведінку

cr0x@server:~$ sudo unbound-control status
version: 1.17.1
verbosity: 1
threads: 4
modules: 2 [ validator iterator ]
uptime: 86400 seconds
options: control(yes)

cr0x@server:~$ sudo unbound-control list_local_zones | grep corp.example
corp.example. transparent

Значення: Unbound працює і має local‑zone для внутрішнього домену. «transparent» означає, що він використовуватиме local‑data, якщо є, інакше рекурсуватиме/форвардитиме.

Рішення: Якщо потрібна сувора внутрішня поведінка, віддайте перевагу «static» або використовуйте явні local‑data і блокуйте витік на публічний рекурс.

Завдання 13: Виявити, чи негативне кешування вам шкодить (dig +trace та SOA TTL)

cr0x@server:~$ dig jira.corp.example @1.1.1.1 +noall +authority
corp.example.  900  IN  SOA  ns1.public-dns.example. hostmaster.public-dns.example. 1 7200 900 1209600 900

Значення: Якщо публічний резолвер повертає SOA в секції authority для NXDOMAIN, TTL негативного кеша може спричинити «воно продовжує падати навіть після виправлення».

Рішення: Очистіть кеші на клієнті/резолверах де можливо, і зменшіть негативні TTL на зонах, якими ви керуєте.

Завдання 14: Виявити клієнтів, які обходять DNS, перевіривши логи резолвера (приклад: BIND querylog)

cr0x@server:~$ sudo tail -n 3 /var/log/named/query.log
04-Feb-2026 12:44:11.112 client @0x7f0a3c: query: jira.corp.example IN A +E(0)K (10.20.14.22)
04-Feb-2026 12:44:11.114 client @0x7f0a3c: query: ocsp.corp.example IN A +E(0)K (10.20.14.22)
04-Feb-2026 12:44:11.116 client @0x7f0a3c: query: idp.corp.example IN A +E(0)K (10.20.14.22)

Значення: Ви можете підтвердити, які клієнти реально запитують внутрішній DNS. Якщо користувач відтворює помилку і ви не бачите відповідних рядків у логах,
їхній пристрій не питає вас. Це ключовий факт для політичної розмови.

Рішення: Розглядайте обхід як питання відповідності керованих кінцевих пристроїв, а не як «налаштування DNS‑сервера».

Виправлення: зберегти приватність і роздільний DNS

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

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

Шаблон A: Запустіть власні зашифровані DNS‑ендпоінти (рекомендовано)

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

Потім налаштуйте кінцеві пристрої (через MDM/GPO) використовувати ваш зашифрований DNS, а не випадковий публічний.
Для роздільного DNS ваш резолвер має мати ту ж логіку views, що й існуючий внутрішній DNS, або форвардити внутрішні зони в потрібне місце.

Операційна деталь, що має значення: потрібне планування потужностей і моніторинг затримок. Якщо ваш зашифрований DNS повільніший за публічні резолвери,
клієнти й додатки «допомогливо» переключаться. Це не злоба; це досвід користувача.

Шаблон B: Примусова маршрутизація за доменом (NRPT / scoped resolvers / split DNS)

Якщо не можна повністю централізувати вибір резолвера, принаймні примусьте маршрутизацію для внутрішніх доменів:
*.corp.example, *.svc.cluster.local та інші внутрішні простори імен повинні йти до внутрішніх резолверів.
Це мінімальний захисний поручень для роздільного DNS.

• Windows: NRPT‑правила — ваш друг. Вони нудні, але саме тому працюють.
• macOS: scoped resolvers через VPN‑профілі; перевіряйте scutil --dns.
• Linux: systemd‑resolved підтримує per‑link domains; NetworkManager може проштовхувати це через VPN.

Шаблон C: Блокуйте те, що потрібно, але не прикидайтеся, що це «вирішено»

Блокування вихідних TCP/853 знижує обхід через DoT. Блокувати DoH складніше, бо він їде через HTTPS.
Ви можете блокувати відомі DoH‑ендпоінти, але списки клієнтів змінюються, і CDN‑и рухаються.

Якщо вирішите блокувати DoH у мережі, робіть це усвідомлено:

• Ви будете грати у whack‑a‑mole, якщо не використовуєте управління кінцевими пристроями також.
• Ви можете пошкодити легітимні HTTPS‑сервіси, якщо будете надто широкі.
• Деякі клієнти повернуться до незашифрованого DNS. Це може бути прийнятно або неприйнятно залежно від політики.

Шаблон D: Припиніть використовувати внутрішні імена, що конфліктують з публічним DNS

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

Використовуйте піддомен, яким керуєте публічно (наприклад corp.example) для внутрішнього використання. Уникайте «шорткатних» внутрішніх TLD і не покладайтесь
на пошукові суфікси для критичних систем. Якщо треба зберегти старі імена — вважайте це технічним боргом і плануйте міграцію.

Шаблон E: Зробіть внутрішній DNS настільки надійним, щоб користувачі не шукали альтернатив

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

Основи надійності:

• Резервні резолвери в кожному великому сайті/регіоні.
• Чітка політика форвардингу для внутрішніх зон і для інтернет‑рекурсії.
• Моніторинг: латентність, рівень SERVFAIL, NXDOMAIN, топ‑QNAMEів, стан апстрімів.
• Суворий контроль змін для делегацій зон і записів роздільного DNS.

Один цитат, бо вона досі актуальна в DNS‑світі. Вернер Фогельс (ідея переказана): «Все ламається постійно; проєктуйте так, щоб системи продовжували працювати у будь‑якій ситуації».

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

Три корпоративні міні‑історії з польових боїв

Міні‑історія 1: Інцидент через хибне припущення

Середня компанія розгорнула новий VPN‑клієнт з «secure DNS» в маркетингових матеріалах. Команда мережі припустила, що це означає «він використовує наші DNS‑сервери,
але зашифровано». Вони швидко погодили це, бо втомилися від дискусій про відкритий DNS і хотіли перемогу.

Через два тижні розробники почали повідомляти про періодичні проблеми з Git over HTTPS і помилки сертифікатів.
Ім’я іноді резолвилося на внутрішній IP, іноді — на публічний IP зовсім іншого сервісу з подібною назвою.
Браузер показував невідповідність сертифіката, користувачі іноді натискали «продовжити» (бо, звісно, так вони робили), і тепер у вас інцидент плюс погані звички.

Корінь проблеми не був у TLS. Не був у Git‑сервісі. Він був у виборі резолвера. Функція «secure DNS» VPN‑клієнта за замовчуванням вмикала DoH до стороннього резолвера.
Коли VPN був увімкнений, внутрішній DNS працював для деяких додатків. Але браузери з DoH отримували стабільні відповіді від неправильного резолвера, і збої виглядали випадковими,
бо різні додатки використовували різні стеки.

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

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

Інша організація намагалася покращити продуктивність для віддалених працівників, проштовхнувши публічний резолвер як вторинний DNS‑сервер.
Внутрішній резолвер був доступний через VPN, але в деяких регіонах мав високу затримку. Ідея була: «якщо внутрішній повільний, публічний буде швидким, і лише внутрішні імена потребують внутрішнього DNS».
У цьому реченні містилося зерно майбутнього інциденту.

Першою ознакою проблеми був сплеск звернень до служби підтримки: «Деякі внутрішні інструменти не працюють, але тільки для віддалених людей».
Інженери швидко перевірили і побачили, що внутрішні резолвери в порядку. Додатки працювали. VPN був увімкнений. Але резолюція імен була непослідовною.
Деякі клієнти резолвили api.corp.example на внутрішній IP, інші отримували NXDOMAIN.

Відкат прийшов від гонки резолверів і кешування. Деякі клієнти запитували обидва резолвери; публічний відповідав швидше з NXDOMAIN,
який кешувався. Пізніше, навіть коли внутрішній резолвер міг би відповісти правильно, клієнт уже не питав — він довіряв негативному кешу.
Оптимізація продуктивності обернулася помилкою правильності.

Виправлення — видалити публічні резолвери з конфігурації VPN і натомість розгорнути регіональні внутрішні резолвери (або форвардери) ближче до користувачів.
Також переглянули TTL для негативного кешування там, де мали контроль. Нова практика: ніколи не додавати «резервний резолвер», який не може відповідати на ваші внутрішні зони.
Це не резерв, це роздвоєння реальності.

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

Велике підприємство вже стандартизувалося на виділеному внутрішньому простору імен (corp.example) і документувало правила умовного форвардингу
між їхнім on‑prem DNS і приватними зонами в хмарі. Вони також мали політики для кінцевих пристроїв, які відключали DoH, керований браузером, якщо він не вказував на корпоративний DoH‑сервіс.
Це було нудно. Але ефективно.

Під час великого інтернет‑інциденту, що торкнувся мережі популярного публічного резолвера, вони мали менше проблем, ніж колеги.
Їхні корпоративні пристрої не залежали від зовнішнього DNS для внутрішніх імен, а внутрішні резолвери мали резервні апстріми для інтернет‑рекурсії.
Внутрішні додатки залишалися доступними. Користувачі VPN продовжували працювати. Служба підтримки мала тихий день — найближче до трофея для опсів.

Критичний момент: хтось запропонував «просто скажіть людям тимчасово використовувати цей публічний DNS».
Команда DNS відмовила — не з упертості, а тому, що вже бачила наслідки цього фільму.
Натомість вони збільшили потужність внутрішніх резолверів і тимчасово посилили правила egress, що дозволяли неврегульований DoT.

Постмортем був коротким і майже нудним: нудна практика (стабільні простори імен, документовані форвардинги, політика кінцевих пристроїв) зменшила радіус ураження.
Не все потребує інновацій. Іноді потрібно просто політика, що переживе реальність.

Поширені помилки: симптом → корінь проблеми → виправлення

1) Симптом: «VPN підключено, але внутрішні домени не резолвляться»

Корінь: DoH браузера або Private DNS ОС обходить резолвер, наданий VPN.

Виправлення: Застосувати політику на кінцевих пристроях: відключити сторонні DoH/DoT або вказати корпоративний зашифрований DNS; додати правила за доменом для corp.example.

2) Симптом: «Пінг працює, а в браузері — ні»

Корінь: Різні стекі резолвера. CLI‑інструменти використовують DNS ОС; браузер — DoH.

Виправлення: Узгодьте політику резолвера. В керованому середовищі централізовано налаштуйте DoH у браузерах. В некерованому — публікуйте інструкції і робіть внутрішні додатки доступними через публічний DNS + автентифікацію, якщо це доречно.

3) Симптом: «Після зміни деякі користувачі отримують NXDOMAIN для внутрішніх імен»

Корінь: Негативне кешування від публічного резолвера або внутрішнього форвардера з довгим TTL при NXDOMAIN.

Виправлення: Очистіть кеші там, де можливо; зменшіть негативні TTL у зонах, якими ви керуєте; припиніть пересилати внутрішні імена до резолверів, що не можуть на них відповісти.

4) Симптом: «У логах DNS немає нічого під час тестів користувача»

Корінь: Обхід через DoH/DoT, жорстко задані резолвери або локальний агент.

Виправлення: Виявте обхід: блокуйте вихідний 853 там, де політика дозволяє; застосуйте налаштування DoH; використовуйте перевірки відповідності кінцевих пристроїв для виявлення неконформних налаштувань.

5) Симптом: «Внутрішні імена іноді резолвляться в публічні IP»

Корінь: Роздільний DNS існує, але клієнт періодично використовує неправильний горизонт (multi‑homed DNS, гонка).

Виправлення: Усуньте публічні резолвери з корпоративних конфігурацій; використовуйте scoped domains/NRPT; забезпечте низьку затримку і високу доступність внутрішніх резолверів.

6) Симптом: «Команда безпеки бачить падіння телеметрії DNS»

Корінь: DoH до сторонніх резолверів; DNS‑фільтрація відходить від вашого шляху.

Виправлення: Надати корпоративний DoH/DoT з логуванням і політикою; примусити використання резолверів через MDM/GPO; розглянути контролі на рівні застосунку, що не залежать від видимості DNS.

7) Симптом: «Поди Kubernetes не можуть резолвити внутрішні зони, але вузли можуть»

Корінь: Налаштування DNS у подах або node‑local кеші форвардить на зовнішні резолвери; відсутні stubDomains.

Виправлення: Налаштуйте CoreDNS stubDomains/forward для внутрішніх зон; переконайтеся, що node‑резолвери не використовують публічний DoH/DoT для внутрішніх просторів імен.

Контрольні списки / покроковий план

Покроково: стабілізувати роздільний DNS під тиском DoH/DoT

1. Інвентаризуйте внутрішні простори імен. Перелічіть внутрішні зони та критичні хости. Якщо ви не можете їх перелічити, ви не зможете їх захистити.
2. Визначте політику резолвера. Виберіть одне: «лише корпоративні резолвери» (кероване) або «лише примусова маршрутизація за доменом» (гібрид).
3. Розгорніть корпоративні зашифровані DNS‑ендпоінти. Запропонуйте DoH/DoT як підтримувану послугу з HA, моніторингом і контролем змін.
4. Налаштуйте кінцеві пристрої через MDM/GPO. Вимкніть сторонні DoH/DoT; вкажіть корпоративні резолвери; застосуйте NRPT/scoped domains.
5. Блокуйте вихідний TCP/853 там, де доречно. Дозвольте винятки лише для власних резолверів. Документуйте винятки явно.
6. Керування DoH. Або:
   • Дозволяйте корпоративний DoH і блокуйте відомі сторонні DoH там, де можливо, або
   • Дозволяйте DoH широко, але гарантуйте, що внутрішні домени резолвляться через внутрішні канали (NRPT/scoped resolvers).
7. Зробіть внутрішній DNS швидким. Додайте регіональні форвардери, кешування і резервування. Моніторьте латентність і частоти помилок.
8. Тестуйте на реальних клієнтах. Перевірте на Windows/macOS/Linux та принаймні на одній мобільній платформі, якщо її підтримуєте.
9. Операціоналізуйте: логування + дашборди. Відстежуйте обсяг запитів до резолверів, SERVFAIL, NXDOMAIN і топ‑доменів. Слідкуйте за різкими падіннями (обхід).
10. Напишіть рукопис дій (runbook). Включіть Швидкий план діагностики і 12+ завдань вище. Майбутній ви це оцінить.

Контрольний список для рев’ю змін (логіка для друку)

• Чи вплине ця зміна на те, який резолвер відповідає на корпоративні імена?
• Чи підтримує рішення роздільні view або умовне форвардінг?
• Чи є відповідь для DoH на рівні браузера і DoT на рівні ОС?
• Що станеться під час часткового збою (поведінка відкоту)?
• Чи маємо метрики латентності і помилок для корпоративних резолверів?
• Чи є явна політика для некерованих пристроїв?

Питання й відповіді (FAQ)

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

Ні. Некерований DoH шкідливий для підприємств. Керований DoH — нормальний і часто кращий варіант. Конфлікт у контрольній площині, а не в шифруванні.

2) Чи варто блокувати DoH повсюди?

Лише якщо ви можете забезпечити альтернативу, яка задовольнить вимоги приватності й надійності. Сліпе блокування часто призводить до відкату на незашифрований DNS або до обходів.
Краще: надайте корпоративний DoH/DoT і управляйте вибором резолвера.

3) Навіщо існує роздільний DNS, якщо він такий крихкий?

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

4) Чи вирішує це DNSSEC?

DNSSEC допомагає перевірити автентичність відповідей. Він не шифрує запити і не завадить кінцевим пристроям використовувати неправильний резолвер.
Ви можете (і часто повинні) використовувати DNSSEC разом із DoH/DoT, але це не заміна.

5) Якщо я запускаю внутрішній DoH, чи все ще потрібен роздільний DNS?

Якщо у вас є внутрішні кінцеві точки, то так. DoH не замінює роздільний DNS; він змінює транспорт. Вам все одно потрібні views/forwarding, щоб внутрішні імена резолвилися правильно.

6) Яке найбезпечніше мінімальне виправлення, якщо я не можу робити великий проєкт?

Примусова маршрутизація за доменом для внутрішніх просторів імен (NRPT/scoped domains) та видалення публічних резолверів з керованих конфігурацій.
Потім блокуйте вихідний TCP/853, щоб зменшити некерований DoT.

7) Як працювати з мобільними пристроями?

Розглядайте їх окремо. Якщо вони керовані, натисніть DNS‑профіль і обмежте налаштування Private DNS. Якщо це BYOD, не розраховуйте, що роздільний DNS працюватиме.
Надавайте внутрішні додатки через публічний DNS з сильною автентифікацією або використовуйте керований контейнер/робочий профіль.

8) Чому додавання «резервного» публічного DNS спричиняє відмови?

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

9) Чи можна покладатися на пошукові домени замість FQDN?

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

10) Яка найкраща метрика для виявлення обходу DoH?

Різке падіння обсягу запитів до ваших внутрішніх резолверів, особливо з мереж, де кількість кінцевих пристроїв не змінилася.
Спаруйте це з спостереженнями egress (TCP/853, відомі DoH‑ендпоінти) і звітністю відповідності кінцевих пристроїв.

Висновок: наступні кроки, які можна виконати цього тижня

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

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

1. Прогніть Швидкий план діагностики на одному реальному користувачі з помилкою і задокументуйте, який резолвер відповів.
2. Видаліть «вторинний публічний DNS» з профілів VPN і керованих конфігурацій кінцевих пристроїв.
3. Реалізуйте маршрутизацію за доменом для внутрішніх просторів імен (NRPT/scoped resolvers) як базу.
4. Сплануйте й розгорніть корпоративні DoH/DoT‑ендпоінти, потім поширіть їх через MDM/GPO.
5. Моніторьте латентність і рівні помилок резолверів; ставтеся до DNS як до продакшн‑інфраструктури, бо це так.

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