DNS по HTTPS – половинчатое и неверное решение
Всё время существования интернета открытость была одной из его определяющих характеристик, и большая часть сегодняшнего трафика всё ещё передаётся без какого бы то ни было шифрования. Большая часть запросов HTML-страниц и связанного с этим контента делается в простом текстовом виде [plain text], и ответы возвращаются тем же способом, несмотря на то, что протокол HTTPS существует с 1994 года.
Однако иногда возникает необходимость в безопасности и/или конфиденциальности. Хотя шифрование интернет-трафика получило широкое распространение в таких областях, как онлайн-банки и покупки, вопрос сохранения конфиденциальности во многих интернет-протоколах решался не так быстро. В частности, при запросе IP-адреса сайта по хосту DNS-запрос почти всегда передаётся открытым текстом, что позволяет всем компьютерам и провайдерам по пути запроса определить, на какой сайт вы заходите, даже если вы используете HTTPS после установления связи.
Идея о необходимости шифрования также и DNS-запросов не нова, и первые попытки этого делались ещё в 2000-х — DNSCrypt, DNS over TLS (DoT), и т.п. Mozilla, Google и другие крупные интернет-компании продвигают новый метод шифрования DNS-запросов: DNS over HTTPS (DoH).
DoH не только шифрует DNS-запрос, но и передаёт его «обычному» веб-серверу, а не DNS-серверу, благодаря чему DNS-трафик невозможно отличить от обычного HTTPS. У этой монеты есть две стороны. Эта процедура защищает сам DNS-запрос, как DNSCrypt или DoT, а также делает невозможным ребятам из служб безопасности крупных фирм отслеживать DNS-спуфинг, и переносит ответственность за критически важные функции сети с ОС в приложение. И также это никак не помогает скрыть IP-адрес веб-сайта, который вы только что запросили – ведь вы всё равно на него переходите.
По сравнению с DoT, DoH централизует информацию о посещённых вами сайтах в нескольких компаниях: на сегодня это Cloudflare, обещающая избавляться от ваших данных через 24 часа, и Google, которая намерена сохранить и монетизировать все подробности всего, что вы когда-либо планировали сделать.
DNS и конфиденциальность – важные темы, поэтому давайте углубимся в детали.
DNS-сервера и доверие
Концепция системы доменных имён восходит ещё к ARPANET, когда в единственном текстовом файле на каждом узле ARPANET – под названием HOSTS.TXT – содержалось всё соответствие названий систем, подключённых к ARPANET и их цифровых адресов. Когда вы самостоятельно пополняли этот файл, легко было убедиться в его правильности. С ростом сети стало нереально поддерживать центральную и локальные копии этих файлов. К началу 1980-х уже начались попытки создания системы автоматизации этого процесса.
Первый сервер имён (Berkeley Internet Name Domain Server или BIND) был написан в 1984 году группой студентов Калифорнийского университета в Беркли на основе RFC 882 и RFC 883. К 1987 году стандарт DNS был несколько раз пересмотрен, что привело к появлению RFC 1034 и RFC 1035, которые с тех пор по большому счёту не менялись.
Основа структуры DNS состоит в её древовидной схеме, где узлы и листья делятся на зоны. Корневая зона DNS – это верхний уровень, состоящий из тринадцати кластеров корневых серверов, формирующих официальные корневые DNS-сервера. Любой новый DNS-сервер (поднятый провайдером или компанией) получает DNS-записи по меньшей мере от одного из этих главных серверов.
DNSSEC: добавляем доверие в систему DNS
Перед тем, как перейти к шифровке DNS-запросов, нужно убедиться, что мы можем доверять DNS-серверу. Эта необходимость стала очевидной в 1990-х, и привела к появлению первых рабочих расширений стандарта безопасности DNS (DNSSEC), RFC 2353 и пересмотренного RFC 4033 (DNSSEC-bis).
Карта интернета 2006 года
DNSSEC работает, подписывая записи запросов DNS публичным ключом. Подлинность DNS-записи можно подтвердить публичными ключами корневой зоны DNS, являющейся доверенным третьим лицом в этом сценарии. Владельцы доменов генерируют свои ключи, подписываемые операторами зоны и добавляемые в DNS.
Хотя DNSSEC позволяют быть относительно уверенным в том, что ответы от DNS-сервера настоящие, этот протокол нужно включить в ОС. К сожалению, мало какие ОС реализуют сервис DNS, способный на нечто большее, чем просто «знать о наличии DNSSEC» – то есть, они на самом деле не подтверждают ответы DNS. А значит, сегодня нельзя быть уверенным в том, что получаемые вами ответы от DNS настоящие.
Проблема с DoH
Представим, что вы используете DNSSEC. Вы готовы зашифровать сообщения, чтобы добавить вашей передаче данных конфиденциальности. Причин для того, чтобы сохранить DNS-запросы в секрете от любопытных глаз, может быть много. Среди самых невинных — обход фильтров корпорации и провайдеров, запрет отслеживания интернет-привычек, и прочее. Среди более серьёзных — попытки избежать преследования со стороны правительства за выражение политических взглядов в интернете. Естественно, что шифрование DNS-запросов не даёт людям подсматривать эти запросы, однако в результате игнорируются более крупные проблемы с безопасностью DNS, и, естественно, всех остальных протоколов связи.
Основными конкурентами здесь являются DoT с использованием TLS и DoH с использованием HTTPS. Самая очевидная разница между ними – это порт: DoT работает на выделенном порту TCP 853, а DoH смешивается с другим HTTPS-трафиком на порту 443. Это даёт спорное преимущество неотличимости DNS-запросов от остального трафика, что лишает возможности операторам сети (частным и корпоративным) обезопасить собственную сеть, как в прошлом году заявил в своём твиттере один из архитекторов DNS Пол Викси.
Второе из главных отличий состоит в том, что если DoT просто отправляет DNS-запросы по TLS, то DoH по сути представляет собой DNS-over-HTTP-over-TLS, требует своего Media Type application/dns-message, и значительно всё усложняет. Смешение DoH с существующими протоколами приводит к тому, что каждый DNS-запрос и ответ проходят через стек HTTPS. Это кошмар для встроенных приложений, а также несовместимо практически со всеми существующими типами оборудования.
У DoT есть ещё одно преимущество – этот протокол уже реализован, и гораздо дольше, чем существует DoH, используется такими компаниями, как Cloudflare, Google, а также местными интернет-провайдерами; такое стандартное серверное ПО, как BIND, использует DoT прямо «из коробки». На ОС Android Pie (9-я версия) DNS через TLS будет использоваться по умолчанию, если выбранный сервер DNS поддерживает DoT.
Зачем переключаться на DoH, если DoT уже раскручивается? Если такие нестандартные приложения, как Firefox, будут обходить системную DNS на базе DoT, и использовать собственную систему получения доменных имён через DoH, то с точки зрения безопасности эта ситуация станет весьма сложной. Передача DNS на откуп отдельным приложениям, происходящая сейчас, кажется шагом назад. Известно ли вам, какой метод DNS использует каждое из приложений? Узнаете ли вы о том, что оно смешивает этот процесс с TCP-трафиком на 443-м порту?
Шифрование не препятствует слежке
За DNS over HTTPS ратуют две крупные компании, Cloudflare и Mozilla, причём последняя даже выпустила миленький комикс, где пытается объяснить схему DoH. Неудивительно, что они совершенно не упоминают DNSSEC (несмотря на то, что её называют «критически важной» в RFC 8484), и вместо этого предлагают нечто под названием Trusted Recursive Resolver (TRR), что, по сути, представляет собой совет «использовать доверенный DNS-сервер», под которым Mozilla подразумевает Cloudflare.
Кроме DoH, они упоминают стандарт QNAME minimization (RFC 7816), который должен уменьшить количество некритичной информации, отправляемой DNS-сервером. При этом этот стандарт никак не зависит от DoH и будет работать без всякого шифрования DNS. Как в случае с DNSSEC, безопасность и конфиденциальность улучшаются через эволюцию стандарта DNS.
Самое же интересное содержится в разделе «Чего не исправляет TRR + DoH»? Как уже говорили многие эксперты, шифрование DNS не препятствует отслеживанию. Любой последующий запрос к IP-адресу, который был получен ужасно секретным способом, всё равно будет ясно виден. Все всё равно будут знать, что вы зашли на Facebook.com, или на сайт для диссидентов. Никакое шифрование DNS или интернет-трафика не скроет информацию, жизненно необходимую для работы такой сети, как интернет.
Станет ли будущий интернет единой точкой отказа?
Mozilla предлагает справляться с проблемой отслеживания IP просто заявляя, что это не проблема благодаря использованию Облака. Чем больше веб-сайтов и сетей распространения контента (CDN) навесят на небольшое количество сервисов (Cloudflare, Azure, AWS, и т.п.), тем меньше будет значить этот единственный IP-адрес – нужно будет просто верить в то, что выбранный вами облачный сервис не будет воровать ваши данные и не упадёт на сутки.
В этом году 24 июня было массивное падение сервисов, когда ошибка в настройках, сделанная провайдером Verizon, привела к тому, что Cloudflare, Amazon, Linode и многие другие большую часть дня были недоступны. 2 июля этого года примерно на полчаса упал Cloudflare, а вместе с ним и многие веб-сайты, полагающиеся на его услуги.
По совпадению, облачный сервис Office365 от Microsoft тоже лежал в тот день несколько часов, из-за чего многие пользователи не смогли воспользоваться его услугами. В выходные перед днём труда [национальный праздник в США, отмечаемый в первый понедельник сентября / прим. перев.] отключение напряжения в дата-центре AWS US-East-1 привело к тому, что терабайт хранившихся там данных клиентов накрылся медным тазом. Очевидно, в идее о благе централизации интернета есть ещё какие-то недостатки.
Старые песни по-новому
Потрясающе, что во всей этой дискуссии по поводу конфиденциальности и отслеживания нет никаких упоминаний виртуальных частных сетей (VPN). Они решают проблемы с шифрованием данных и DNS-запросами, с сокрытием IP-адреса и прочим, просто перемещая точку, в которой ваш ПК или другое выходящее в интернет устройство соединяется с интернетом. Диссиденты внутри авторитарных режимов десятилетиями использовали VPN для обхода интернет-цензуры; VPN, включая такие его специальные виды, как Tor, являются критически важным элементом свободы в интернете.
Как работает Tor
Если вы доверяете большой коммерческой компании вроде Cloudflare в такой схеме, как DoH, то найти доверенного VPN-провайдера, не хранящего и не продающего ваши данные, будет легко. А в браузере Opera вообще есть бесплатная встроенная поддержка proxy, предлагающая множество преимуществ VPN.
В итоге можно сказать, что DoH подтверждает свой акроним, плохо делая то, что уже хорошо удаётся DoT [«Doh!» – восклицание, указывающее на глупость совершённого действия, особенно собственного / прим. перев.]. Нужно больше концентрироваться на повсеместном внедрении DNSSEC, совместно с DoT и минимизацией QNAME. А если вас заботит реальная конфиденциальность, то вам нужно обратиться к VPN.
«DNS over HTTPS» оформлен в RFC 8484 — но не все им довольны
В конце октября Инженерный совет интернета (IETF) представил стандарт DNS over HTTPS (DoH) для шифрования DNS-трафика, оформив его в виде RFC 8484. Его одобрили многие крупные компании, но были и те, кто остался недоволен решением IETF. Среди последних был один из создателей системы DNS Пол Викси (Paul Vixie). Сегодня мы расскажем, в чем здесь суть.
Проблема DNS
Протокол DNS не шифрует запросы от пользователя к серверу и ответы на них. Данные транслируются в виде текста. Таким образом, запросы содержат имена хостов, которые посещает пользователь. Отсюда появляется возможность «подслушать» канал связи и перехватить незащищенные персональные данные.
В чем суть DNS over HTTPS
Чтобы исправить ситуацию, был предложен стандарт DNS over HTTPS, или «DNS поверх HTTPS». В IETF начали работать над ним в мае 2017 года. Его авторами выступили инженеры Пол Хоффман (Paul Hoffman) из ICANN — корпорации по управлению доменными именами и IP-адресами — и Патрик Макманус (Patrick McManus) из Mozilla.
Особенность DoH заключается в том, что запросы на определение IP-адреса отправляются не DNS-серверу, а инкапсулируются в трафик HTTPS и передаются HTTP-серверу, на котором специальный резолвер обрабатывает их с помощью API. DNS-трафик маскируется под обычный HTTPS-трафик, а связь клиента и сервера происходит через стандартный для HTTPS порт 443. Содержание запросов и факт использования DoH остаются скрытыми.
В RFC 8484 Инженерный совет приводит примеры DNS-запросов к example.com с DoH. Вот запрос с методом GET:
Аналогичный запрос с использованием POST:
Многие из представителей ИТ-индустрии выступили в поддержку стандарта IETF. Например, ведущий исследователь интернет-регистратора APNIC Джефф Хьюстон (Geoff Houston).
Разработку протокола поддержали крупные интернет-компании. С начала года (когда протокол еще находился на этапе драфта) DoH тестируют Google/Alphabet и Mozilla. Одно из подразделений Alphabet, выпустило приложение Intra для шифрования DNS-трафика пользователей. Браузер Mozilla Firefox поддерживает DNS over HTTPS с июня этого года.
DoH внедрили и DNS-сервисы — Cloudflare и Quad9. В Cloudflare недавно выпустили приложение (об этом была статья на Хабре) для работы с новым протоколом на Android и iOS. Оно выступает в роли VPN к собственному устройству (на адрес 127.0.0.1). DNS-запросы начинают отправляться в Cloudflare с использованием DoH, а трафик идет «обычным» маршрутом.
Список браузеров и клиентов с поддержкой DoH можно найти на GitHub.
Критика стандарта DoH
Не все участники индустрии положительно отозвались о решении IETF. Противники стандарта считают, что DoH — шаг в неправильном направлении и он только снизит уровень безопасности соединения. Наиболее резко о новом протоколе высказался Пол Викси, один из разработчиков системы DNS. У себя в Twitter он назвал DoH «полнейшей чушью с точки зрения информационной безопасности».
По его мнению, новая технология не даст эффективно контролировать работу сетей. Например, системные администраторы не смогут блокировать потенциально вредоносные сайты, а рядовые пользователи будут лишены возможности организации родительского контроля в браузерах.
/ фото TheAndrasBarta PD
Противники DoH предлагают использовать другой подход — протокол DNS over TLS, или DoT. Эта технология принята как стандарт IETF и описана в документах RFC 7858 и RFC 8310. Как и DoH, протокол DoT скрывает содержимое запросов, но отправляет их не по HTTPS, а использует TLS. Для подключения к DNS-серверу при этом используется отдельный порт — 853. Из-за этого отправка DNS-запроса не скрывается, как в случае с DoH.
Технология DoT тоже подвергается критике. В частности, эксперты отмечают: из-за того, что протокол работает с выделенным портом, третья сторона сможет отслеживать использование защищенного канала и при необходимости блокировать его.
Что ждет протоколы дальше
По словам экспертов, пока неясно, какой из способов защиты DNS-запросов станет более распространен.
Сейчас и Cloudflare, и Quad9, и Alphabet поддерживают оба стандарта. Если DoH Alphabet использует в упомянутом выше приложении Intra, то протокол DoT применили для защиты трафика в Android Pie. Также Google включил поддержку DoH и DoT в Google Public DNS — причем внедрение второго стандарта никак не анонсировали.
Издание The Register пишет, что конечный выбор между DoT и DoH будет зависеть от пользователей и провайдеров, и сейчас ни у одного из стандартов нет явного преимущества. В частности, по прогнозам ИТ-специалистов, для широкого распространения протокола DoH на практике потребуется пара десятилетий.
DNS-over-HTTPS и риски для персональных данных — обсуждаем мнения экспертов
25 февраля Mozilla сделали DNS-over-HTTPS (DoH) протоколом по умолчанию в своем браузере для всех американских пользователей. В целом ИТ-сообщество встретило это решение положительно, заметив, что шифрование DNS-трафика повысит безопасность в интернете. Но нашлись и те, кто считает иначе, — например, представители интернет-регистратора RIPE.
В сегодняшнем материале разбираем основные мнения.
Небольшой ликбез
Прежде чем переходить к обзору мнений кратко разберем, как работает DoH и почему его реализация вызывает жаркие споры в ИТ-сообществе.
Обмен данными между браузером и DNS-сервером происходит в открытом виде. При желании злоумышленник может подслушать этот трафик и проследить, какие ресурсы посещает пользователь. Чтобы решить проблему, протокол DoH инкапсулирует запрос IP-адреса в трафик HTTPS. Затем он поступает специальному серверу, который обрабатывает его при помощи API и генерирует ответ (стр.8):
Таким образом, DNS-трафик скрыт в трафике HTTPS, и запросы к системе доменных имен остаются анонимными.
Кто поддерживает DoH
В поддержку DoH высказываются западные облачные провайдеры, телекомы и интернет-провайдеры. Многие из них уже предлагают DNS-сервисы на базе нового протокола — полный список есть на GitHub. Например, в British Telecommunications говорят, что сокрытие DNS-запросов в HTTPS увеличит безопасность британских пользователей.
Пара материалов из нашего блога на Хабре:
Год назад DNS-over-HTTPS начали тестировать в Google. Инженеры добавили возможность активировать DoH в Chrome 78. По словам разработчиков, инициатива защитит пользователей от DNS-спуфинга и фарминга, когда хакеры перенаправляют жертву на ложный IP-адрес.
В начале материала мы упомянули другого разработчика браузера — Mozilla. На этой неделе компания подключила DNS-over-HTTPS для всех пользователей из США. Теперь при установке браузера новый протокол активируется по умолчанию. Тех, у кого уже есть Firefox, планируют перевести на DoH в ближайшие недели. Другие страны новая инициатива пока обойдет стороной, но желающие могут включить передачу DNS-запросов по HTTPS самостоятельно.
Аргументы против
Те, кто выступает против внедрения DoH, говорят, что он снизит безопасность сетевых подключений. Например, Пол Викси (Paul Vixie), один из авторов доменной системы имен, утверждает, что системным администраторам станет сложнее блокировать потенциально вредоносные сайты в корпоративных и частных сетях.
Выступили против нового протокола и представители интернет-регистратора RIPE, отвечающего за европейский и ближневосточный регионы. Они обратили внимание на проблемы безопасности персональных данных. DoH позволяет передавать информацию о посещаемых ресурсах в зашифрованном виде, но соответствующие логи все равно остаются на сервере, отвечающем за обработку DNS-запросов с помощью API. Здесь встает вопрос доверия к разработчику браузера.
Сотрудник RIPE Берт Хуберт (Bert Hubert), который участвовал в разработке PowerDNS, говорит, что классический подход DNS-over-UDP предоставляет большую анонимность, так как смешивает все запросы к системе доменных имен из одной сети (домашней или публичной). В этом случае сопоставить отдельные запросы с конкретными компьютерами становится сложнее.
/ Unsplash / chris panas
К недостаткам DoH некоторые эксперты также относят невозможность настроить родительский контроль в браузерах и сложности с оптимизацией трафика в CDN-сетях. В последнем случае может вырасти задержка до начала передачи контента, так как резолвер будет искать адрес хоста, ближайшего к серверу DNS-over-HTTPS. Здесь стоит отметить, что ряд ИТ-компаний уже работает над решением этих сложностей. Например, в той же Mozilla рассказали, что Firefox будет автоматически отключать DoH, если пользователь настроит правила родительского контроля. И компания планирует продолжить работу над более совершенными инструментами в будущем.
О чем мы пишем в корпоративном блоге VAS Experts:
Как послать провайдера подальше, и включить DNS по HTTPS в любом браузере
Поддержка DoH уже встроена во все основные браузеры. Пользователям нужно её только включить и настроить.
Все шесть производителей основных браузеров планируют поддерживать протокол DNS по HTTPS (DoH), шифрующий DNS-трафик и помогающий усилить конфиденциальность пользователя в сети.
Этот протокол является одной из самых обсуждаемых тем этого года. Он позволяет браузеру прятать DNS-запросы и ответы внутри обычного на первый взгляд HTTPS-трафика.
Это делает DNS-трафик пользователя невидимым для сторонних наблюдателей за сетью, например, провайдеров. Однако если пользователи обожают DoH и считают его благом для конфиденциальности, провайдеры и производители средств кибербезопасности его ненавидят.
Британский провайдер назвал Mozilla «интернет-злодеем» за планы компании по внедрению DoH, а группу лоббистов от Comcast уличили в подготовке документа касательно DoH, который они планируют представить законотворцам Британии, надеясь предотвратить более широкое распространение протокола.
Однако, время уже может быть упущено. Редакция в течение недели связалась с производителями основных веб-браузеров, чтобы узнать об их будущих планах касательно DoH, и все они планируют внедрять протокол в том или ином виде.
Как включить DoH в любом браузере
Вот, что нам известно на сегодня по поводу планов производителей браузеров, связанных с DoH, и о том, как пользователи могут включить DoH в любом браузере.
Brave
«Мы очень хотим реализовать его», — сказал нам Том Лоуэнталь, менеджер продукта из Brave for Privacy & Security.
Однако у команды Brave пока нет точных сроков внедрения DoH. Они занимаются другими улучшениями, связанными с приватностью. К примеру, на этой неделе компания выпустила обновление, улучшающее распознавание скриптов, отслеживающих действия пользователей. На горизонте маячит версия Brave 1.0, и команде нужно сконцентрироваться на её выходе. Но DoH в Brave будет.
«Реализация DoH – это гораздо больше, чем простая техническая задача. Нам нужно решить, какие разумные и защитные установки мы можем включить по умолчанию для большинства людей, не задумывающихся о настройке DNS – но так, чтобы мы ничего не сломали у тех людей и организаций, что тщательно подошли к подстройке своих программ», — сказал Лоуэнталь.
Поскольку Brave основан на открытом проекте Chromium, в нём есть поддержка DoH. Однако команда пока не настроила эту поддержку. В коде она есть, но включается так, как это придумала команда авторов Google Chrome. Включить DoH в Brave можно, перейдя на следующий URL:
Chrome
Google Chrome стал вторым браузером после Firefox, добавившим поддержку DoH. Её можно включить, перейдя по следующему URL:
По-умолчанию DoH не включено для всех. Сейчас Google проводит ограниченный эксперимент с небольшим количеством пользователей, чтобы проверить, как DoH покажет себя при реальном использовании.
Поддержка DoH в Chrome отличается от Firefox, по-умолчанию перенаправляющего DoH-трафик на Cloudflare. Браузер после включения протокола будет отправлять DNS-запросы на всё те же сервера, что и ранее. Если у выбранного сервера окажется интерфейс с поддержкой DoH, тогда Chrome зашифрует DNS-трафик и отправит его на тот же DNS-сервер по протоколу DoH.
Благодаря этому Chrome не перехватывает DNS-настройки ОС – это очень ответственный подход, поскольку браузер может использоваться в условиях больших предприятий.
На текущий момент DoH в Chrome работает так:
Однако есть два способа обойти это и заставить Chrome использовать DoH постоянно и вне зависимости от настроек DNS вашего провайдера.
Во-первых, можно воспользоваться обучающим материалом по принудительному включению поддержки DoH в Chrome. Во-вторых, пользователь может настроить DNS-сервер с поддержкой DoH в своей ОС. Его можно выбрать из списка, и это гарантированно будет работать в Chrome.
В следующем году Microsoft планирует выпустить новую версию браузера Edge на основе кода Chromium. Представитель Microsoft сообщил нам, что компания поддерживает DoH, но точные планы не раскрывает. Однако, версия Edge на основе Chromium уже поддерживает DoH. Её можно включить, перейдя по URL:
Это включит поддержку DoH, но она будет работать только, если ваш компьютер использует DNS с поддержкой DoH – чего в 99% случаев не происходит. Чтобы принудительно включить DoH в Edge, вы можете воспользоваться инструкцией из следующего поста в блоге одного из программистов Edge. Адрес сервера Cloudflare можно заменить на любой другой сервер DoH, который можно выбрать по ссылке. После соответствующей настройки, Edge способен работать с DoH.
Firefox
Mozilla стала пионером этого протокола совместно с Cloudflare. Поддержка DoH уже есть в стабильных версиях Firefox. Её можно включить в настройках в разделе «Настройки сети».
Все критикуют реализацию DoH в Firefox потому, что браузер по умолчанию использует Cloudflare, перезаписывая настройки DNS.
Однако это значение можно поменять, прописав любой сервер с DoH. Из всех браузеров, поддержка протокола в Firefox реализована лучше всего, а настроить её легче всего – в основном потому, что разработчики имели с ней дело дольше остальных.
Сейчас браузер уже включает поддержку DoH по умолчанию для всех пользователей США. Поскольку британское правительство возражает против этого, для британских пользователей эта поддержка по умолчанию включена не будет.
В прошлом Mozilla не гарантировала включение DoH по умолчанию в других странах. Однако, поскольку поддержка протокола уже есть в стабильной версии браузера, пользователю остаётся лишь включить её, и всё будет работать.
Opera
Opera уже встроила поддержку DoH. По умолчанию она выключена, но её можно включить в любой момент, и всё будет работать без дополнительных шагов.
Разработчики Opera используют модуль для работы с DoH сходный с тем, что используется в Firefox, и не оставляют всё на откуп провайдерам, как Chrome. Весь трафик браузера сейчас идёт через резолвер 1.1.1.1 от Cloudflare.
Мы не нашли способа поменять его на другой, но, по крайней мере, DoH в Opera работает. Однако работать с VPN он не будет – если вам нужен DoH, то его придётся отключить.
Чтобы включить DoH в Opera, зайдите сюда:
Safari
Нет данных. Разработчики Safari обычно опаздывают на все вечеринки по добавлению новых возможностей, а Apple недавно вкладывалась в конфиденциальность пользователей, поэтому есть все шансы, что у Safari появится поддержка DoH.
Vivaldi
Представитель Vivaldi сказал, что поддержка DoH связана с реализацией Chrome. Пользователи могут включить её, перейдя по следующему URL:
Однако поскольку DoH в Vivaldi работает так же, как в Chrome, он не будет шифровать DNS-запросы, если пользователь использует DNS-сервер, указанный в ОС, и не поддерживающий шифрование.
Скорее всего, придётся добавить в настройки DNS вашей ОС один из серверов, поддерживающий DoH, чтобы эта функция заработала в Vivaldi, и использовать его постоянно. Мы смогли добиться этого, прописав в настройках DNS-сервер 1.1.1.1.
Представитель Vivaldi сказал, что в будущем поддержка DoH в браузере может поменяться, в зависимости от того, как Google будет изменять поддержку протокола в Chromium.
