DoH настройка: где DNS-запросы уходят наружу открытым текстом
Разрешение имён — самый незаметный канал утечки в корпоративной сети. Рабочая станция по умолчанию отправляет запрос открытым текстом на 53-й порт — он уходит за периметр раньше, чем устанавливается защищённая сессия с сайтом. Внутри зашифрованного соединения наблюдатель видит только домен, а открытый DNS-трафик отдаёт весь список имён, к которым обращался сотрудник.
Что именно достаётся наблюдателю на канале: провайдеру, транзитному оператору, точке доступа в коворкинге или гостинице. По последовательности запросов восстанавливается карта инфраструктуры — внутренние сервисы, системы мониторинга, файловые хранилища, сервисы подрядчиков. Время и частота запросов выдают график работы, распределение по подразделениям и моменты активности проектов.
Отдельный класс — перехват ответов распознавания имён. Наблюдатель успевает подменить ответ распознавания раньше легитимного, и резолвер кладёт подложенную запись в кэш. Дальше сотрудник попадает на копию страницы входа либо на пустой ответ. Подпись зоны (DNSSEC) закрывает часть случаев, но не работает там, где зона её не публикует.
DoH настройка начинается не с клиента, а с политики исходящего трафика. 53-й порт закрывается для всех, кроме внутренних резолверов, а рабочие станции и серверы выходят наружу только через закреплённый набор адресов DoH и DoT. Тогда утечка DNS-запросов закрывается, ответы приходят только от доверенного резолвера, а сам канал становится управляемым и наблюдаемым. Разбираем, как это разворачивается на практике.
Что даёт шифрование DNS: приватность, контроль, устойчивость
Без шифрования каждый запрос на разрешение имени уходит открытым текстом: посредник на маршруте видит и само имя, и адрес источника, а по последовательности запросов восстанавливает поведение устройства и его владельца. DoH упаковывает запрос в обычный защищённый веб-сеанс, DoT — в выделенный канал на отдельном порту, и для внешнего наблюдателя остаётся только адрес резолвера и объём трафика. Приватность распознавания имён перестаёт быть декларацией и становится свойством транспорта.
Второй эффект — доля подменённых ответов. Перехваченный запрос дешево вернуть с подставного адреса, и до появления шифрования это происходило незаметно для клиента. Шифрование транспорта в связке с проверкой подписи на резолвере убирает класс атак целиком: запрос нельзя прочитать и подменить по пути, а ответ без валидной подписи отбрасывается. В журналах резолвера остаются попытки вмешательства, а доля ответов, не прошедших проверку, падает до нуля.
Контроль исходящих запросов появляется как побочный, но самый практичный результат. Пока клиент может обратиться к любому публичному резолверу — например, к Cloudflare — корпоративная фильтрация обходится одним переключением в настройках сети на устройстве. Правило на периметре закрывает это: прямой DNS наружу запрещён, разрешены только корпоративные точки DoH/DoT, и тогда все имена видны в одном журнале, а политики применяются централизованно, а не по принципу «у кого как настроено».
Устойчивость канала имён — третий измеримый эффект. Смена резолвера перестаёт быть правкой на каждом устройстве: это изменение адреса точки в конфигурации, которое разъезжается по паркам за один цикл обновления. Постоянные сессии и кэш на клиенте и на резолвере держат задержку разрешения на прежнем уровне, а переключение между несколькими точками при отказе одной проходит без участия пользователя. Итог измеряется тремя показателями: видимость имён для внешнего наблюдателя, доля подменённых ответов и доля запросов, прошедших корпоративные политики.
Сравнение режимов: DoH, DoT, локальный резолвер и гибрид
Выбор режима определяется не уровнем «безопасности», а тем, какие каналы доступны у клиентов, где живут внутренние зоны и как быстро нужно вернуться в рабочее состояние при сбое. На одном предприятии обычно сосуществуют все четыре схемы: офисный парк, удалённые сотрудники, гостевой доступ и внутренние сервисные записи ведут себя по-разному, и одна политика на всех ломается на первом же ограничении.
Ниже — рабочая матрица: вариант, условия применимости и то, чем он ограничивает сопровождение.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Шифрование поверх веб-протокола | Публичные и гостевые сети, где разрешён только обычный веб-трафик; браузеры и мобильные устройства | Трафик неотличим от обычного, поэтому фильтрация и разбор на периметре настраиваются отдельно; часть приложений игнорирует системные параметры |
| Выделенный шифрованный канал имён | Управляемый парк, где нужен предсказуемый канал и понятная точка отказа | Отдельный порт легко блокируется в партнёрских и гостевых сетях, требуется открытый исходящий доступ |
| Локальный резолвер | Внутренние зоны, сервисные записи, запросы, чувствительные к задержке; когда наружу уходит один узел | Участок «клиент — резолвер» остаётся открытым; отказоустойчивость и масштабирование ложатся на инфраструктуру |
| Гибридная схема | Смешанный парк: офис, удалённые сотрудники, гости, отдельные приложения со своими настройками | Две политики и два контура мониторинга; порядок отката приходится описывать заранее, иначе расхождение конфигураций копится |
Практический вывод: режим по умолчанию закрепляют за большинством клиентов, а остальные схемы включают точечно — под конкретные зоны или группы устройств. Перед переключением проверяем совместимость с текущими фильтрами, внутренними зонами и сценарием возврата на прежние настройки, чтобы сбой одного узла не оставлял парк без разрешения имён.
DoH настройка: этапы внедрения в корпоративной сети
Порядок работ здесь задаёт не удобство настройки, а то, что шифрование переносит точку, где видно содержимое запроса. Если сначала включить DoH на клиентах, сеть теряет видимость распознавания имён, а фильтрация и журналы перестают сходиться между собой. Поэтому этапы идут от инвентаризации к передаче в эксплуатацию, и на каждом есть свой критерий готовности.
- Аудит схемы распознавания. Собираем перечень резолверов, локальных зон, статических записей в конфигурациях и приложений, которые уже ходят шифрованными запросами в обход корпоративного пути. Результат — карта запросов с указанием инициатора и того, какой сегмент куда обращается.
- Проектирование схемы. Определяем, где остаётся единая точка выхода, а куда идёт резервный путь. Для управляемых устройств обычно подходит DoT, для роуминга — DoH поверх стандартного защищённого порта, который пропускают почти все гостевые сети.
- Настройка шифрованного канала. Профили на резолверах и клиентах, доверенные сертификаты, проверка имени сервера, отключение незашифрованного резервного запроса либо явное правило, когда он допускается.
- Закрытие обхода. Блокируем сторонние шифрованные точки на периметре — иначе политика фильтрации обходится сменой одной настройки в браузере.
- Проверка после внедрения. Разрешение имён во всех сегментах, добавленная задержка, поведение при недоступности резолвера, полнота журналов и корреляция событий.
- Передача в эксплуатацию. Регламент обновления сертификатов, оповещения, инструкция по откату на предыдущую схему, обучение дежурной смены.
Конфигурации, схемы и регламенты: что остаётся на руках
Смысл передачи — в том, чтобы через день после завершения работ схему можно было менять без нас. Поэтому в комплект входят не только настроенные узлы, но и всё, что описывает их поведение: файлы конфигурации в репозитории, топология, правила и порядок согласования правок. Ниже — перечень артефактов, которые остаются у вашей команды.
- Конфигурации узлов — рабочие профили резолверов и шлюзов DoH/DoT, шаблоны под разные площадки, параметры кеша и правила выпуска сертификатов с автоматическим продлением.
- Схема сети — топология с точками перехвата и выхода запросов, адресация слушателей, маршруты до вышестоящих резолверов и порядок деградации при отказе одного из них.
- Регламент изменений — кто и как правит конфигурацию, обязательный прогон проверок, окна работ, порядок возврата на предыдущую ревизию и критерии успешной правки.
- Политики доступа — какие команды и сервисы обращаются к узлам, по каким признакам различаются внутренние и внешние клиенты, как выдаются и отзываются учётные данные.
- Документация инфраструктуры — описание компонентов, зависимостей и точек отказа, инструкции по типовым операциям: добавление площадки, смена сертификата, вывод узла из эксплуатации.
- Мониторинг и оповещения — метрики по задержке ответа, доле отказов и попаданиям в кеш, пороги срабатывания и список сигналов, требующих вмешательства дежурного.
- Процедура поэтапного отката — как за минуты вернуть клиентов на прежний способ разрешения имён, не потеряв доступность и не разослав испорченный кеш.
Кейс: перевод офисной сети на шифрованный DNS
Что было до проекта
Запросы имён из офисной сети уходили наружу открытым текстом: их читал любой узел на пути, а ответ можно было незаметно подменить. За квартал зафиксировали несколько подтверждённых случаев — сотрудники попадали на подставные страницы авторизации, а разбор каждого инцидента занимал часы: сначала доказать саму подмену, потом найти затронутые сегменты. Доля незашифрованных запросов составляла 100%, восстановление после сбоя разрешения имён — до нескольких часов силами дежурной смены.
Что изменили
Шифрование развернули в два слоя: на рабочих станциях — системными политиками и настройками браузеров, на резолверах подразделений — на транспортном уровне. Основным сделали Cloudflare, резервный резолвер независимый, с автоматическим переключением при недоступности основного. Раскатка шла поэтапно: пилотный сегмент, неделя наблюдения за метриками, затем остальные офисы — так сбой на одном участке не превращался в общий.
Результат
Доля открытых запросов упала со 100% до 2-3% — остались устройства без поддержки шифрования, вынесенные в отдельный сегмент с ограниченным доступом. Подтверждённых инцидентов с подменой ответов после перевода нет, а незашифрованный запрос теперь автоматически считается поводом для разбора, а не фоном. Время восстановления при отказе основного узла сократилось с нескольких часов до минут: переключение происходит без участия дежурного, а старые записи продолжают отдаваться из локального кеша, пока резервный резолвер не войдёт в работу.
Чем DoH отличается от DoT и когда достаточно одного
Разница не в стойкости шифрования, а в том, как трафик выглядит для того, кто смотрит на периметр. DoH упаковывает запросы внутрь обычной защищённой веб-сессии, поэтому снаружи они неотличимы от загрузки страницы — их сложно выборочно блокировать, но так же сложно учитывать в правилах. DoT идёт по отдельному защищённому каналу на своём порту: трафик виден как отдельный сервис, зато предсказуемо разрешается, ограничивается по адресам и попадает в журналы как самостоятельный поток. Отсюда и практическое правило выбора режима шифрования — по сценарию, а не по «лучше/хуже».
На рабочих станциях решает не протокол, а то, кто управляет настройкой. Современные браузеры умеют включать DoH сами, и тогда запросы уходят мимо корпоративного резолвера: внутренние имена перестают разрешаться, а картина обращений распадается. Рабочая схема — отключить встроенный режим политикой и направить машины на свой узел, который уже шифрует трафик наружу.
В серверном сегменте обычно достаточно DoT. Соединения там долгоживущие, нагрузка предсказуемая, а администратору важно видеть, какой узел куда обращается: отдельный канал проще привязать к внутреннему резолверу и закрыть на периметре. DoH здесь оправдан, если сервис выходит наружу через обратный прокси и вы не хотите открывать лишний порт.
Мобильные устройства и гостевые сети дают обратную картину. Телефоны и ноутбуки поддерживают оба режима через штатные профили, но при переходе между сетями защищённая сессия переустанавливается, и DoT это переживает тяжелее — заметны паузы при первом запросе после переключения. В гостевых сетях логичнее DoH: он не требует публиковать отдельный порт наружу, а гостевой трафик остаётся в общем веб-потоке. На практике почти всегда получается гибрид: DoT внутри периметра, DoH для браузеров и гостевых сегментов, и явная политика, запрещающая клиентам выбирать резолвер самостоятельно.
Совместимость, откат и проверка: технические сомнения
Прежде чем включать шифрование на весь парк, технические команды проверяют три вещи: как оно уживается с фильтрацией, что происходит при откате и как убедиться, что трафик действительно зашифрован. Ниже — ответы на сомнения, которые чаще всего всплывают на согласовании.
Не сломает ли DoH существующую фильтрацию трафика?
Нет, пока политика остаётся на внутреннем резолвере: клиент шифрует только участок до него, а категории и чёрные списки работают как раньше. Схема ломается там, где приложения обходят корпоративный резолвер и уходят на внешний — такие случаи закрываем правилами на периметре.
Что делать с внутренними зонами?
Внутренние имена должны разрешаться только через корпоративный резолвер, иначе часть сервисов просто перестанет открываться. Проверяем это отдельным набором тестов до раскатки на всех.
Как откатываются изменения?
Порядок отката фиксируется заранее: клиентские профили возвращаются на прежние адреса резолверов, правила на периметре снимаются, конфигурация откатывается к предыдущей версии. Тот же сценарий проигрываем на пилотной группе.
Можно ли включить частичное шифрование?
Да, раскатка идёт по группам устройств и площадкам — начинаем с подразделения, где проще собрать обратную связь. При проблемах группа возвращается в прежний режим, остальные продолжают работать.
Как проверить, что шифрование реально работает?
Смотрим на исходящий трафик: незашифрованные запросы наружу должны исчезнуть, а ответы приходить от корпоративного резолвера. Дополнительно сверяем журналы резолвера и тестовые домены.
Обсудим задачу: какие данные нужны для оценки и плана
Чтобы оценка и план работ появились после одного разговора, а не трёх итераций уточнений, нам нужен срез инфраструктуры. Чем точнее исходные данные, тем меньше допущений в проекте и тем предсказуемее сроки раскатки шифрования запросов.
- Перечень сегментов и площадок: офисы, филиалы, удалённые подключения сотрудников, гостевые сети, серверные — по каждому важно понимать, кто и как выходит в интернет.
- Текущая схема распознавания: какие резолверы используются внутри, куда обращаются клиентские устройства, есть ли локальные кэширующие серверы и как они получают ответы.
- Требования к журналированию: что нужно фиксировать (источник, время, домен, вердикт политики), сколько хранить и у кого есть доступ к выгрузкам.
- Правила фильтрации сегодня: списки и категории, кто их ведёт, как часто они меняются и что обязательно должно сохраниться после перехода.
- Инвентарь клиентов под раскатку: операционные системы, мобильные устройства, оборудование филиалов, автоматизированные системы и сервисные учётные записи.
- Порядок управления доступом: как выдаются права на изменение сетевых настроек, есть ли отдельный контур и кто согласует правки.
- Ограничения и окна работ: внутренние требования безопасности, отраслевые нормы и периоды, когда допустимо менять маршрут запросов.
Этого набора достаточно, чтобы вернуться с оценкой и планом: пилотный сегмент, последовательность раскатки, точки отката и метрики, по которым будем проверять результат. Если часть данных недоступна — опишите, что есть, остальное соберём вместе.
