Захищений DNS на Windows: DoH/DoT — що реально працює

Що насправді означає «захищений DNS» на Windows

DNS — це службова книга, яку весь стек вважає надійною, поки вона такою не стає. Традиційний DNS переважно працює по UDP/53, без автентифікації, і часто його можна перехопити або змінити «по дорозі». «Захищений DNS» зазвичай означає один із двох транспортів:

• DoT (DNS over TLS): DNS-повідомлення всередині TLS, зазвичай TCP/853. Мережа бачить це як «DNS‑трафік». Легше ідентифікувати й блокувати; іноді простіше дозволити навмисно.
• DoH (DNS over HTTPS): DNS-повідомлення всередині HTTPS, зазвичай TCP/443. Зливається з веб‑трафіком. Чудово обходить captive‑портали і примхливі middlebox‑и; також чудово обходить вашу корпоративну політику DNS, якщо ви не обережні.

Ні DoH, ні DoT автоматично не роблять DNS «достовірним». Ви все ще можете питати резолвер, який бреше. Ви все ще можете витікати запити через fallback. І ви все ще можете зламати внутрішнє розвʼязування, відправляючи приватні зони на публічні резолвери. Шифрування транспорту — це один шар: воно покращує приватність і цілісність «по дорозі», але не вирішує управління.

На Windows «захищений DNS» має конкретний операційний зміст: клієнт DNS Windows (Dnscache) надсилає запити до налаштованого резолвера через DoH (і в деяких випадках переходить на fallback). DoT не є основною системною опцією по всій ОС так, як на деяких інших платформах; ви частіше зустрінете його в спеціалізованих клієнтах, пристроях або там, де підприємство запускає власні DoT‑фворвардери.

І ще одна вісь — браузери. Chrome, Edge і Firefox можуть виконувати власний DoH незалежно від налаштувань Windows, залежно від політик і конфігурацій. Тому ви можете «увімкнути DoH у Windows» і все одно мати додатки, що його обходять. Або вимкнути — і браузери все одно будуть це робити. Саме тут ваша служба відповідності раптом проявляє інтерес до захоплень пакетів.

Операційне правило: якщо ви не можете довести, який резолвер відповів і яким транспортом, у вас нема конфігурації — у вас система вірувань.

Цікаві факти й історичний контекст (коротко, корисно, іноді дратівливо)

1. DNS зʼявився раніше за веб. Робота над специфікацією DNS почалася на початку 1980‑х як масштабована заміна підходу з HOSTS.TXT.
2. DNSSEC старіший за DoH/DoT. Основні RFC для DNSSEC зʼявилися в середині 2000‑х; це вирішує автентичність даних, а не приватність транспорту.
3. DoT був стандартизований раніше за DoH. DoT (RFC 7858) зʼявився першим; DoH (RFC 8484) пішов слідом, значною мірою за ініціативою браузерних і приватнісних спільнот.
4. Багато «DNS‑фільтрів» залежали від доступності відкритого тексту. Коли ви шифруєте DNS, ви змінюєте не лише приватність, але й площину примусового застосування — часто без повідомлення команд, що її обслуговують.
5. EDNS Client Subnet (ECS) ускладнює приватність. Дехто з резолверів надсилає часткову інформацію про підмережу клієнта вгору по ланцюгу, щоб поліпшити локалізацію CDN, жертвуючи приватністю заради продуктивності.
6. Розвʼязування імен у Windows — це не лише DNS. Існують LLMNR, mDNS, NetBIOS і правила NRPT в деяких середовищах; DoH покриває лише ті DNS‑запити, які робить саме клієнт Windows DNS.
7. Captive‑портали ненавидять зашифрований DNS. Вони часто залежать від перехоплення DNS, щоб перенаправити вас на сторінку входу; DoH обминає це — іноді добре, іноді це причина «чому я не можу підключитися до готельного Wi‑Fi».
8. Підприємства історично використовували DNS як площину управління. Блокування доменів, спрямування трафіку, sinkholing шкідливого ПЗ або розділення внутрішніх/зовнішніх зон — шифровані транспорти не усувають ці потреби; вони змінюють спосіб їх реалізації.

Матриця підтримки Windows: DoH vs DoT vs «браузерна магія»

Що робить (і не робить) Windows

Windows 11 і сучасні збірки Windows 10 підтримують DoH на рівні ОС для клієнта DNS Windows. Ви можете налаштувати його на кожному інтерфейсі й для кожного резолвера. ОС намагається використовувати DoH для сумісних резолверів; залежно від налаштувань вона може перейти на відкритий текст, якщо DoH не вдається. Поведінка fallback — це різниця між «доволі приватно» і «тихо витікає».

OS‑широкий DoT не є основним функціоналом кінцевих Windows‑пристроїв. Ви зустрінете DoT у мережевому обладнанні, DNS‑форвардерах і сторонніх клієнтах. На Windows‑робочих станціях, коли люди кажуть «захищений DNS», вони майже завжди мають на увазі DoH.

Браузери: паралельна реальність

Браузери можуть робити DoH незалежно від Windows. Це означає:

• Ваш браузер може використовувати DoH навіть якщо Windows налаштовано на відкритий текст.
• Ваш браузер може все ще використовувати відкритий текст, навіть якщо Windows використовує DoH — залежно від налаштувань браузера і політик.
• Split DNS (внутрішні зони) може ламатися креативними способами, якщо браузер використовує публічний резолвер для імен, що існують лише всередині мережі.

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

Резолвери важать більше за маркетинг

DoH у Windows — це не «увімкнули шифрування і все працює». Windows потребує резолвера, який підтримує DoH, і, залежно від конфігурації, відомий шаблон/відповідність endpoint. Публічні резолвери зазвичай працюють. Ваш внутрішній резолвер може не працювати, якщо ви не реалізували або не придбали DoH‑підтримку.

Також: якщо ви запускаєте власний DoH, деталі сертифікатів і SNI мають значення. TLS — це не «враження», це суворо.

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

Що я рекомендую (і чого уникаю)

Для більшості підприємств: оберіть одну з двох раціональних моделей

Модель A: корпоративний резолвер + зашифрований транспорт до нього. Кінцеві пристрої використовують корпоративний DNS‑резолвер (або форвардер) як зазвичай, але транспорт від пристрою до резолвера шифрується (DoH, якщо ви на Windows; DoT, якщо стандартизуєте це в інших місцях). Резолвер реалізує політику, split DNS, логування й потреби інцидент‑реакції. Це модель «збереження управління».

Модель B: керований публічний резолвер зі строгим контролем політик. Якщо ви невелика організація або не маєте внутрішніх зон, можна використовувати перевірені публічні резолвери з DoH і примусово задавати це через політику кінцевих пристроїв. Ви втрачаєте можливості split DNS, якщо не додасте щось інше, але й зменшуєте складність.

Чого я уникаю

• Тихого fallback на відкритий текст, якщо ви явно не прийняли ризик. Якщо мета — приватність/цілісність, «best effort» перетворюється на «best excuse».
• Запуску внутрішніх зон при дозволі браузерам використовувати публічний DoH без контролю. Саме так «інтранет» перестає працювати в браузері, але ще працює в ping, і всі звинувачують проксі.
• Припущення, що VPN‑клієнти не втручаються. Багато VPN встановлюють власний DNS, змінюють метрики інтерфейсів або навʼязують конкретні резолвери. Розглядайте VPN як двигун конфігурації DNS.
• Припущення, що засоби безпеки не втручаються. Деякі стекі безпеки на кінцевих пристроях і проксі для інспекції TLS ламають або погіршують DoH залежно від політик.

Цитата, щоб не забувати реальність: Сподівання — не стратегія. (парафраз відомої ідеї з практики операцій та надійності)

Практичні перевірки (команди, виводи, рішення)

Це реальні завдання, які ви можете виконати на Windows‑машині (PowerShell) або з Linux‑скоку в тій самій мережі. Кожне завдання містить: команду, реалістичний фрагмент виводу, що це означає, і рішення, яке слід ухвалити.

Завдання 1 — Визначте, які DNS‑сервери Windows вважає потрібними

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"
InterfaceAlias ServerAddresses
-------------- --------------
Ethernet       {10.20.0.10, 10.20.0.11}
Wi-Fi          {192.168.1.1}

Значення: Windows надсилатиме запити на 10.20.0.10/11 через Ethernet і 192.168.1.1 через Wi‑Fi. Якщо DoH налаштовано, воно буде повʼязане з цими IP‑адресами (і іноді з шаблонами).

Рішення: Якщо ви очікуєте корпоративний DNS на всіх мережах, 192.168.1.1 — сигнал тривоги. Виправте правила DHCP/VPN або метрики інтерфейсів до того, як шукати привидів DoH.

Завдання 2 — Перевірте налаштування DNS на інтерфейсі і чи можливі витоки через «неправильний інтерфейс»

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Format-Table ifIndex,InterfaceAlias,InterfaceMetric,NlMtu -AutoSize"
ifIndex InterfaceAlias InterfaceMetric NlMtu
------ -------------- -------------- -----
12     Ethernet       15             1500
7      Wi-Fi          55             1500

Значення: Менший metric виграє. Ethernet буде в пріоритеті для маршрутизації і часто для поведінки DNS щодо «основного інтерфейсу».

Рішення: Якщо Wi‑Fi ніколи не повинен використовуватися для корпоративного розвʼязування (часто при підключенні до док‑станції), встановіть метрики або вимкніть інтерфейс під час докінгу.

Завдання 3 — Підтвердіть, чи увімкнено DoH у Windows і для яких резолверів

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientDohServerAddress | Format-Table -AutoSize"
ServerAddress Template               AllowFallback AutoUpgrade
------------- --------               ------------- -----------
10.20.0.10    https://dns.corp/dns-query False         False
10.20.0.11    https://dns.corp/dns-query False         False

Значення: Windows має явні відповідності DoH для корпоративних резолверів, і AllowFallback False означає, що він не має тихо переходити на відкритий текст для цих IP.

Рішення: Якщо ви не бачите записів, DoH на рівні ОС, ймовірно, не налаштовано. Якщо AllowFallback True, вирішіть, чи готові ви прийняти витік‑за‑дизайном у випадку збою.

Завдання 4 — Перевірте вплив таблиці політик розвʼязування імен (NRPT) (поширено при VPN)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptRule | Select-Object -First 5 | Format-List"
Namespace : .corp.example
NameServers : {10.20.0.10, 10.20.0.11}
DirectAccessDnsServers :
DnsSecValidationRequired : False

Значення: Запити для .corp.example змушуються йти на конкретні сервери. Це може переважати «глобальні» налаштування резолвера і часто є тим, що вам потрібно для split DNS.

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

Завдання 5 — Запитайте запис і підтвердіть, який сервер відповів (базова функціональність)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName intranet.corp.example -Type A -Server 10.20.0.10"
Name                           Type   TTL   Section    IPAddress
----                           ----   ---   -------    ---------
intranet.corp.example          A      60    Answer     10.30.4.25

Значення: Базове розвʼязування працює проти корпоративного резолвера.

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

Завдання 6 — Перевірте, чи досяжний DoH endpoint з клієнта

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection dns.corp -Port 443"
ComputerName     : dns.corp
RemoteAddress    : 10.20.0.10
RemotePort       : 443
InterfaceAlias   : Ethernet
TcpTestSucceeded : True

Значення: TCP/443 до DoH endpoint доступний з цього клієнта на очікуваному інтерфейсі.

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

Завдання 7 — Перевірте ланцюг сертифікатів TLS, який бачить Windows (поширений корпоративний збій)

cr0x@server:~$ powershell -NoProfile -Command "openssl s_client -connect dns.corp:443 -servername dns.corp -showcerts < NUL | findstr /R /C:\"subject=\" /C:\"issuer=\""
subject=CN = dns.corp
issuer=CN = Corp Issuing CA 01

Значення: Сервіс представляє сертифікат для dns.corp, підписаний внутрішнім CA.

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

Завдання 8 — Перевірте операційні події клієнта Windows DNS (що він намагався робити)

cr0x@server:~$ powershell -NoProfile -Command "wevtutil qe Microsoft-Windows-DNS-Client/Operational /c:5 /f:text"
Event[0]:
  Provider Name: Microsoft-Windows-DNS-Client
  Event ID: 3018
  Level: Warning
  Description: Name resolution for the name intranet.corp.example timed out after none of the configured DNS servers responded.

Значення: DNS‑клієнт сплинув за таймаутом. Це ще не каже, DoH чи відкритий текст, але доводить, що проблема на шляху клієнт‑резолвер (не в додатку).

Рішення: Корелюйте часові мітки з логами файрвола й захопленням пакетів. Якщо таймаути відбуваються лише коли увімкнено DoH, підозрюйте проблеми з TLS/проксі.

Завдання 9 — Перевірте, чи браузер обходить системний DNS (Firefox відомо незалежністю)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process firefox -ErrorAction SilentlyContinue | Select-Object -First 1 | Format-Table Name,Id"
Name    Id
----    --
firefox 10432

Значення: Firefox запущено. Це не доказ DoH, але нагадування: браузери можуть ігнорувати рішення ОС щодо резолвера.

Рішення: Якщо внутрішні імена не працюють у браузері, але працюють у Resolve-DnsName, перевірте політики DoH у браузері перед зміною налаштувань Windows DoH.

Завдання 10 — Підтвердіть, чи запити DNS досі йдуть по UDP/53 (тест витоку через захоплення пакетів на Linux)

cr0x@server:~$ sudo tcpdump -ni eth0 'host 10.20.0.50 and (udp port 53 or tcp port 53 or tcp port 443)' -c 10
IP 10.20.0.50.51722 > 10.20.0.10.443: Flags [S], seq 11223344, win 64240, options [mss 1460], length 0
IP 10.20.0.10.443 > 10.20.0.50.51722: Flags [S.], seq 99887766, ack 11223345, win 65160, options [mss 1460], length 0
IP 10.20.0.50.51722 > 10.20.0.10.443: Flags [.], ack 1, win 64240, length 0

Значення: Ви бачите TCP/443 тристороннє рукостискання до резолвера. Не видно UDP/53 у перших пакетах — хороший знак для використання DoH (не остаточний без глибшого огляду).

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

Завдання 11 — Перевірте налаштування проксі, що можуть перехоплювати або блокувати DoH

cr0x@server:~$ powershell -NoProfile -Command "netsh winhttp show proxy"
Current WinHTTP proxy settings:

    Proxy Server(s) : 10.20.1.25:8080
    Bypass List     : (none)

Значення: Системні служби, що використовують WinHTTP, підуть через проксі, якщо не буде обходу. Деякі реалізації DoH і endpoint‑и не люблять такої схеми.

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

Завдання 12 — Перевірте поведінку локального DNS‑кешу (старіння може виглядати як «DoH зламався»)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientCache | Select-Object -First 5 | Format-Table -AutoSize Entry,Data,TimeToLive"
Entry                 Data           TimeToLive
-----                 ----           ----------
intranet.corp.example 10.30.4.25     00:00:42
wpad.corp.example     10.20.1.25     00:12:10

Значення: Кеш клієнта містить записи з TTL. Якщо ви щойно змінили DNS‑записи і «воно все ще розвʼязується неправильно», можливо, це просто кеш.

Рішення: Якщо ви діагностуєте правильність — очистіть кеш і перезапустіть тест. Якщо ви діагностуєте продуктивність — кеш частина історії; не очищуйте його без потреби.

Завдання 13 — Очистіть DNS‑кеш, щоб відокремити проблему резолвера від кешу

cr0x@server:~$ powershell -NoProfile -Command "Clear-DnsClientCache; Write-Output 'cache cleared'"
cache cleared

Значення: Кеш очищено на клієнті.

Рішення: Якщо проблеми зникають після очищення, а потім повертаються — ви ганяєтеся за TTL/negative caching або непослідовними відповідями вгорі по ланцюгу, а не за транспортом.

Завдання 14 — Доведіть, який процес використовує локально порт 53 (рідко, але трапляється)

cr0x@server:~$ powershell -NoProfile -Command "netstat -ano | findstr \":53 \" | more"
  UDP    0.0.0.0:5353           *:*                                    1234
  UDP    192.168.1.10:49712     192.168.1.1:53                         0

Значення: У вас запущено mDNS (5353) і вихідний UDP/53 трафік з хоста. Рядок UDP/53 вказує, що відкритий текст DNS все ще використовується десь.

Рішення: Якщо ви очікуєте лише DoH, зʼясуйте, чому існує UDP/53: інший інтерфейс, інший резолвер, fallback або локальний сервіс (VPN, агент безпеки), що робить власне розвʼязування.

Завдання 15 — Перевірте overrides у файлі hosts (бо хтось завжди «полагодив DNS» локально)

cr0x@server:~$ powershell -NoProfile -Command "Get-Content C:\Windows\System32\drivers\etc\hosts | Select-Object -Last 5"
# ::1             localhost
10.30.4.99        intranet.corp.example

Значення: Файл hosts примушує intranet.corp.example на 10.30.4.99. Тут транспорт DNS не має значення.

Рішення: Видаліть несанкціоновані overrides і перезапустіть тести. У підприємстві розглядайте це як інцидент конфігураційного відхилення, а не «клієнтське налаштування».

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

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

Перше: це вибір резолвера, а не шифрування?

• Запустіть Get-DnsClientServerAddress і підтвердіть, що потрібні IP резолверів дійсно налаштовані.
• Перевірте метрики інтерфейсів за допомогою Get-NetIPInterface, коли існує кілька адаптерів (Wi‑Fi + Ethernet + VPN).
• Перевірте правила NRPT, якщо у вас є VPN або split DNS.

Якщо вибрано неправильний резолвер: виправте DHCP/VPN/політику/пріоритет інтерфейсу. Не починайте з ковиряння в DoH‑шаблонах.

Друге: чи досяжний і довірений DoH endpoint?

• Test-NetConnection до TCP/443 на домені DoH.
• openssl s_client для перевірки subject/issuer сертифікату і SNI.
• Перевірте WinHTTP proxy через netsh winhttp show proxy.

Якщо TLS/сертифікат/проксі проблема: ви побачите таймаути або помилки handshake; виправте довірчий ланцюжок і обхід проксі. Не переключайте fallback у надії, що «заспокоїться».

Третє: чи витікає через fallback або інші стекі?

• Перевірте Get-DnsClientDohServerAddress на AllowFallback.
• Захопіть трафік (tcpdump/Wireshark) на наявність UDP/53.
• Перевірте поведінку DoH на рівні браузера, якщо симптоми специфічні для додатку.

Якщо витік є: вирішіть, чи примушуєте ви «тільки DoH» (і приймаєте поломки при збої), чи дозволяєте fallback (і приймаєте прогалини в приватності/цілісності). Обирайте свідомо.

Четверте: це насправді проблема продуктивності резолвера?

• Порівняйте затримку запитів до та після увімкнення DoH.
• Шукайте часту зміну TLS‑сесій (churn) замість повторного використання.
• Перевірте симптоми кеш‑хітності локально (проблеми зникають після «прогріву»).

Якщо це продуктивність: швидше за все потрібно налаштувати потужність резолвера, поведінку keep‑alive або вартість політик, а не «більше шифрування».

Три корпоративні міні‑історії з передової

Інцидент №1 — Аутейдж через неправильне припущення

План був простий: увімкнути DoH на Windows‑ноутбуках, щоб зменшити підслуховування DNS у публічних Wi‑Fi. Роллаути були по стадіях, політики були сфокусовані, а CAB‑тикет мав те знайоме ауре «безпечного покращення».

Через два дні внутрішні веб‑додатки почали відмовляти — тільки в браузерах, тільки для деяких користувачів і тільки поза офісом. Ping до внутрішніх імен працював. Remote Desktop працював. Але інтранет‑портал в Edge і Chrome повертав «host not found».

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

Виправлення не було героїчним. Вони ввели політику браузера: або відключити DoH у браузерах, або вказати корпоративний DoH endpoint, що розуміє split DNS. Після цього симптоми зникли. Урок: розвʼязування імен — це стек стеків, і браузери вже не «просто програми» — вони платформи з власними думками.

Інцидент №2 — Оптимізація, що відплатилася

Інша компанія мала скаргу на продуктивність: «DNS повільний на Windows при увімкненому DoH». Хтось помітив, що DoH endpoint був за шаром L7‑проксі, який робив TLS‑інспекцію та автентифікацію. Швидкою оптимізацією стало перенести DoH‑сервіс за глобальний load balancer з агресивними перевірками стану і короткими таймаутами зʼєднань. На папері: нижча затримка, краща доступність.

На практиці балансувальник термінував TLS і встановлював його заново до upstream. Це не було автоматично погано, але це створило постійну зміну зʼєднань. Деякі клієнти перепідключалися часто, і DoH‑сервіс витрачав CPU на handshakes. Пікові години перетворили резолвер на фабрику TLS зі стороннім бізнесом у DNS‑відповідях.

Гірше: health checks виглядали як «допустимий HTTPS‑трафік», але не тестували реальний DoH‑хендлер послідовно. LB визнавав бекенди здоровими навіть коли DoH‑шлях деградував, бо TCP/TLS шар був в порядку. Користувачі бачили випадкові збої, що корелювали лише з «після обіду».

Вони відкотили «оптимізацію», потім повернули зміни обережно: налаштували keep‑alive, перевірили health checks на фактичний DoH‑шлях і уникали непотрібного термінування TLS. Продуктивність покращилася, але головний виграш — операційна прозорість: якщо ви не можете виміряти DoH‑хендлер окремо від TLS, ви літаєте в темряві.

Інцидент №3 — Нудна, але правильна практика, що врятувала день

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

Під час глобального оновлення Windows у підгрупи пристроїв почалися збої DoH через проблему довіри сертифікатів. Сертифікат резолвера був коректний, але ротація проміжного CA не була повністю розгорнута в усіх образах пристроїв. Деякі ноутбуки могли валідувати ланцюжок; деякі — ні. Поведінка залежала від налаштувань fallback і того, чи пристрій на VPN.

Оскільки команда мала визначений чекліст перевірки, helpdesk не витрачав дні на звинувачення «інтернету». Вони зібрали стандартний пакет: вивід DoH‑mapping, журнали подій і швидку TLS‑перевірку. Паттерн став очевидний за кілька годин: пристрої без проміжного CA не могли робити DoH, а пристрої з відключеним fallback мали жорсткі збої.

Виправлення було теж нудним: розгорнути відсутній проміжний у керуванні кінцевими пристроями, підтвердити через перевірку сховища сертифікатів і перезапустити завдання перевірки. Ніхто не отримав грамоту. Але й ніхто не мав тижневого інциденту. У операціях нудна рутина часто — найвищий рівень компетентності.

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

1) «Захищений DNS увімкнено», але захоплення пакетів показує UDP/53

Симптоми: Ви все ще бачите DNS‑запити по UDP/53 з хоста; інструменти приватності звітують про витоки.

Причина: DoH не налаштовано для фактичних IP резолверів; дозволено fallback; або інший інтерфейс/VPN‑адаптер все ще використовує відкритий текст.

Виправлення: Перевірте IP резолверів (Get-DnsClientServerAddress), перевірте DoH‑відповідності (Get-DnsClientDohServerAddress), встановіть AllowFallback False там, де потрібно, і виправте пріоритет адаптера.

2) Внутрішні імена працюють лише в командному рядку, а в браузері — ні

Симптоми: Resolve-DnsName intranet.corp.example працює; браузер повертає NXDOMAIN або «не знайдено».

Причина: DoH на рівні браузера використовує публічні резолвери; split DNS не дотримується.

Виправлення: Примусово задати політику браузера, щоб відключити DoH або вказати корпоративний DoH; переконайтеся, що внутрішні зони розвʼязуються через корпоративний шлях резолвера.

3) DoH працює в головному офісі, але ламається через VPN

Симптоми: На LAN: усе добре. На VPN: таймаути. Вимкнення «захищеного DNS» вирішує проблему.

Причина: VPN навʼязує NRPT‑правила або DNS‑сервери, які не мають DoH‑відповідностей; VPN блокує доступ до DoH endpoint; налаштування проксі відрізняються на VPN.

Виправлення: Узгодьте резолвери, що надсилає VPN, з DoH‑відповідностями; забезпечте доступність DoH hostname через VPN; додайте правильний обхід проксі для DoH endpoint.

4) Періодичні збої після увімкнення DoH

Симптоми: Деякі запити зависають, потім вдаються. Випадкові таймаути додатків. «Працює після перезавантаження».

Причина: Нестабільність TLS‑handshake (інспекція проксі, проблеми з MTU), обмеження потужності резолвера або балансувальник закриває прості зʼєднання занадто агресивно.

Виправлення: Перевірте MTU шляху; перевірте доступність TCP/443 і TLS‑ланцюг; налаштуйте keep‑alive/таймаути балансувальника; масштабуйтесь або зменшуйте вартість політик резолвера.

5) «DoH endpoint доступний», але Windows не використовує його

Симптоми: HTTPS до endpoint працює в браузері; Windows досі використовує відкритий текст або відмовляється.

Причина: Відсутня DoH‑відповідність/шаблон для IP резолвера; невідповідність імені в сертифікаті; проблеми SNI.

Виправлення: Переконайтеся, що DoH‑шаблон співпадає з резолвером, а сертифікат дійсний для імені, яке використовує Windows; перевірте за допомогою openssl s_client -servername.

6) DNS‑фільтрація раптово перестала працювати

Симптоми: Доменні імена, що раніше блокувалися, тепер розвʼязуються; команда безпеки бачить менше DNS‑телеметрії.

Причина: Кінцеві пристрої/браузери перейшли на зовнішні DoH‑резолвери, обходячи корпоративні контролі DNS.

Виправлення: Примусьте політику резолверів (на кінцевих пристроях і/або на виході мережі). Якщо потрібна фільтрація, тримайте розвʼязування на резолверах під вашим контролем.

Жарт №2: Зашифрований DNS чудовий — поки ви не зрозумієте, що улюблений інструмент служби підтримки був «побачити, що введено в домен».

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

План A — Корпоративний rollout DoH на Windows (без самозавданих ран)

1. Інвентаризуйте ваші резолвери: перелікуйте IP‑адреси DNS‑серверів, які отримують кінцеві пристрої на LAN, Wi‑Fi і VPN. Якщо ви не можете їх перелічити — ви не готові.
2. Визначте стратегію примусового застосування: дозволити fallback (менше ризику відмов, більше витоків) або заборонити (сильніша гарантія, більш крихке рішення). Запишіть рішення.
3. Розгорніть/перевірте DoH endpoint: забезпечте доступність TCP/443 з усіх мереж, коректні сертифікати, правильну поведінку SNI і передбачуване балансування навантаження.
4. Реалізуйте DoH‑відповідності: звʼяжіть кожен IP резолвера з DoH‑шаблоном endpoint і встановіть поведінку fallback.
5. Обробіть split DNS явно: NRPT‑правила для внутрішніх зон повинні вказувати на корпоративні резолвери з увімкненим DoH.
6. Узгодьте політику браузера: або відключіть DoH у браузерах, або вкажіть браузерам той самий корпоративний DoH endpoint, щоб уникнути split‑DNS проблем.
7. Виміряйте до/після: затримку розвʼязування, частоту відмов і наявність UDP/53 у вихідному трафіку. «Виглядає нормально» — не метрика.
8. Розгортайте по кільцях: IT‑персонал, power users, потім ширше. Збирайте логи і приклади трафіку в кожному колі.
9. Майте план відкату: один перемикач політики, щоб повернутися до відкритого тексту під час діагностики.

План B — Мала організація / без внутрішніх зон (просто та надійно)

1. Оберіть стратегію резолвера: один провайдер, дві IP‑адреси для резервування, стабільний DoH endpoint.
2. Увімкніть DoH на рівні ОС з явними відповідностями і визначте fallback. Якщо ви робите це для приватності — не ставте fallback «ну хай буде».
3. Перевірте еґрес: підтвердіть, що використовується лише TCP/443 до резолвера і що UDP/53 не витікає до випадкових маршрутизаторів.
4. Узгодьте браузери: не дозволяйте браузеру вибирати інший резолвер, ніж ОС, якщо не бажаєте налагоджувати проблему.

Операційний чекліст — Перед тим як звинувачувати DoH

• Чи правильний IP резолвера для цієї мережі?
• Чи доступний DoH‑hostname по TCP/443 з цієї мережі?
• Чи довіряє endpoint ланцюжку сертифікатів?
• Чи проксі перехоплює або блокує DoH‑потік?
• Чи браузер використовує власні налаштування DoH?
• Чи захоплення пакетів показує UDP/53 (витік) або лише 443 (очікувано)?

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

1) Чи увімкнення DoH у Windows автоматично захищає весь DNS на машині?

Ні. Воно захищає DNS‑запити, зроблені через клієнт DNS Windows, до резолверів, які налаштовано/маповано для DoH. Додатки та браузери можуть робити власні DNS‑запити (включно з власним DoH), а інші протоколи, як mDNS/LLMNR, окремі.

2) Чи DoH «кращий» за DoT?

З операційної точки зору: DoT легше ідентифікувати й керувати на мережевому рівні; DoH важче відрізнити від звичайного HTTPS і тому складніше контролювати. З точки зору приватності вони обидва можуть бути хорошими. В підприємствах «кращий» означає «підходить під нашу політику і не ламає split DNS».

3) Чому внутрішній split DNS ламається при увімкненому DoH?

Він ламається, коли запити для внутрішніх зон йдуть до резолвера, який їх не знає — часто до публічного DoH‑резолвера, який використовує браузер. Виправте це, забезпечивши політику браузера і гарантуючи, що внутрішні зони розвʼязуються через корпоративні резолвери (помагає NRPT).

4) Якщо я відключу fallback, чи щось зламається?

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

5) Чи може TLS‑інспекція (proxy) зламати DoH?

Так. Деякі проксі блокують або заважають DoH‑endpointам; інші «працюють», але додають затримку і нові моди відмови. Якщо вам потрібно інспектувати трафік, розглядайте DoH як окремий додаток з власними SLO і тестуйте його відповідно.

6) Як довести, що DoH реально використовується?

Використайте комбінацію: перевірте DoH‑відповідності Windows, підтвердіть TCP/443‑зʼєднання до DoH endpoint і захопіть трафік, щоб підтвердити відсутність UDP/53 до ваших резолверів. Для глибокого доказу перевірте HTTPS‑запити до DoH‑шляху на сервері (логи) або телеметрію на кінцевому пристрої.

7) Чому я бачу UDP/53, хоч DoH налаштовано?

Типові причини: дозволений fallback, інший інтерфейс використовує відкритий текст, VPN ввів резолвер без DoH‑відповідності або локальний агент виконує власне розвʼязування. Розглядайте UDP/53 як симптом і трасуйте, який процес/інтерфейс його породжує.

8) Чи DoH замінює DNSSEC?

Ні. DoH шифрує транспорт; DNSSEC підписує записи для автентичності (за умов правильної валідації). Вони вирішують різні завдання і можуть використовуватися разом.

9) Чи покращить DoH продуктивність DNS?

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

10) Який найбезпечніший дефолт для корпоративних ноутбуків?

Корпоративний резолвер + явна DoH‑відповідність + політика браузера, узгоджена з корпоративним розвʼязуванням + свідомий вибір щодо fallback. «Найбезпечніше» — це послідовність. Непослідовне розвʼязування породжує в той же час прогалини у безпеці і відмови.

Наступні кроки, що не зіпсують ваш понеділок

Робіть це в порядку:

1. Оберіть модель: корпоративний резолвер з DoH‑транспортуванням або керований публічний резолвер. Не робіть і те, і інше без чітких меж.
2. Зробіть все спостережуваним: визначте, як ви доведете транспорт і ідентичність резолвера (журнали подій, захоплення пакетів, серверні логи).
3. Узгодьте браузери: впровадьте політику, щоб браузери не обходили вашу стратегію DNS.
4. Вирішіть щодо fallback: прийміть витоки (fallback увімкнено) або відмови (fallback вимкнено). Задокументуйте вибір і план відкату.
5. Запустіть перевірки вище на трьох мережах: LAN головного офісу, домашній Wi‑Fi і VPN. Більшість проблем DNS — «працює в одному місці».

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