Оба протокола шифруют DNS-запросы, но делают это по-разному: разные порты, разная маскировка в общем трафике и разная поддержка в браузерах и ОС. Разбираем разницу между DNS-over-HTTPS и DNS-over-TLS и даём чёткий ответ, что выбрать в 2026 году.
Каждый раз, когда вы открываете сайт, устройство отправляет DNS-запрос — «переводит» доменное имя вроде example.com в IP-адрес. По умолчанию этот запрос уходит в открытом виде по протоколу UDP на порт 53 — без шифрования, любой узел на пути между вами и DNS-сервером может его прочитать.
Из-за этого даже HTTPS-соединение не спасает от полной прозрачности: провайдер всё равно видит доменные имена в каждом вашем запросе — это фактический журнал сайтов, которые вы посещаете. DoH и DoT решают именно эту проблему, оборачивая DNS-запрос в шифрование, но выбирают для этого разный транспорт.
DNS-over-HTTPS (RFC 8484) отправляет DNS-запросы внутри обычного HTTPS-соединения на порту 443. С точки зрения сети это неотличимо от любого другого веб-запроса: браузер и так постоянно ходит на порт 443, и DNS-запрос растворяется в общем HTTPS-трафике.
Пример прямого DoH-запроса через curl (формат JSON, поддерживаемый Cloudflare и Google):
curl -s -H 'accept: application/dns-json' \
'https://cloudflare-dns.com/dns-query?name=example.com&type=A'DNS-over-TLS (RFC 7858) решает ту же задачу похожим способом, но использует отдельный, выделенный порт — 853. DNS-запрос оборачивается в собственный TLS-туннель, не смешиваясь с остальным трафиком устройства.
Зато DoT чаще настраивается на уровне всей операционной системы или роутера: один раз включив его, вы защищаете DNS-запросы сразу всех приложений на устройстве, а не только браузера. На Android это встроенная функция — «Частный DNS» (доступна начиная с Android 9).
| Параметр | DoH | DoT |
|---|---|---|
| Порт | 443 — общий с HTTPS | 853 — выделенный |
| Маскировка в HTTPS-трафике | Полная: неотличим от обычного веб-сёрфинга | Отсутствует: виден как отдельный DNS-протокол |
| Поддержка браузерами/ОС | Firefox, Chrome, Edge — нативный тумблер; Safari/iOS/macOS и Windows 11 — через профиль/системные настройки | Android — нативно («Частный DNS»); в браузерах почти не встроен |
| Производительность | Немного выше нагрузка на CPU из-за обёртки HTTP/2 | Минимальный оверхед, чуть быстрее хендшейк |
| Приватность от наблюдателя в сети | Высокая — сам запрос не отличить от прочего HTTPS | Высокая по содержимому, но факт использования DoT виден по порту |
вы настраиваете приватность на уровне браузера, хотите включить всё в пару кликов и не готовы трогать системные настройки. Это выбор по умолчанию для большинства пользователей.
нужно защитить DNS-запросы всех приложений на устройстве разом, а не только браузера. На Android это одна системная настройка вместо конфигурации каждого приложения отдельно.
Комбинировать оба протокола одновременно не имеет смысла — они решают одну и ту же задачу разными способами. Выбирайте один вариант в зависимости от того, что хотите защитить: отдельный браузер или всё устройство целиком.
Проверить, действительно ли ваши DNS-запросы уходят зашифрованными, можно сервисом 1.1.1.1/help от Cloudflare — он показывает статус DoH, DoT и других механизмов защиты соединения.
DoH и DoT скрывают только сам DNS-запрос — «какой IP-адрес у этого домена». Следующий шаг соединения, TLS ClientHello, по умолчанию всё равно передаёт имя сайта открытым текстом в поле SNI. Технология ECH (Encrypted Client Hello) дополняет DoH, шифруя и это поле — так провайдер не видит ни DNS-запрос, ни имя сайта в TLS-рукопожатии.
ECH уже поддерживается современными версиями Chrome и Firefox и работает автоматически для сайтов, которые публикуют нужную DNS-запись. Подробный разбор — в статье «ECH и DoH: как браузер скрывает DNS и SNI от провайдера».
DoH и DoT закрывают проблему перехвата самих DNS-запросов, но это не полная приватность соединения:
Для полной приватности соединения шифрованный DNS стоит комбинировать с шифрованием всего трафика целиком — тогда наблюдатель в сети не увидит ни DNS-запросы, ни IP-адреса назначения, ни поле SNI.
Для большинства пользователей проще и практичнее DoH: он идёт по порту 443 вместе с обычным HTTPS-трафиком, включается в браузере в пару кликов и не требует системных настроек. DoT (порт 853) стоит выбрать, если нужно защитить DNS сразу всех приложений на устройстве, а не только браузера, — например, через «Частный DNS» на Android.
DoH оборачивает DNS-запрос в HTTPS и отправляет на порт 443 — трафик неотличим от обычного веб-сёрфинга. DoT использует отдельный порт 853 и собственный TLS-туннель — устроен проще, но по номеру порта легко определить, что используется шифрованный DNS. Оба протокола одинаково надёжно шифруют содержимое запроса.
Нет — сам DNS-запрос зашифрован внутри HTTPS-соединения. Наблюдатель в сети видит только факт подключения к DoH-серверу (например, 1.1.1.1) и общий объём трафика, но не то, какие конкретно домены вы запрашивали.
DoT проще заблокировать технически — достаточно закрыть порт 853, и весь такой трафик отсекается без побочных эффектов. DoH заблокировать сложнее: он делит порт 443 с обычным HTTPS, и блокировка этого порта сломает доступ ко всем защищённым сайтам сразу.
Практического смысла нет: оба протокола решают одну и ту же задачу — шифрование DNS-запросов. Достаточно выбрать один: DoH для конкретного браузера или DoT — на уровне операционной системы, если нужно защитить сразу все приложения.
Нет. DoH и DoT шифруют только DNS-запросы. Сам веб-трафик, IP-адреса серверов и поле SNI в TLS ClientHello (пока не задействован ECH) остаются видимыми для наблюдателя в сети. Полную приватность соединения даёт только шифрование всего трафика целиком.
DoH и DoT защищают только DNS. AuraShield шифрует весь трафик от устройства до сервера — провайдер не видит ни DNS-запросы, ни адреса назначения. Два дня бесплатно.
Попробовать бесплатно →