Нидерландах от 390р
DNS — один из самых «шумных» протоколов в инфраструктуре: он нужен браузеру, пакетному менеджеру, почте, мониторингу, почти всему. Исторически классический DNS по UDP/53 не шифруется, поэтому запросы и ответы можно подсмотреть, попытаться подменить или просто использовать как источник метаданных.
Отсюда и популярность шифрованных вариантов: DNS over TLS (DoT) и DNS over HTTPS (DoH). Оба решают схожую задачу, но с разной ценой для эксплуатации и политик.
Ниже — практический разбор: как устроены DoH/DoT, где они реально повышают приватность, где мешают администрированию, и что выбирать в сценариях «дом/офис», корпоративная сеть, серверы и инфраструктура на VDS.
Зачем вообще шифровать DNS
DNS отвечает на простой вопрос «имя → IP», но по факту раскрывает много косвенной информации. Даже если весь веб-трафик у вас по HTTPS, наблюдатель на пути может видеть домены, которые резолвятся, и делать выводы о сервисах и поведении пользователя.
- Приватность: список доменов часто коррелирует с посещаемыми сайтами и используемыми приложениями.
- Целостность: в небезопасных сетях возможны попытки подмены ответов (вплоть до фишинга и редиректов).
- Управляемость: «сломавшийся DNS» выглядит как «сломался интернет», а без ясной картины диагностика затягивается.
Шифрованные варианты закрывают два класса рисков: усложняют пассивное наблюдение и резко усложняют подмену «по дороге». Но они не превращают DNS в анонимность: доверие просто переносится на резолвер, который теперь видит ваши запросы вместо провайдера/точки Wi‑Fi.
DoH/DoT защищают участок клиент↔резолвер. Сам резолвер всё равно видит домены и метаданные, а сайты и сервисы всё равно видят IP клиента и прикладной трафик.
DoT: DNS поверх TLS — как работает и что важно знать
DoT — это DNS внутри TLS-сессии. Обычно используется отдельный порт 853/tcp. Клиент устанавливает TLS-соединение к резолверу и дальше обменивается стандартными DNS-сообщениями внутри шифрованного канала.
Плюсы DoT
- Отделимость на сети: DoT легче идентифицировать и контролировать на периметре (порт, ACL, политики).
- Предсказуемость для админов: проще разрешить DoT только к «правильным» резолверам или запретить полностью.
- Прозрачная диагностика: видно отдельный канал «DNS в TLS», меньше сюрпризов в наблюдаемости.
Минусы DoT
- Часто режется на чужих сетях:
853/tcpнередко блокируют, и без запасного плана резолвинг ломается. - Плохая «маскировка»: DoT не выглядит как обычный веб, поэтому в жёстко ограниченных средах проходит хуже.
Если DoT нужен на серверах и вы хотите предсказуемый контроль резолвинга, проще всего начать с отдельной инфраструктуры и тестов на одном узле, а затем раскатывать на остальные. Для таких задач часто выбирают отдельный контур на VDS, чтобы изолировать эксперименты от продакшн-сети.
Россия
Нидерланды
DoH: DNS поверх HTTPS — почему он вызывает споры
DoH упаковывает DNS в HTTPS (обычно 443/tcp). Для сети это обычный веб-трафик, а DNS-сообщения передаются внутри HTTP-запросов (часто с типом application/dns-message). Именно «похожесть на веб» и делает DoH максимально живучим в фильтруемых сетях.
Плюсы DoH
- Высокая проходимость: там, где открыт только
443, DoH часто работает, а DoT — нет. - Удобство для приложений: некоторые клиенты (особенно браузеры) могут использовать DoH независимо от системного резолвера.
- Сложнее пассивно классифицировать: без расшифровки TLS неочевидно, что внутри HTTPS идёт DNS.
Минусы DoH
- Сложнее корпоративный контроль: DNS «прячется» в веб-трафик, и привычные DNS-политики (split-DNS, внутренние зоны, блоклисты) могут обходиться.
- Диагностика тяжелее: проблемы выглядят как HTTPS-проблемы (TLS-ошибки, прокси, DPI, блокировки по SNI/ALPN и т.д.).
- Риск фрагментации: часть системы резолвит через один путь, браузер — через другой, и вы ловите «неповторяемые» баги.
DoH vs DoT: сравнение по критериям, важным в эксплуатации
Управляемость и политики
Если вам важно централизованно управлять DNS (внутренние зоны, split-horizon, аудит, фильтрация), DoT обычно проще: его легче выделить и ограничить на периметре. DoH потребует контроля на уровне приложений и/или списка разрешённых DoH-endpoint’ов.
Совместимость в жёстких сетях
В гостевых сетях, отелях и средах «разрешён только веб» чаще выигрывает DoH. DoT в таких местах может просто не подняться из-за блокировки порта 853.
Наблюдаемость и диагностика
DoT проще отлаживать как отдельный класс трафика: есть подключение по 853/tcp и TLS до резолвера. DoH превращает DNS в частный случай HTTPS: дополнительно всплывают нюансы прокси, HTTP/2, HTTP/3, политик инспекции трафика.
Перенос доверия и «privacy dns»
По смыслу «privacy dns» обычно означает: «чтобы провайдер/точка доступа не видели домены». И DoH, и DoT дают сопоставимый эффект, если не происходит отката в обычный DNS и клиент действительно использует выбранный резолвер.
При этом ключевой вопрос остаётся тем же: кому вы доверяете вместо провайдера. Резолвер видит запросы и метаданные (IP, время, частоту). Поэтому в компаниях часто выбирают не «публичный резолвер где-то в интернете», а свой резолвер (или доверенного провайдера) с понятной политикой логирования и сроками хранения.
Где DoH/DoT помогают, а где создают проблемы
Домашняя сеть и публичный Wi‑Fi
Для защиты от подмены и «подглядывания» DNS в кафе/гостинице подходят оба варианта. На практике DoH чаще «пробивается», но если вы настраиваете всё централизованно на роутере/шлюзе и хотите управляемости, DoT нередко удобнее.
Офис, VPN, split-horizon и внутренние зоны
В корпоративной сети типичная проблема — внутренние домены и зоны, доступные только через VPN. Если рабочая станция уходит в публичный DoH, она может перестать видеть внутренние имена или получать «не те» ответы. Это ломает SSO, панели мониторинга, сервис-дискавери, внутренние API.
Практическое правило: корпоративный DNS должен оставаться управляемым. То есть нужен локальный резолвер, контроль того, что умеют браузеры/клиенты, и документированное поведение при сбоях.
Серверы, CI/CD и инфраструктура на VDS
На серверах приватность DNS обычно вторична относительно доступности и предсказуемости. Но DoT/DoH полезны, когда вы хотите защититься от вмешательства «на пути» или унифицировать резолвинг между узлами.
Часто лучший компромисс для серверов — поднять локальный кеширующий резолвер и уже его отправлять вверх по DoT/DoH. Так уменьшаются задержки, упрощается контроль и не появляется «зоопарк» настроек на каждом приложении.
Типовые архитектуры внедрения без сюрпризов
1) Клиент → публичный DoH/DoT
Минимум инфраструктуры и быстрый старт. Минусы: минимум контроля, возможны конфликты с внутренними зонами и политиками, сложнее аудит.
2) Клиент → локальный резолвер → DoT/DoH upstream
Самый админский вариант: клиенты ходят в ваш резолвер (обычно по обычному DNS внутри доверенной сети), а резолвер общается с внешним миром шифрованно. Так вы управляете кешем, логами, блокировками и split-horizon.
3) Браузерный DoH отдельно от системного DNS
Опасный режим для корпоративных сетей: появляется два «мира» резолвинга. В результате ошибки могут воспроизводиться только в браузере или только в системных утилитах, что сильно усложняет поддержку.
Если вы поднимаете собственный DoH/DoT-endpoint для пользователей или филиалов, не забывайте про TLS и жизненный цикл сертификатов: истекший сертификат превращает «приватный DNS» в внезапные отказы резолвинга. Для таких задач обычно заранее планируют закупку и ротацию SSL-сертификаты.
Минимальный набор проверок и команд для диагностики
Ниже — общий подход, который помогает быстро понять, где именно ломается резолвинг: «доступность порта», «TLS», «нет ли отката в обычный DNS».
Проверить, доступен ли DoT (порт 853)
nc -vz 1.1.1.1 853
nc -vz 8.8.8.8 853Проверить TLS-рукопожатие до DoT-резолвера
openssl s_client -connect 1.1.1.1:853 -servername cloudflare-dns.comЕсли TLS не сходится из-за времени, цепочки или перехвата, DoT обычно просто не поднимется (и важно заранее знать, будет ли fallback).
Быстрая проверка DoH HTTP-ответа (без привязки к конкретной реализации)
DoH — это HTTPS до endpoint’а. Если у вас проблемы с корпоративным прокси/фильтрацией, иногда достаточно понять, что HTTPS до endpoint’а в принципе не открывается.
curl -I doh.exampleЗамените doh.example на домен вашего DoH-endpoint’а (в корпоративной схеме это обычно ваш домен, а не публичный сервис). Если вы используете собственный домен под DoH/DoT, заранее продумайте его защиту и управление жизненным циклом: пригодится материал про защиту домена и бренда.
Частые ошибки при внедрении
Ошибка: считать, что DoH/DoT заменяют DNSSEC
DoH/DoT шифруют транспорт на участке клиент↔резолвер. DNSSEC отвечает за криптографическую целостность данных зоны «от владельца зоны». Это разные уровни, и в идеале они дополняют друг друга.
Ошибка: не продумать fallback и поведение при сбоях
Если DoH/DoT недоступен (блокировка, сбой, неверное время на машине, проблемы TLS), что делает клиент: молча уходит в обычный DNS или перестаёт резолвить? Это должно быть заранее определено и одинаково во всей инфраструктуре.
Ошибка: включить DoH в браузере внутри корпоративной сети
Типичный эффект: внутренние домены не открываются, порталы мониторинга недоступны, SSO ломается, а пользователь говорит «интернет есть». Лечится политиками управления браузером и правильной корпоративной схемой резолвинга.
Практические критерии выбора: DoH или DoT
- Нужен контроль на периметре и единые политики? Выбирайте DoT или схему «локальный резолвер → DoT/DoH upstream».
- Сеть часто блокирует нестандартные порты? DoH обычно живучее.
- Есть split-horizon и внутренние зоны? Не допускайте «самовольный» DoH наружу, иначе получите труднообъяснимые инциденты.
- Важна диагностика и наблюдаемость? DoT проще как отдельный слой; DoH потребует смотреть на HTTPS-цепочку.
- Важны требования к логам и соответствию политикам? Сначала определите, что логируется и сколько хранится, а уже потом выбирайте протокол.
Итог
DoT и DoH решают одну задачу — шифруют DNS-трафик — но по-разному влияют на управляемость и диагностику. Для инфраструктуры и корпоративных сетей чаще выигрывает DoT или вариант с локальным резолвером (а DoT/DoH используются только «вверх»). Для гостевых и ограниченных сетей, где открыт только веб, практичнее часто оказывается DoH.
Выбирайте не «религию», а сценарий: где важнее пройти ограничения, а где важнее контроль, внутренние зоны и предсказуемая эксплуатация.
