Debian 13: DNS через TLS/HTTPS — увімкніть без порушення корпоративних мереж (випадок №51)

January 9, 2026 • February 3, 2026 • Читання: 5 хв • Views: 8

Було корисно?

Шифрований DNS — це покращення, яке здається нудним, поки ви не опинитесь на виклику о 02:00, читаючи пакетний дамп і не зрозумієте, що половина парку витікає внутрішні імена хостів у ту випадкову Wi‑Fi точку доступу, до якої вони приєдналися. Ви хочете DoT або DoH заради приватності, цілісності і інколи простішої надійності.

Проте корпоративні мережі мають власні вимоги: split‑horizon зони, внутрішні резолвери з політикою, проксі, які перехоплюють трафік, VPN‑клієнти, що «допомагають», і відповідальні за відповідність, які хочуть знати, куди йшли ваші запити. Debian 13 може коректно працювати зі шифрованим DNS, але потрібно поважати середовище, інакше ви створите повільно розвиваючийся інцидент.

Що саме ви змінюєте (і що ні)

На Debian 13 практичний спосіб «увімкнути шифрований DNS» — поставити systemd-resolved на місце відповідача і повідомити його використовувати один з варіантів:
a) ваші корпоративні резолвери через DoT, якщо вони це підтримують, або
b) контрольований DoH/DoT форвардер, який ви керуєте (рекомендовано), або
c) публічний резолвер (тільки якщо політика дозволяє і ви готові до наслідків).

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

Також: шифрування DNS не зупиняє SNI, ECH, відстеження за IP або той факт, що хтось все ще бачить, куди ви підключаєтесь. Воно лише зменшує пасивне витікання DNS‑запитів і ускладнює певні форми підробки.

Практична порада: в організаціях не вказуйте кінцеві пристрої безпосередньо на випадкові публічні DoH. Запустіть форвардер (або оновіть внутрішні резолвери), щоб політика, split‑horizon, логування і реагування на інциденти продовжували працювати.

Факти та контекст, які можна повторити на зустрічі

DNS спочатку передбачав дружню мережу. Базовий протокол — UDP/53 з думками 1983 року: швидкий, втратний і легко спостережуваний або підроблюваний.
DNSSEC додає цілісність, а не приватність. Воно може валідувати відповіді, але ваші питання усе ще передаються у відкритому вигляді, якщо ви не використовуєте DoT/DoH.
DoT стандартизовано як RFC 7858 (2016). Це DNS в TLS, зазвичай TCP/853, зрозумілий і у логах видно як «щось, пов’язане з DNS».
DoH стандартизовано як RFC 8484 (2018). Це DNS поверх HTTPS, зазвичай TCP/443, що може зливатися з веб‑трафіком і дратувати команди файрволів.
Браузери спричинили корпоративну негативну реакцію. Автоматичні rollout DoH у браузерах зламали внутрішні зони в багатьох організаціях, через що мережеві команди стали насторожено ставитися до DoH за замовчуванням.
Split‑horizon DNS — це функція, а не хаґ. Внутрішні імена типу corp.example повинні резолвитися по‑різному в середині і ззовні; шифрований DNS не усуває цю потребу, він лише загострює наслідки помилок.
Захоплення captive portal не любить шифрований DNS. Якщо ви не можете резолвити хостнейм порталу до входу в умови, «розумний» DNS може тримати вас офлайн.
Багато корпоративних резолверів уже підтримують шифрування. Сучасні BIND, Unbound і деякі заводські DNS‑пристрої можуть робити DoT/DoH — але сертифікати та політика мають бути оброблені свідомо.
Централізоване логування часто незаперечне. Команди безпеки покладаються на DNS‑логи для розслідувань; обходження внутрішніх резолверів може розцінюватися як порушення політики, а не інновація.

DoT vs DoH: оберіть правильний інструмент для вашої мережі

DoT: передбачувано, дружньо до файрволів (в сенсі підприємства)

DoT використовує окремий порт (853). Це благословення: ви можете дозволити його там, де потрібно, блокувати там, де політика забороняє, і ідентифікувати його у flow‑логах без прикидок, що кожна TLS‑сесія — «просто веб‑трафік».

Якщо в організації є межа безпеки з жорстким контролем egress, DoT зазвичай простіше узгодити. Ви можете довести, що це саме те. Ви також можете маршрутизувати його до внутрішнього кластеру резолверів і зберегти split‑horizon.

DoH: зручно, іноді політично небажано

DoH їде поверх HTTPS. Це чудово для клієнтів в русі, оскільки 443 майже завжди відкритий. Саме тому деякі мережі трактують його як «вивіз політики під виглядом веб‑браузингу». Якщо ваш проксі робить TLS‑інспекцію, DoH може ламатися у кумедні способи, якщо ви не контролюєте обидва кінці.

Користуйтеся DoH, коли маєте відомий, керований кінцевий пункт (власний DoH‑фронтенд або провайдер, схвалений компанією) і розумієте, як він поводиться з проксі, mTLS та перехопленням сертифікатів.

Жорстока правда: коли ви говорите команді файрволу, що хочете «DNS over HTTPS», вони чують «я хочу провезти політику в плащі‑піджаці». І, можливо, вони не помиляються.

Режими відмов у підприємствах: де шифрований DNS гине

Split‑horizon та пошукові домени

Якщо клієнти обходять внутрішні резолвери, внутрішні зони перестануть працювати. Ваш список тикетів наповниться «VPN не працює» і «Git‑сервер недоступний», хоча технічно все «вгору». Виправлення — не «відключити DoH», а «не обходити резолвер, який знає приватні зони».

Проксі‑перехоплення і TLS break‑and‑inspect

Корпоративні проксі, що перехоплюють TLS, можуть спричинити відмову DoH двома протилежними шляхами:
вони або блокують його взагалі, або роблять MITM і показують корпоративний CA, якому ваш DoH‑клієнт не довіряє. Якщо клієнт строгий (як і має бути), ви отримаєте таймаути і загадкову поведінку fallback.

Налаштування DNS від VPN перезаписуються

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

Проміжні пристрої, які «допомагають», переписуючи

Деякі мережі переписують DNS‑відповіді (captive portal, батьківський контроль, фільтри від шкідливого ПЗ). Якщо ви їх обходите, ви обходите цю функцію. Іноді це мета. Іноді ця функція — спосіб, яким гості потрапляють на сторінку входу в Wi‑Fi. Обирайте свій біль.

Регресії продуктивності від накладних витрат handshake та зламаного кешування

TLS‑handshake не безкоштовний. При хорошому повторному використанні з’єднань накладні витрати малі. При поганих мережах, короткоживучих з’єднаннях або неправильно налаштованих резолверах ви можете додати помітну латентність. Люди помічають затримки DNS, бо це проявляється як «інтернет здається повільним», і ніхто не пише точний баг‑репорт.

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

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

Перше: підтвердіть, хто займається DNS і які сервери використовуються.
Якщо система все ще використовує старий /etc/resolv.conf від DHCP, жодні ваші налаштування systemd-resolved не матимуть значення.
Друге: підтвердіть досяжність транспорту (853 для DoT, 443 для DoH‑endpoint).
Заблокований порт виглядає як «таймаут DNS» і з’їсть години, якщо ви одразу цього не перевірите.
Третє: підтвердіть валідацію сертифіката/SNI/імені (особливо для DoT).
Якщо сертифікат резолвера не відповідає очікуванням клієнта, systemd-resolved мовчки деградує залежно від конфігурації. Визначте, чи хочете ви строгий режим або опортуністичний, а потім його ж і застосуйте.

Якщо ці три перевірки пройшли, решта підозрюваних: маршрутизація split DNS, проксі‑перехоплення, помилки валідації DNSSEC або проблеми з продуктивністю/ємністю на боці резолвера.

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

Це польові задачі, які я насправді виконую на Debian‑хостах, коли вмикаю DoT/DoH або діагностую, чому ноутбук не резолвить git.corp.example при підключенні через VPN.

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

Task 1 — Ідентифікуйте активний стек резолверів

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Dec 30 09:12 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Значення: /etc/resolv.conf вказує на systemd stub, тож застосунки будуть запитувати 127.0.0.53, а systemd-resolved виконуватиме upstream‑роботу.

Рішення: Якщо ви не бачите симлінку на системний stub/real resolv.conf, виправте це спочатку; інакше ви змінюватимете налаштування, якими ніхто не користується.

Task 2 — Підтвердьте, що systemd-resolved працює і є авторитетним

cr0x@server:~$ systemctl status systemd-resolved --no-pager
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-12-30 09:10:21 UTC; 6min ago
       Docs: man:systemd-resolved.service(8)
   Main PID: 612 (systemd-resolve)
     Status: "Processing requests..."

Значення: Сервіс резолвера запущений.

Рішення: Якщо він неактивний/відключений, або грамотно увімкніть його, або оберіть інший стек резолверів (Unbound, dnscrypt-proxy тощо) — але не робіть «пів‑увімкнення» обох.

Task 3 — Перегляньте поточну конфігурацію DNS по лінках (перевірка split DNS)

cr0x@server:~$ resolvectl status
Global
       Protocols: +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens192)
    Current Scopes: DNS
         Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.20.30.40
       DNS Servers: 10.20.30.40 10.20.30.41
        DNS Domain: corp.example

Значення: DNS приходить від корпоративних серверів на цьому інтерфейсі; DNS‑over‑TLS наразі вимкнений.

Рішення: Зберігайте per‑link DNS. Не перезаписуйте глобально, якщо не впевнені, що не зламаєте домени, надані через VPN.

Task 4 — Підтвердіть, що система має можливість DoT/DoH у збірці systemd-resolved

cr0x@server:~$ resolvectl --version
systemd 258 (258.2-1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +BPF_FRAMEWORK
+IDN2 +XZ +ZSTD +BZIP2 +LZ4 +ACL +BLKID +CURL +ELFUTILS +FIDO2 +TPM2 +PWQUALITY +P11KIT
default-hierarchy=unified

Значення: Сучасний systemd присутній; підтримка DoT тут стандартна. Підтримка DoH залежить від опцій збірки та версії, тож перевірте у вашому середовищі Debian 13.

Рішення: Якщо потрібен DoH, а ваша збірка його не має (або політика вимагає окремого DoH‑клієнта), плануйте локальний форвардер типу Unbound, що робитиме DoT upstream, або DoH‑проксі під вашим контролем.

Task 5 — Перевірте, чи DNS зараз витікає до публічних резолверів

cr0x@server:~$ grep -vE '^\s*#|^\s*$' /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search corp.example

Значення: Застосунки використовують локальний stub; upstream‑вибір прихований за resolved.

Рішення: Якщо ви бачите тут публічну IP‑адресу, ви вже обходите корпоративний DNS. Вирішіть, чи це дозволено, перш ніж додавати шифрування.

Task 6 — Доведіть, що базове резолвування працює до шифрування

cr0x@server:~$ resolvectl query debian.org
debian.org: 151.101.194.132 151.101.2.132 151.101.66.132 151.101.130.132
          -- Information acquired via protocol DNS in 21.5ms.
          -- Data is authenticated: no

Значення: Базовий DNS працює. Не міняйте транспорт, якщо базова конфігурація вже зламана.

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

Task 7 — Увімкніть DoT у systemd-resolved (opportunistic vs strict)

Відредагуйте /etc/systemd/resolved.conf. Для підприємств почніть з opportunistic DoT, якщо ви не впевнені у сертифікатах, а потім перейдіть до strict.

cr0x@server:~$ sudoedit /etc/systemd/resolved.conf

cr0x@server:~$ grep -nE '^(DNS=|DNSOverTLS=|Domains=|FallbackDNS=)' /etc/systemd/resolved.conf
9:DNS=10.20.30.40#dns.corp.example 10.20.30.41#dns.corp.example
12:FallbackDNS=
15:Domains=~corp.example ~.
20:DNSOverTLS=opportunistic

Значення: Ви закріплюєте внутрішні резолвери і вказуєте очікуване TLS‑ім’я (#dns.corp.example), щоб валідація сертифіката могла працювати, коли ви перейдете в strict. Рядок Domains= вказує на маршрутизацію split DNS: ~corp.example маршрутизується до цих серверів; ~. означає маршрут за замовчуванням.

Рішення: Використовуйте opportunistic для першого rollout. Перейдіть на yes (strict), коли перевірите сертифікати та проміжні пристрої.

Task 8 — Перезапустіть resolved і перевірте, що конфіг активний

cr0x@server:~$ sudo systemctl restart systemd-resolved
cr0x@server:~$ resolvectl status | sed -n '1,25p'
Global
       Protocols: +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Значення: +DNSOverTLS вказує, що DoT увімкнено глобально. Це не гарантує, що кожен upstream його підтримує; це означає, що клієнт спробує.

Рішення: Якщо все ще показує -DNSOverTLS, ваша конфігурація не читається або її перезаписує drop‑in. Розбирайтесь перш ніж продовжувати.

Task 9 — Підтвердіть, що запити йдуть до призначеного резолвера, а не «куди попало»

cr0x@server:~$ resolvectl query git.corp.example
git.corp.example: 10.55.8.19
               -- Information acquired via protocol DNS in 6.3ms.
               -- Data is authenticated: no

Значення: Внутрішнє ім’я резолвиться; split‑horizon збережений.

Рішення: Якщо внутрішні імена падають після увімкнення DoT, ймовірно ви спрямували їх до неправильного upstream (глобальні публічні резолвери — звичайний підозрюваний).

Task 10 — Виявлення блокування порту 853 (класика «вона таймаутить»)

cr0x@server:~$ nc -vz 10.20.30.40 853
nc: connect to 10.20.30.40 port 853 (tcp) timed out: Operation now in progress

Значення: TCP/853 недосяжний (файрвол, ACL, резолвер не слухає). Opportunistic DoT впаде до простого DNS; strict DoT зламає резолв.

Рішення: Якщо політика дозволяє DoT, відкрийте 853 до VIP резолвера. Якщо політика забороняє, не вмикайте strict DoT на клієнтах; натомість робіть шифрування всередині мережі (client→internal резолвер plain, internal резолвер→upstream зашифрований).

Task 11 — Перевірте сертифікат резолвера і SNI через OpenSSL

cr0x@server:~$ openssl s_client -connect 10.20.30.40: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

Значення: Резолвер пред’являє сертифікат, який відповідає dns.corp.example, і хост довіряє CA‑видавцю.

Рішення: Якщо валідація не проходить, не переходьте у strict DoT доти, поки не виправите поширення CA або не скоригуєте server name у DNS=.

Task 12 — Перевірте логи resolved для розуміння його рішень (воно вам скаже, якщо ви запитаєте)

cr0x@server:~$ journalctl -u systemd-resolved --since "10 min ago" --no-pager | tail -n 12
Dec 30 09:15:33 server systemd-resolved[612]: Using DNS server 10.20.30.40 for interface ens192.
Dec 30 09:15:33 server systemd-resolved[612]: Switching to DNS server 10.20.30.41 for interface ens192.
Dec 30 09:16:02 server systemd-resolved[612]: Server returned error NXDOMAIN, ignoring.
Dec 30 09:16:44 server systemd-resolved[612]: DNS-over-TLS negotiation failed with 10.20.30.40:853: Connection timed out

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

Рішення: Connection timeout → проблема мережі/порту. Verification failure → проблема PKI. NXDOMAIN → маршрутизація split DNS або неправильний вміст резолвера.

Task 13 — Замір latency та поведінки кешу (бо «зашифрований» може стати «повільним»)

cr0x@server:~$ resolvectl statistics
Transactions: 224
  Cache Hits: 141
  Cache Misses: 83
DNSSEC Verdicts: 0
DNSSEC Supported: no
DNSSEC NTA: 0

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

Рішення: Низьке співвідношення попадань у кеш + скарги на високу латентність: гарантуйте, що всі використовують 127.0.0.53, і що ви не перезапускаєте resolved постійно (так, таке трапляється).

Task 14 — Доведіть, який процес відправляє DNS, якщо підозрюєте обхід

cr0x@server:~$ sudo ss -ntup | awk '$5 ~ /:53$|:853$|:443$/ {print}'
tcp   ESTAB 0 0 10.9.1.12:45652 10.20.30.40:853 users:(("systemd-resolve",pid=612,fd=25))

Значення: DoT‑з’єднання походить від systemd-resolve, як і планувалося.

Рішення: Якщо ви бачите застосунки, що підключаються безпосередньо до публічних IP на 53/853/443, у вас є обход. Виправляйте політикою (а іноді й правилами файрволу egress).

Task 15 — Перевірте, чи DHCP/VPN не перезаписують DNS несподівано

cr0x@server:~$ nmcli dev show ens192 | sed -n '1,80p'
GENERAL.DEVICE:                         ens192
GENERAL.STATE:                          100 (connected)
IP4.DNS[1]:                             10.20.30.40
IP4.DNS[2]:                             10.20.30.41
IP4.DOMAIN[1]:                          corp.example

Значення: NetworkManager постачає корпоративні DNS‑сервери і домен. Добре. Це фундамент для split DNS.

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

Task 16 — Перевірте локальну політику файрволу (не думайте, що мережа — єдиний файрвол)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain output {
    type filter hook output priority 0; policy accept;
  }
}

Значення: Локальний файрвол не блокує вихідні 853/443. Якби блокував, ви бачили б явні дропи.

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

Контрольні списки / покроковий план (безпечний rollout)

Крок 0 — Визначте, що означає «безпечно для підприємства» у вашій організації

Чи повинні внутрішні зони резолвитися? Якщо так, клієнти мають використовувати внутрішні резолвери для цих зон.
Чи повинні DNS‑логи централізовано зберігатися? Якщо так, не обходьте внутрішні резолвери. Шифруйте client→resolver якщо можливо; інакше шифруйте resolver→upstream.
Чи є проксі у грі? Якщо так, вважайте DoH «потребує дизайн», а не «переключити на разі».
Чи потрібна строгість валідації сертифікатів? Зазвичай так. Але робіть контрольований rollout, щоб уникнути масових збоїв.

Крок 1 — Інвентаризація поточної поведінки DNS

Зберіть resolvectl status з репрезентативних хостів: у LAN, через VPN, у Wi‑Fi, в сегменті ЦОД.
Визначте, де існує split DNS: домени, умовні форвардери, поведінка на кшталт NRPT.
Підтвердьте, чи внутрішні резолвери сьогодні підтримують DoT/DoH (і чи мають вони належні сертифікати).

Крок 2 — Віддавайте перевагу «шифрувати до вашого резолвера», а не «обходити ваш резолвер»

Якщо ваші внутрішні резолвери вміють говорити DoT з валідним сертифікатом: робіть це. Це найчистіша модель для підприємств.
Якщо ні: запустіть невеликий керований рівень форвардингу (Unbound/BIND), який приймає plain DNS від клієнтів і робить зашифрований upstream всередині вашого довіреного кордону.

Крок 3 — Розгортайте спочатку opportunistic DoT з моніторингом

Увімкніть DNSOverTLS=opportunistic у пілотній групі.
Моніторинг: latency DNS, рівень помилок, CPU резолверів, кількість TCP/853 з’єднань та скарги користувачів на «повільний інтернет».
Слідкуйте за логами переговорів. Виправте досяжність і сертифікати перед переходом у strict режим.

Крок 4 — Перейдіть на strict DoT де можливо

Коли ви зможете надійно валідувати сертифікати (openssl s_client — див. вище), переходьте на strict:
це запобігає мовчанній деградації до plain, коли проміжний пристрій блокує 853.

cr0x@server:~$ sudo perl -0777 -i -pe 's/DNSOverTLS=opportunistic/DNSOverTLS=yes/g' /etc/systemd/resolved.conf
cr0x@server:~$ sudo systemctl restart systemd-resolved
cr0x@server:~$ resolvectl status | sed -n '1,12p'
Global
       Protocols: +LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported

Крок 5 — Тримайте split DNS явним

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

Крок 6 — Документуйте випадки виключень (вони трапляться)

Captive portal мережі
Сегменти ЦОД з обмеженим egress, що блокують 853/443
Системи з агентами постачальника, які хардкодять DNS
Легасі‑застосунки з власними бібліотеками резолвера

Три корпоративні міні‑історії (чому це складніше, ніж здається)

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

Середня компанія вирішила «модернізувати DNS». Добросердечний інженер припустив, що шифрований DNS — це лише покращення приватності, функціонально еквівалентне plain DNS. Вони увімкнули DoH на підмножині Debian‑лаптопів, вказавши публічного провайдера, бо він був «надійний».

Понеділок був повільним горінням. Нічого не вибухнуло одразу. Але розробники на VPN почали повідомляти, що внутрішні сервіси періодично не резолвяться. Хелпдеск побачив закономірність: користувачі, які нещодавно перезавантажилися, мали більше проблем. Ті, хто сидів без перерви впродовж вихідних, були в порядку. Така закономірність змушує підозрювати кешування, а не інфраструктуру.

Неправильне припущення було простим: «DNS — це DNS». Насправді їх внутрішні резолвери виконували split‑horizon для corp.example, повертаючи внутрішні VIP лише коли запит походив зсередини мережі або з пулу VPN‑адрес. Публчні резолвери робили те, що роблять публчні резолвери: вони або нічого не повертали, або повертали зовнішні адреси для партнерів. Деякі сервіси були доступні ззовні, але з іншими шляхами автентифікації. Хаос, але тихий.

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

Міні‑історія 2 — Оптимізація, що відсіклась боком

Інша організація хотіла зменшити latency DNS по глобальних локаціях. Хтось запропонував: «Давайте примусово направимо всі на один глобальний DoH endpoint на 443. Він пройде через кожен файрвол, а HTTP/2 перемножить запити. Швидше, правда?» Звучало модерно. Було модерно. Але наївно щодо географії і проксі.

Розгортання почалося в регіоні, де вихідний HTTPS наполегливо йшов через явний проксі з TLS‑інспекцією. DoH‑клієнт не довіряв MITM‑сертифікату проксі для цього endpoint. DNS‑запити почали затримуватися, бо система пробувала DoH спочатку, чекала, потім відкотилась. Фолбек теж блокувався, оскільки вихідний UDP/53 за політикою був заборонений (як і має бути в цій мережі).

Користувачі відчували це як «кожен сайт запускається десять секунд». Це були не сайти — це був резолвер, що таймаутиться на кожному новому hostname, поки кеші не прогріються або застосунки не повторять запити по‑іншому. Деякі застосунки справлялися; інші йшли в нестійкий стан.

Звіт після інциденту був відверто прямим: оптимізація припускала чистий інтернет‑шлях. У підприємств рідко він такий. Вони перебудували дизайн навколо внутрішніх резолверів по регіонах і використали DoT у контрольованих egress‑точках. DNS став швидшим, а безпека перестала косо дивитись на проєкт.

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

Сильно регульована організація мала правило: жодних змін DNS на клієнтах без canary‑групи, і жодного canary без автоматичного відкату. Усім це не подобалося, бо уповільнювало «прості» покращення. Потім вони спробували увімкнути strict DoT для корпоративних резолверів на Debian‑ендпоінтах.

Canary‑група загорілася за хвилини. Не тому, що DoT був зламаний скрізь, а тому, що на одному сайті ще був старий правил файрвола, який дозволяв UDP/53 до VIP резолвера, але блокував TCP/853. Opportunistic би приховав це; strict правильно впав. Користувачі в тій локації не могли нічого резолвити.

Автоматика відразу відкотила їх до opportunistic, і інцидент залишився локалізованим. Мережевики виправили файрвол, потім canary пройшов успішно, потім rollout продовжився. Ніхто не піднімався о другій ночі. Нудний процес не тільки «знизив ризик»; він перетворив гострий черепок на невеликий синяк.

Надійність часто — це відмова робити ту ж помилку скрізь одночасно.

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

1) «Внутрішні домени не резолвяться після увімкнення DoH/DoT»

Симптоми: git.corp.example NXDOMAIN або резолвиться у зовнішні IP; користувачі VPN потрапляють не туди.

Причина: Обхід внутрішніх резолверів, що обслуговують split‑horizon; глобальне перезаписування DNS ігнорує per‑link маршрутизацію.

Виправлення: Використовуйте внутрішні резолвери для ~corp.example з split DNS. Не вказуйте клієнтам прямі публічні резолвери. Перевіряйте з resolvectl status і resolvectl query.

2) «Все повільно, але не впало»

Симптоми: Сторінки та встановлення пакетів зависають перед підключенням; періодичні паузи; повтори «вирішують» проблему.

Причина: Таймаути DoH/DoT з подальшим фолбеком, часто через блокування 853, перехоплення проксі або невідповідність сертифікатів.

Виправлення: Перевірте досяжність (nc -vz ... 853), валідацію сертифікатів (openssl s_client) і логи resolved. Віддавайте перевагу strict режиму тільки коли шлях чистий; інакше ви створите латентність через таймаути.

3) «DoT strict mode ламається лише на одному сайті»

Симптоми: Працює в HQ, падає в філії; однакова image, різні мережі.

Причина: На сайті‑філії файрвол/ACL дозволяє UDP/53, але блокує TCP/853, або 853 маршрутується інакше.

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

4) «Працює по Ethernet, але падає на Wi‑Fi/captive portal»

Симптоми: На публічному Wi‑Fi не пробивається нічого, поки ви не відключите шифрований DNS; портал не з’являється.

Причина: Captive portal залежить від перехоплення DNS/HTTP; шифрований DNS перериває потік перехоплення.

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

5) «Помилки DNSSEC з’являються після ввімкнення шифрування»

Симптоми: Деякі домени падають з SERVFAIL; логи згадують DNSSEC або проблеми валідації.

Причина: Безпосередньо не через шифрування; це виявляє зміни у поведінці резолвера, обробці EDNS0 або пошкодження відповіді проміжними пристроями.

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

6) «Деякі застосунки все ще використовують plaintext DNS навіть після того, як ви «увімкнули DoT»»

Симптоми: Пакетний дамп показує UDP/53 до випадкових серверів; або застосунок резолвить навіть коли resolved зупинено.

Причина: Застосунки використовують власні резолвери (контейнери, рантайми мов, VPN‑агенти) або обходять шлях glibc resolver.

Виправлення: Аудит за допомогою ss, налаштування DNS у runtime контейнера і контроль egress. Наведіть порядок, щоб на керованих ендпоінтах був єдиний шлях резолвингу, або документуйте винятки явно.

FAQ

1) Чи слід за замовчуванням увімкнути DoH чи DoT на Debian 13 ендпоінтах?: В організаціях: за замовчуванням обирайте DoT до ваших резолверів (або вашого керованого форвардера). DoH підходить, коли ви контролюєте endpoint і історію проксі. Уникайте direct‑to‑public, якщо політика явно цього не дозволяє.
2) Який найбезпечніший початковий режим rollout?: Opportunistic DoT. Він намагається зашифрувати, але не впаде, якщо сайт блокує 853. Використайте цю фазу, щоб виявити прогалини в політиці, потім переходьте на strict там, де можливо.
3) Якщо ми вже маємо DNSSEC, чи потрібні DoT/DoH?: Так, якщо вам важлива приватність запитів і опір пасивному моніторингу. DNSSEC захищає цілісність відповідей (коли валідується), а не конфіденційність питань.
4) Чи зламає шифрований DNS split‑horizon DNS?: Не за визначенням. Обхід внутрішнього резолвера ламає split‑horizon. Шифрування транспорту до внутрішнього резолвера зберігає його.
5) Як зберегти відповідність журналювання при використанні шифрованого DNS?: Продовжуйте використовувати внутрішні резолвери, де знаходяться логування і політика. Шифруйте з кінцевого пристрою до цих резолверів (DoT) або принаймні шифруйте зв’язок резолвер→upstream. Не розпорошуйте DNS клієнтів по випадкових зовнішніх провайдерах.
6) Що з проксі та TLS‑інспекцією?: DoT зазвичай уникає проксі‑перехоплення за дизайном (це не HTTPS), але може бути заблокований egress‑правилами. DoH часто конфліктує з інспекцією, якщо клієнт не довіряє CA перехоплювача або якщо ви не виняткуєте цей трафік — це політичне, а не просте технічне питання.
7) Як довести, що ми дійсно використовуємо DoT?: Шукайте +DNSOverTLS у resolvectl status, підтвердьте TCP/853 сесії від systemd-resolve за допомогою ss, і валідуйте сертифікат резолвера через openssl s_client.
8) Чи ставити публічні fallback DNS‑сервери?: В організаціях: зазвичай ні. Фолбек на публічні резолвери може мовчки обійти внутрішні зони і логування. Якщо потрібна стійкість, запустіть декілька внутрішніх резолверів і переконайтеся, що маршрути до них працюють скрізь (LAN, VPN, філії).
9) Чи припинить шифрування DNS фільтрацію на основі DNS?: Може, якщо фільтрація спирається на перехоплення plaintext DNS у транзиті. Це може бути бажаним або порушувати політику. Підприємницька порада — робити фільтрацію на резолвері, яким ви керуєте, і шифрувати транспорт до нього.

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

Шифрований DNS на Debian 13 не складний. Робити це, не зламавши корпоративні мережі, здебільшого означає поважати те, як організації фактично використовують DNS: split‑horizon, виконання політик і передбачувану маршрутизацію.

Наступні кроки, що швидко окупаються:

Оберіть модель: endpoint→internal resolver зашифрований (найкраще), або internal resolver→upstream зашифрований (друге найкраще), і уникайте endpoint→public resolver, якщо політика цього не дозволяє.
Запустіть Швидкий план діагностики на пілотній групі і виправте нудні блокери: досяжність TCP/853, сертифікати та поведінку per‑link DNS.
Розгорніть opportunistic DoT з моніторингом, потім переходьте на strict там, де можете довести коректність шляху та PKI.
Задокументуйте обробку винятків для captive portal і проблемних VPN‑клієнтів. Вам це знадобиться.

Одна перефразована думка від W. Edwards Deming добре підходить сюди: Без даних ви просто ще одна людина з думкою. Заміряйте перед тим, як вмикати strict режим.

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

Жарт №2: Шифрований DNS не виправить вашу організаційну діаграму, але покаже, хто володіє egress‑політикою — зазвичай випадково.