Узнайте, что такое DNS-over-HTTPS (DoH), как работает этот протокол, чем он отличается от классического DNS и какие преимущества и риски несет его использование. Всё о шифровании DNS-запросов, настройке DoH в браузерах и роутерах, а также о влиянии технологии на безопасность и конфиденциальность.
В 1983 году, когда Пол Мокапетрис создал DNS, интернет был совсем другим — сеть научных лабораторий и университетов, где скорость и простота были важнее безопасности. DNS решал одну единственную задачу: быстро преобразовывать доменные имена в IP-адреса. Шифрование? Об этом никто не думал, угрозы казались далекими, а круг пользователей был ограничен.
Запросы DNS летали по сетям в открытом виде, как открытки без конверта. Любой, кто мог «подслушать» — от провайдера до хакера в кафе с Wi-Fi — видел, какие сайты вы посещаете. Более того, злоумышленники могли подменить ответы, перенаправив вас с легитимного сайта вроде google.com на фишинговую страницу или сервер с вредоносным кодом.
В 1990-х появился DNSSEC — первый шаг к защите. Эта технология подписывала ответы цифровой подписью, чтобы гарантировать их подлинность. Это позволило обеспечить защиту от атак, направленных на подделку данных DNS, таких как атаки типа «Man-in-the-Middle», и гарантировать, что полученные DNS-ответы исходят от авторитетных источников, а не от злоумышленников, пытающихся перехватить или изменить информацию.
Но как же конфиденциальность? Запросы всё ещё оставались видимыми для всех. VPN-сервисы, шифровавшие весь трафик, стали популярны позже, но их настройка была не для всех, скорость страдала, а доверие к провайдерам VPN вызывало вопросы.
К началу 2010-х стало ясно: DNS нужен свой щит, который сохранит его простоту, но добавит конфиденциальности. Первая попытка защиты DNS-запросов с использованием шифрования была реализована в DNSCrypt, который был разработан в 2013 году. Однако этот протокол не был стандартизирован и оставался скорее экспериментальным. Успешным способом защиты стал DNS-over-TLS (DoT), появившийся в 2016 году (RFC 7858). Запросы упаковывались в TLS-туннель, однако их было легко вычислить по порту 853 и заблокировать, если провайдеру это не нравилось.
Прорыв случился в 2018 году, когда IETF стандартизировало DNS-over-HTTPS (DoH, RFC 8484). Запросы замаскировали под обычный HTTPS-трафик на порту 443, что добавляло безопасности запросам, а для наблюдателя выглядело как просто еще одно соединение с сайтом. Таким образом отличить DNS-запрос от загрузки веб-страницы стало почти невозможно.
Браузеры и ОС подхватили новинку: Firefox внедрил DoH в 2019, Chrome и Edge — вскоре после. Cloudflare запустил публичный сервер 1.1.1.1, Google — 8.8.8.8, а Яндекс добавил DoH в свой DNS-сервис. Так началась новая глава: DNS-запросы перестали быть легкой добычей, а пользователи получили реальную защиту приватности.
Кстати, наш сервис SkyDNS также поддерживает протокол DNS-over-HTTPS (DoH) для своих юзеров.
Представьте: вы пишете адрес сайта на открытке и отдаёте её почтальону. Однако по пути открытку может прочитать кто угодно — соседи, охранник на проходной или случайный прохожий. Так устроен классический DNS: каждый запрос к доменному имени идёт в сети «как есть», без защиты.
DNS-over-HTTPS (DoH) по сути создает для вашей открытки «конверт», который инкапсулирует её в зашифрованный HTTP поверх TLS-трафика, это делает DNS-запросы неотличимыми от обычного общения с сайтом. Для провайдера, администратора сети или злоумышленника ваш запрос на разрешение домена выглядит как загрузка страницы или видео, а не как попытка узнать IP-адрес вашего целевого сайта.
DoH использует два способа передачи:
В обоих случаях данные находятся внутри TLS-туннеля, что делает их чтение со стороны фактически невозможным без сессионных ключей.
Так выглядит запрос DNS при захвате трафика:
А так данные передаются в запросе с включенным DoH (для демонстрации был отключен ECH — Encrypted Client Hello, однако при включении имя сервера будет зашифровано):
При этом важно понимать, что DoH опирается на те же механизмы безопасности, что и обычный HTTPS, а значит, его надежность напрямую зависит от TLS. Основная часть браузеров и операционных систем сегодня работает на базе TLS 1.3 — более быстрой и защищенной версии протокола, хотя и TLS 1.2 по-прежнему используется.
Защиту трафика обеспечивают современные криптографические алгоритмы: AES, ChaCha20 и схемы обмена ключами на основе ECDHE. Для перехватчика это делает содержимое запросов фактически недоступным без сессионных ключей. Дополнительный уровень доверия создает проверка сертификата DoH-сервера: клиент принимает ответ только в том случае, если сертификат выдан надежным центром сертификации. Всё это вместе снижает риск подмены сервера и обеспечивает конфиденциальность канала связи.
При этом стоит помнить: даже при использовании TLS некоторые метаданные, такие как IP-адреса или SNI в Client Hello (если не включен ECH), остаются видимыми для внешнего наблюдателя.
Поскольку в классическом DNS запросы к доменным именам передаются в сети в открытом виде, без шифрования и без проверки подлинности источника, это образует ряд угроз, от которых защищает DoH.
Поскольку DNS-запросы, как правило, идут поверх протоколов UDP/TCP на 53 порту, их может перехватить любой, кто имеет доступ к маршруту передачи: провайдер, системный администратор в Wi-Fi-сети кафе или злоумышленник с доступом к локальной сети. Это позволяет отслеживать, какие сайты посещает пользователь, в какое время и с какой регулярностью. В совокупности это даёт достаточно информации, чтобы составить поведенческий профиль. Практика показывает, что некоторые провайдеры и рекламные сети используют эти данные для таргетированной рекламы.
Один из самых опасных сценариев атак для пользователя на классический DNS — это подмена ответов. Здесь есть два основных варианта подмены:
Также DNS нередко используется как средство блокировки. Вместо настоящего IP-адреса возвращается «заглушка» или редирект на страницу с предупреждением. В некоторых странах это основной способ ограничить доступ к информации. Классический DNS делает такую цензуру простой и эффективной: запросы не шифруются и легко контролируются.
Большинство перечисленных угроз снижается при использовании DoH: запросы становятся невидимыми для посторонних и их сложнее подменить «по пути». Однако технология не снимает всех рисков: сохраняются вопросы доверия к выбранному резолверу, видимость метаданных и необходимость дополнительных механизмов вроде DNSSEC и ECH.
Ниже приведена инструкция по включению протокола DoH в наиболее известных браузерах.
Mozilla Firefox был одним из первых браузеров, внедривших DoH: поддержка протокола появилась ещё в 2019 году.
В Google Chrome поддержка DoH появилась в 2020 году.
Microsoft Edge основан на Chromium, поэтому настройка почти идентична Chrome.
Также существует вариант включения DNS-over-HTTPS на роутере. Это удобно тем, что под защитой оказываются сразу все устройства в сети — от смартфонов и ноутбуков до различных IoT-устройств. Способ настройки зависит от модели и прошивки. Ниже — некоторые варианты для популярных вендоров.
Для кого? Домашние пользователи. Поддержка DoH/DoT встроена, настройка делается через веб-интерфейс.
Как включить?
Для кого? Тем, кто использует MikroTik в офисе или дома, DoH поддерживается из коробки.
Как включить?
/ip dns set use-doh-server=https://dns.cloudflare.com/dns-query verify-doh-cert=yes
/ip dns print
Для кого? Энтузиасты и продвинутые пользователи, готовые к кастомной прошивке.
Как включить? (вариант с https-dns-proxy)
opkg update
opkg install https-dns-proxy
Для кого? Бизнес, продвинутые домашние сети, x86-маршрутизаторы.
Как включить? (через Unbound + DoT/DoH)
Не все устройства умеют работать с DoH напрямую: если смартфоны и браузеры уже давно поддерживают эту технологию, то телевизоры, камеры видеонаблюдения, приставки или умные колонки продолжают обращаться к обычному DNS на 53-й порт. Чтобы не оставлять их трафик «голым», на помощь приходит роутер: он берёт на себя роль DNS-прокси.
В этом случае клиенты сети отправляют стандартные незашифрованные DNS-запросы к роутеру, а он сам перенаправляет их на внешний DoH-резолвер, упаковывая запросы в HTTPS. Снаружи весь DNS-трафик выглядит как обычное TLS-соединение на 443-й порт.
Однако если со стандартных хостов проверить работу DoH можно с помощью инструментов вроде Wireshark или tcpdump, то для проверки с роутера нужен несколько иной подход.
Рассмотрим инструкцию на примере упомянутых ранее Keenetic:
Проще всего открыть любой тестовый сервис — например, 1.1.1.1/help от Cloudflare или adguard.com/test.html. В них должно появиться подтверждение, что используется защищенный DNS.
Если вы не хотите вручную прописывать адреса DoH/DoT, достаточно активировать встроенные фильтры — SkyDNS, AdGuard DNS или Яндекс.DNS. При наличии соответствующих компонентов KeeneticOS роутер автоматически переведет работу на шифрованный протокол. Но важно помнить: при включенных фильтрах внешние проверки иногда показывают «Fail» — это не ошибка, а особенность. Keenetic в таком режиме блокирует транзитный DoH/DoT, чтобы исключить утечку запросов мимо прокси.
В версиях прошивки до KeeneticOS 3.7 проверить поддержку можно через командную строку следующими командами:
show adguard-dns availability
show cloudflare-dns availability
Для получения доступа к CLI в cmd или терминале нужно ввести команду:
telnet 192.168.1.1
Затем ввести пароль.
Если в DHCP или в настройках сетевого адаптера на клиентских устройствах прописаны сторонние DNS-серверы, тесты покажут «Fail», потому что запросы пойдут в обход Keenetic. Решение простое: убрать эти адреса и повторить проверку.
Если добавлено несколько DoT/DoH-адресов, результат теста зависит от того, какой сервер сейчас активен. Например, Google DoH не всегда проходит пункт «Secure DNS» в тесте Cloudflare.
Проверку работы Cloudflare можно провести и на cloudflare.com/ssl/encrypted-sni. Там при корректной настройке галочки должны стоять напротив «Secure DNS», «DNSSEC» и «TLS 1.3».
Появление DoH стало шагом к большей приватности в интернете, позволяя лучше защищать личные данные пользователей от посторонних глаз. DoH частично решает проблему безопасности в открытых Wi-Fi сетях — в кафе и аэропортах — где трафик легко перехватывается.
Но у любой технологии есть обратная сторона: приватность — это компромисс. В личном сценарии DoH выглядит логичным решением, однако в корпоративной среде он создает проблему: шифрование лишает видимости на уровне сети и затрудняет выявление угроз, которые раньше эффективно находили при анализе DNS-трафика.
Технологию оперативно освоили и атакующие: спустя полгода после появления стандарта ботнет Godlua начал использовать DoH для связи с серверами управления (C2), из-за чего их стало сложнее обнаруживать. Позже подтянулись и более серьёзные игроки киберпреступного мира: APT34 (OilRig) была замечена в применении DNS-туннелей и DoH для эксфильтрации данных, усложняя жизнь аналитикам.
Таким образом, DoH не решает проблему доверия, а лишь меняет её адресата: раньше вы доверяли провайдеру, теперь часть доверия переносится на оператора DoH. Cloudflare, Google, Яндекс — все они получают доступ к вашим DNS-запросам. По сути, это замена одной линии наблюдения другой. Для тех, кто хочет «никому не доверять», это не решение, а переадресация вопроса: «А кому мы доверяем?»
Значит ли это, что DoH «плох» и его нужно запрещать? Нет, это было бы упрощением. DoH полезен: он повышает приватность и снижает риск перехвата запросов в пути. Однако подход «включить всем и забыть» — нерабочий.
Гораздо логичнее смотреть на DoH как на элемент архитектуры: шифруем канал, но оставляем контроль, превращая его в дополнительный слой безопасности в корпоративной среде.
Для дома достаточно выбрать одного проверенного провайдера защищенного DNS. В организациях разумно использовать одного доверенного провайдера защищенного DNS или развернуть собственный резолвер. Так передача данных остается защищенной, а анализ DNS-запросов на признаки риска по-прежнему возможен — особенно при трафике за пределами периметра компании.
Важно помнить: DoH закрывает содержимое запроса, но не метаданные. Снаружи остаются видны IP-адреса и частота обращений, а без Encrypted Client Hello (ECH) — еще и имя хоста в SNI. DoH также не заменяет DNSSEC, который защищает от подмены кэша. Плохая конфигурация DoH, напротив, усложнит работу ИБ.
Таким образом, DoH — лишь один из слоев защиты. Базовая гигиена остается обязательной: всегда использовать HTTPS, подключаться к корпоративным системам через VPN, контролировать расширения браузеров и сетевые приложения. Регулярные обновления ОС и софта закрывают уязвимости, в том числе в протоколах шифрования. И, конечно, внимательность к ссылкам и доменам — ключевой щит: никакое шифрование не спасет, если кликнуть не туда.
