Что шифруют DoH и DoT
Оба протокола решают одну задачу: защитить DNS-запросы от перехвата и подмены на пути между устройством и резолвером. По умолчанию DNS передаёт запросы открытым текстом, поэтому любой промежуточный узел — провайдер, администратор сети, точка доступа Wi-Fi — видит, какие домены вы запрашиваете, и может подменить ответ.
DNS over TLS (DoT) оборачивает стандартный DNS-трафик в TLS-соединение поверх TCP. DNS over HTTPS (DoH) упаковывает DNS-запросы внутрь обычных HTTPS-запросов. В обоих случаях содержимое запроса становится нечитаемым для наблюдателя между устройством и резолвером, а подмена ответа обнаруживается благодаря механизмам TLS.
Транспорт и порты
| Параметр | DoT | DoH |
|----------|-----|-----|
| Транспорт | TCP + TLS | HTTP, HTTP/2 или HTTP/3 поверх TLS |
| Порт | 853 | 443 |
| Стандарт | RFC 7858 | — |
| Видимость для наблюдателя | Отличим от веб-трафика | Неотличим от обычного HTTPS |
DoT использует выделенный порт 853. Это упрощает настройку и диагностику, но одновременно делает протокол легко идентифицируемым: сетевой наблюдатель или файрвол сразу видит, что трафик на порт 853 — это зашифрованный DNS.
DoH работает через порт 443 — тот же порт, что и обычный веб-трафик. Запросы DoH неотличимы от любого другого HTTPS-соединения на уровне сетевого наблюдения. Это свойство важно в сетях, где DoT блокируется или где сам факт использования зашифрованного DNS нежелателен для администратора.
Механика DoT: как устанавливается соединение
Процесс подключения по DoT включает несколько этапов:
- Сохранение отпечатка сертификата. Stub-резолвер (DNS-клиент на устройстве) хранит отпечаток TLS-сертификата резолвера — base64-кодированный SHA-256 хэш информации о публичном ключе, известный как SPKI pin (Subject Public Key Info pin). Этот отпечаток используется для проверки того, что клиент подключается именно к подлинному серверу.
- TCP-соединение. Stub-резолвер устанавливает TCP-соединение с резолвером на порт 853.
- TLS-handshake. Стороны согласуют параметры шифрования, клиент проверяет сертификат сервера. Резолвер предъявляет свой TLS-сертификат в процессе рукопожатия.
- Передача запросов. После установки TLS-туннеля все DNS-запросы передаются внутри зашифрованного соединения.
Поддерживаются TLS 1.2 и TLS 1.3. Все запросы внутри туннеля должны соответствовать спецификации DNS поверх TCP.
Диагностика DoT-соединения
Для проверки DoT-подключения можно использовать утилиту
kdig с флагами TLS:
Код:
kdig -d @1.1.1.1 +tls-ca +tls-host=one.one.one.one example.comВ выводе будет видна цепочка сертификатов, версия TLS, параметры шифрования и время ответа. Успешное соединение показывает версию TLS (например, TLS 1.3), cipher suite и статус
NOERROR — это означает, что запрос прошёл и ответ получен корректно. Строка TLS, The certificate is trusted подтверждает, что сертификат сервера проверен.Если DoT-клиент не поддерживает подключение по IP-адресу, резолвер Cloudflare доступен по hostname
one.one.one.one.Механика DoH: запрос внутри HTTPS
DoH инкапсулирует DNS-запрос в HTTP-сообщение. Клиент отправляет HTTPS-запрос к резолверу, а в теле запроса передаётся DNS-сообщение. Ответ резолвера также приходит как HTTP-ответ с DNS-данными в теле.
DoH поддерживает HTTP, HTTP/2 и HTTP/3. Благодаря использованию порта 443 и стандартного HTTPS-протокола, DoH-запросы неотличимы от обычного веб-трафика для сетевого наблюдателя.
Что видит наблюдатель
При использовании DoT
Наблюдатель видит:
- TCP-соединение на порт 853.
- Факт обращения к конкретному IP-адресу резолвера.
Наблюдатель не видит содержимое DNS-запросов и ответов — они зашифрованы внутри TLS-туннеля.
При использовании DoH
Наблюдатель видит:
- Обычное HTTPS-соединение на порт 443.
- Факт обращения к IP-адресу резолвера.
Наблюдатель не видит содержимое DNS-запросов и не может отличить DoH-трафик от посещения веб-сайта без глубокого анализа паттернов.
Что не защищают ни DoH, ни DoT
Оба протокола защищают только участок между устройством и резолвером. Они не скрывают:
- IP-адрес резолвера. Наблюдатель знает, к какому резолверу вы подключаетесь.
- Остальной сетевой трафик. DoH и DoT шифруют только DNS-запросы, а не все данные, которые передаёт устройство.
Когда DoT предпочтительнее
- Корпоративные и домашние сети с контролируемой политикой. DoT легко блокировать или разрешать на уровне файрвола по порту 853. Это удобно для администраторов, которые хотят централизованно управлять DNS-политикой.
- Простота диагностики. Выделенный порт и отдельный протокол упрощают отладку: сразу видно, что трафик на 853 — это DNS.
- Минимальные накладные расходы. DoT не несёт overhead HTTP-заголовков, что даёт чуть меньший размер пакетов по сравнению с DoH.
Когда DoH предпочтительнее
- Сети с блокировкой нестандартных портов. В публичных Wi-Fi, корпоративных прокси или цензурных средах порт 853 может быть закрыт, а 443 — открыт.
- Сокрытие факта использования зашифрованного DNS. Если наблюдатель блокирует или логирует сам факт обращения к DoT-резолверу, DoH маскирует DNS-запросы под обычный веб-трафик.
- Интеграция в браузеры. Современные браузеры реализуют DoH нативно, без необходимости настраивать отдельный stub-резолвер на уровне системы.
Ограничения приватности
Резолвер видит всё
И DoH, и DoT шифруют трафик на участке между устройством и резолвером, но сам резолвер получает полную картину DNS-запросов. Если вы используете публичный резолвер, вы доверяете ему всю историю доменных имён. Приватность в этом случае зависит от политики логирования конкретного резолвера.
DoH и DoT не заменяют VPN
VPN-туннель шифрует весь IP-трафик устройства, включая DNS-запросы. DoH и DoT защищают только DNS-слой. Если задача — скрыть всю сетевую активность от локального наблюдателя, одного зашифрованного DNS недостаточно.
WireGuard, например, инкапсулирует IP-пакеты поверх UDP и шифрует их целиком. Если DNS-запрос маршрутизируется через интерфейс WireGuard, он уже зашифрован на уровне туннеля, и дополнительный DoH или DoT не требуется для защиты от локального наблюдателя.
Типичные ошибки при настройке
| Ошибка | Последствие |
|--------|-------------|
| DoH включён только в браузере, системный резолвер не изменён | Приложения вне браузера продолжают отправлять DNS открытым текстом |
| DoT настроен, но файрвол блокирует порт 853 | DNS-запросы не проходят или переключаются на незашифрованный fallback |
| Клиент DoT не проверяет сертификат резолвера | Соединение уязвимо к подмене сервера |
Как проверить, что шифрование работает
Для DoT — использовать
kdig с флагом +tls-ca и убедиться, что в выводе присутствует строка с версией TLS и статусом NOERROR. Если в выводе видна строка TLS, The certificate is trusted — соединение установлено с проверкой сертификата.Для DoH — проверить в настройках браузера или системного резолвера, что запросы уходят по HTTPS. Косвенный признак: блокировка порта 853 не влияет на разрешение имён, а блокировка доступа к IP-адресу резолвера на порту 443 — влияет.
Итоговое сравнение
| Критерий | DoT | DoH |
|----------|-----|-----|
| Шифрование содержимого запросов | Да | Да |
| Защита от подмены ответов | Да | Да |
| Маскировка под веб-трафик | Нет | Да |
| Простота блокировки/разрешения для администратора | Высокая | Низкая |
| Нативная поддержка в браузерах | Ограниченная | Широкая |
| Накладные расходы | Минимальные | Чуть выше из-за HTTP-заголовков |
| Защита всего трафика устройства | Нет | Нет |
Выбор между DoH и DoT определяется не уровнем шифрования — он одинаков, — а контекстом сети и моделью угрозы. Если нужно защитить DNS от перехвата в доверенной сети, DoT проще и прозрачнее. Если сеть блокирует нестандартные порты или важно скрыть сам факт использования зашифрованного DNS, DoH обеспечивает лучшую маскировку. Ни один из протоколов не решает задачу приватности полностью: для защиты всего трафика нужен VPN-туннель.
