В 2026 запрос «DNS over HTTPS» уже не про «модно/немодно», а про управляемость, наблюдаемость и предсказуемые задержки. DoH и DoH3 закрывают классические проблемы приватности на линии (перехват и подмена DNS по пути), но добавляют эксплуатационные нюансы: новые транспорты, неоднозначные эффекты на latency, вопросы кэширования и конфликт с корпоративными сценариями вроде split DNS.
Ниже — практичное сравнение трёх подходов: Unbound (локальный валидирующий рекурсор), dnscrypt-proxy (локальный шифрующий прокси к доверенным резолверам) и AdGuard Home (DNS-сервер с фильтрацией и UI). Параллельно разберём, что даёт DNS over HTTP/3 (DoH3), и почему ECH меняет смысл «прятать только DNS».
Коротко о терминах: DoH, DoH3 и где здесь HTTP/3
DoH (DNS over HTTPS) — это DNS-запросы внутри HTTPS (чаще HTTP/2 или HTTP/1.1 поверх TLS). Плюс — трафик похож на «обычный веб», проще пройти через часть сетей. Минус — вы входите в экосистему HTTP со своими накладными расходами и поведенческими особенностями.
DoH3 (DNS over HTTP/3, DNS over HTTPS/3) — тот же DoH, но поверх HTTP/3 на QUIC (UDP). Отличия обычно заметны там, где есть потери/джиттер: меньше штрафов на восстановление и меньше HOL-blocking на уровне транспорта. Но QUIC может упираться в блокировки UDP или агрессивный шейпинг.
Важно: DoH3 не делает DNS «магически быстрее». Он меняет профиль задержек. В «чистых» сетях разница чаще упирается в качество апстрим-резолвера, географию и то, насколько хорошо работает локальный кэш.
Зачем вам вообще локальный резолвер в 2026
Пока многие обсуждают «какой публичный DoH выбрать», на практике больше всего выигрыша обычно дают две вещи:
- Локальный кэш с нормальными TTL и аккуратным поведением в ошибках — снижает средний latency и сглаживает пики.
- Контроль маршрутизации (split DNS, локальные зоны, исключения, политика) — чтобы офис/VPN/домашние сервисы работали стабильно и предсказуемо.
Если у вас несколько устройств, контейнеров, VM, офис и VPN — локальный компонент (Unbound / AdGuard Home / dnscrypt-proxy как прокси) становится центральной точкой контроля. И это та часть, которую реально удобно держать рядом с инфраструктурой — на сервере или на VDS, где вы контролируете сеть, логи и обновления.
Если вы строите локальный резолвер как сетевой сервис (для офиса, VPN или нескольких подсетей), удобнее держать его на отдельной машине с предсказуемыми ресурсами и доступом к логам и метрикам.
Unbound: рекурсивный резолвер, кэш и DNSSEC как база
Unbound — рекурсивный валидирующий резолвер. Его сильная сторона — вы не «переадресуете доверие» одному внешнему провайдеру DNS, а строите резолвинг через корневые и авторитативные серверы с проверкой DNSSEC. Для админа это обычно означает: меньше зависимости от конкретного публичного резолвера, сильный кэш, гибкая политика и понятная диагностика.
Где Unbound особенно хорош
- Минимизация зависимости от третьих сторон: рекурсия напрямую, а не «всё к одному DoH-эндпоинту».
- Кэш и предсказуемость: при корректной настройке кэш резко снижает среднюю задержку и сглаживает пики.
- Split DNS и локальные зоны: удобны для VPN, внутренних доменов, сервис-дискавери.
- DNSSEC: валидирование «из коробки» и прозрачная модель.
Где появляются сложности
- Холодные запросы: при пустом кэше рекурсивный резолвинг может быть медленнее, чем у больших публичных резолверов с anycast и огромным общим кэшем.
- Проблемный UDP: иногда приходится тюнинговать EDNS и fallback на TCP, следить за таймаутами и фрагментацией.
- DoH/DoH3 не «родная» роль: Unbound умеет форвардинг на защищённый апстрим, но как DoH3-«терминатор» и менеджер апстримов обычно менее удобен, чем специализированные прокси.
Рабочая схема: Unbound часто используют как «ядро» (кэш + политика), а шифрование до апстрима делают отдельным слоем (dnscrypt-proxy или AdGuard Home) — так проще обслуживать и дебажить.
Минимальный пример: Unbound как локальный резолвер для сети
Ниже — базовая заготовка, чтобы Unbound слушал локальную сеть и валидировал DNSSEC (конкретные подсети и политики подстройте под себя):
server:
interface: 0.0.0.0
interface: ::0
access-control: 127.0.0.0/8 allow
access-control: 10.0.0.0/8 allow
access-control: 192.168.0.0/16 allow
access-control: fd00::/8 allow
verbosity: 1
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
auto-trust-anchor-file: "/var/lib/unbound/root.key"
harden-glue: yes
harden-dnssec-stripped: yes
Если вам важна диагностика кэша и отказов, заранее продумайте: где хранить логи, как ограничивать их объём и как быстро видеть долю cache hit и источники SERVFAIL.
dnscrypt-proxy: шифрующий прокси и «маршрутизатор» DNS-политик
dnscrypt-proxy — локальный прокси, который отправляет запросы к апстримам через защищённые транспорты (в зависимости от версии и сборки): DNSCrypt, DoH, а поддержку DoH3 нужно проверять отдельно. Он также умеет управлять списками резолверов, балансировкой и fallback, что полезно для устойчивости.
В 2026 dnscrypt-proxy выбирают, когда нужно:
- быстро включить DoH на сервере/роутере/хосте без UI;
- получить гибкую политику выбора апстримов (несколько провайдеров, приоритеты, healthcheck);
- сделать «клей» между системой и разными режимами резолвинга, в том числе для доменных правил.
Сильные стороны
- Простая модель: слушаем локально, шлём наружу шифрованно.
- Резервирование: меньше риск «одной точки отказа» на стороне публичного резолвера.
- Гибкость: удобно строить политики «каким апстримом резолвить» без рекурсии у себя.
Подводные камни
- Зависимость от публичных резолверов: вы выбираете «кому доверять», но доверие остаётся внешним.
- Кэш: это не полноценный рекурсор; часто логичнее комбинировать с Unbound ради сильного локального кэша.
- DoH3: если нужен именно стабильный DoH3, тестируйте в своей сети (UDP/QUIC может быть проблемой).
Практичный компромисс для админских задач: dnscrypt-proxy как транспорт и выбор апстримов, а Unbound — как локальный кэширующий слой и «центр split DNS».
AdGuard Home: фильтрация, UI и удобство для семьи/офиса
AdGuard Home — DNS-сервер с панелью управления, статистикой и фильтрацией. Он закрывает задачу «хочу управляемый DNS для сети» за вечер: подняли сервис, направили клиентов через DHCP/ручные настройки, получили блокировку рекламы/трекеров, отчёты и понятные правила.
Где AdGuard Home выигрывает
- Фильтрация: списки, пользовательские правила, быстрые исключения.
- Наблюдаемость: статистика запросов, клиенты, топ-домены, диагностика «кто шумит».
- Split DNS для бытовых/малых офисных задач: доменные правила, локальные записи.
- Простота эксплуатации: меньше ручной настройки по сравнению с «чистыми» резолверами.
Ограничения и риски
- Фильтрация добавляет задержку, особенно на слабом CPU и при больших списках. Обычно это миллисекунды, но при высокой QPS может стать заметно.
- Глубина DNS-политик: это не «замена Unbound один в один» по рекурсии и тонким DNSSEC-настройкам (многое зависит от апстрима).
- Приватность: статистика полезна, но требует дисциплины по доступам и срокам хранения, особенно в рабочей сети.
Если вы публикуете сервисы наружу и у вас есть требования к доверию на уровне соединения, DNS-настройки почти всегда идут рядом с TLS. В этом месте часто логично заранее определиться с тем, какие SSL-сертификаты вы используете и как устроено продление.
Что выбрать: матрица решений под реальные сценарии
Сценарий 1: максимальная независимость и контроль (сервер/инфраструктура)
Берите Unbound как основной резолвер: рекурсия, DNSSEC, сильный локальный кэш, локальные зоны. Если политика требует «шифровать DNS до доверенного резолвера» (например, из-за требований к каналу связи), это уже другой сценарий: вы превращаете Unbound в форвардер и осознанно меняете модель доверия.
Сценарий 2: «нужно DoH/DoH3 быстро и гибко, без UI»
Чаще всего подходит dnscrypt-proxy: несколько апстримов, healthcheck, fallback, политики. Если нужен сильный локальный кэш — добавляйте Unbound как отдельный слой и считайте его «источником истины» для split DNS.
Сценарий 3: домашняя/офисная сеть, где важны фильтры, отчёты и простое управление
Берите AdGuard Home. Если позже упрётесь в качество рекурсии/кэша — вынесите рекурсор отдельно (например, Unbound) и используйте его как апстрим, сохранив UI и фильтры на входе.
Сценарий 4: split DNS (VPN, внутренние зоны, дев/прод домены)
Здесь важнее не «DoH или DoH3», а где у вас принимается решение маршрутизации. В большинстве случаев:
- Unbound удобен для локальных зон, stub-зон и чётких правил форвардинга.
- AdGuard Home удобен, если split DNS завязан на доменные правила и вам нужна панель для изменений и диагностики.
- dnscrypt-proxy полезен, если split DNS — это прежде всего «каким апстримом резолвить», а не «поднимать свои зоны».
Latency: что реально влияет на задержку DNS в 2026
В спорах «DoH быстрее/медленнее» важно помнить: общая задержка складывается из нескольких частей.
- Локальная обработка (фильтры, правила, логирование).
- Попадание в кэш (ваш локальный и/или кэш апстрима).
- Доставка до апстрима (RTT, потери, джиттер).
- Холодный резолвинг: сколько внешних шагов нужно для ответа (NS, DS/DNSKEY, CNAME-цепочки).
DoH3 может уменьшать штрафы на потерях и ускорять восстановление после разрывов, но если у вас сильный локальный кэш, разница между DoH и DoH3 для «типичного пользователя» часто будет меньше, чем влияние фильтров или качества апстрима.
Как тестировать, чтобы не самообмануться
- Прогревайте кэш и отдельно измеряйте «холодные» запросы (после очистки кэша или новым именем).
- Измеряйте несколько доменов: короткие A/AAAA, домены с CNAME-цепочками, домены с DNSSEC.
- Смотрите не только среднее, но и p95/p99: DoH3 часто выигрывает именно хвостами в «грязной» сети.
Privacy: что DoH/DoH3 скрывает, а что — нет
DoH и DoH3 скрывают содержимое DNS от наблюдателя между вами и резолвером. Но они не скрывают сам факт соединения с конкретным резолвером и метаданные уровня IP/порт/тайминги. Также остаются типовые утечки:
- Приложения с собственным резолвингом (часть браузеров и клиентов может включать DoH независимо от системных настроек).
- Fallback на системный DNS при ошибках или таймаутах апстрима.
- Разные интерфейсы (VPN/не VPN), если split DNS настроен нестрого.
- TLS-метаданные (в частности SNI) — и тут мы выходим на ECH.
ECH в 2026: почему «прятать DNS» без ECH уже не панацея
ECH (Encrypted ClientHello) шифрует часть TLS-рукопожатия, включая SNI, чтобы наблюдатель не видел, к какому домену вы подключаетесь, даже если трафик HTTPS. Исторически многие начинали «улучшать приватность» с DNS (DoH/DoT), но без ECH домен всё равно часто «светился» в SNI.
Практическая картина в 2026 такая:
- ECH становится доступнее в клиентах и у провайдеров, но повсеместность зависит от инфраструктуры и CDN.
- ECH завязан на DNS-записи типа SVCB/HTTPS: DNS становится частью цепочки «включения» приватности.
- Даже с ECH остаются метаданные уровня IP назначения, поэтому ожидания нужно калибровать.
DoH/DoH3 — про защиту DNS на пути и управляемость. ECH — про сокращение утечек доменных метаданных в TLS. Максимальный эффект получается, когда оба слоя настроены согласованно и вы контролируете обходы (особенно при split DNS).
Рекомендуемые архитектуры (без религиозных войн)
Вариант A: Unbound как ядро + шифрование до апстрима (при необходимости)
Локальная рекурсия и кэш, DNSSEC, локальные зоны. Если политика требует шифровать DNS «до доверенного резолвера», Unbound можно использовать как форвардер на локальный прокси. Но учитывайте: при таком подходе вы сознательно отказываетесь от части преимуществ прямой рекурсии.
Вариант B: dnscrypt-proxy как транспорт/политика + Unbound как кэширующий слой
Unbound даёт кэш, локальные зоны и предсказуемую диагностику. dnscrypt-proxy даёт выбор апстримов и защищённый транспорт (DoH, а DoH3 — если поддерживается и проходит в вашей сети). Такой стек часто удобен на сервере/шлюзе.
Вариант C: AdGuard Home для сети + отдельный резолвер апстримом
AdGuard Home обслуживает клиентов, делает фильтрацию и UI. Апстримом ставите либо Unbound (кэш/политики), либо dnscrypt-proxy (DoH/DoH3 и выбор провайдера). Это популярный компромисс «удобство + контроль».
Split DNS: типовые ошибки, которые ломают всё
- Пересечение доменных правил: одно имя попадает под разные политики и ведёт себя непредсказуемо.
- TTL и кэш: вы изменили внутреннюю запись, а клиенты продолжают жить на старом ответе.
- Локальные домены без зоны: «просто A-запись в hosts на части машин» потом невозможно сопровождать.
- DNS через VPN, а DoH мимо VPN: типичная утечка политики, когда клиентский DoH уходит в «обычный интернет».
Если split DNS критичен, выбирайте инструмент, который умеет быть «центром принятия решений» и прозрачно диагностируется (логи, статистика, понятные правила).
Наблюдаемость и эксплуатация: что важно для админа
Для продакшена и даже небольшой сети важны не только протоколы, но и операционные свойства:
- Метрики и логи: QPS, доля кэша, причины отказов (NXDOMAIN/SERVFAIL), таймауты апстрима.
- Контроль роста: ограничения по памяти кэша, размер логов, срок хранения статистики.
- План отказа: что происходит при недоступности апстрима, есть ли fallback, не утекает ли DNS «в обход».
- Обновления: DoH3/QUIC и ECH быстро развиваются; важно не застревать на старых версиях.
Если DNS — часть публичного контура (например, вы обслуживаете домены и интеграции), полезно заранее выстроить процессы вокруг доменной зоны и управления изменениями. По теме защиты домена от ошибок и злоупотреблений пригодится материал про защиту бренда и домена, а если вы часто автоматизируете выпуск сертификатов — про автоматизацию DNS-01 для wildcard SSL.
Итоги: Unbound vs dnscrypt-proxy vs AdGuard Home в 2026
- Unbound — выбор, если нужен сильный локальный кэш, DNSSEC и независимость. DoH/DoH3 здесь чаще выступают как дополнительный транспорт (через форвардинг), а не как цель.
- dnscrypt-proxy — выбор, если нужен управляемый защищённый апстрим (DoH и варианты) и гибкая политика резолверов с резервированием.
- AdGuard Home — выбор для сетей, где нужна фильтрация, UI, простое администрирование и понятная статистика; DoH/DoH3 — как часть апстрима.
ECH в этой картине — напоминание, что приватность это цепочка. DoH/DoH3 закрывает DNS на пути, ECH закрывает часть TLS-метаданных, а итоговый эффект зависит от согласованной настройки клиентов, резолвера и сетевой политики (особенно при split DNS).
