Не работает dns over https

network.trr.mode 3
// Включить DOH в режиме безусловного использования — то есть без обращений к системному DNS даже в случае недоступности указанного в конфиге DOH сервера.
network.trr.bootstrapAddress 1.1.1.1
// Адрес для получения IP ближайшего резолвера. С тем же результатом пробовал 2606:4700:4700::1111, т.к. у меня нативный ipv6.
network.security.esni.enabled true
// Включить ESNI.
network.trr.uri и network.trr.resolvers пробовал оставлять подефолту и прописывать вместо mozilla.cloudflare-dns.com, заблокированного в РФ по ip (104.16.248.249 и 104.16.248.249), dns.cloudflare.com (104.19.199.29 и 104.19.198.29), который не заблокирован.
// Этот домен не используется для отправки запросов, поэтому в любом случае его блокировка не должна влиять на работоспособность DOH.

Здесь все галки зелёные (ESNI функционирует): https://www.cloudflare.com/ssl/encrypted-sni/ Даже разблокировался сайт 2channel.moe , который ТТК банит по TLS-SNI (трейсроуты до IP проходят, но без ESNI в браузере возникает ошибка «PR_CONNECT_RESET_ERROR»).
Тут «CloudFlare» (резолвинг выполняется через CF, а не системный DNS): https://www.dnsleaktest.com/
Сначала всё работает, но проходит несколько часов и ломается без видимой причины, что выражается в ошибках: «Хмм. Нам не удается найти этот сайт» — при попытке открыть любой домен.

Как выяснилось, с CloudFlare есть проблемы и при использовании DOH/DnsCrypt-клиента «dnscrypt-proxy», только симптомы другие.

Я прогнал DNS-бенчмарк namebench и обнаружил, что каждый 5ый запрос завершается ошибкой: «99 queries to this host failed» (из 500); а ещё есть жалобы на какой-то атрибут после каждого запроса: «‘module’ object has no attribute ‘edns'». Бенч даже не смог построить нормальный график — на него можно взглянуть ниже среди результатов теста прочих DNS-серверов. Однако, резолвинг не отваливался полностью, как в Firefox. Ошибки: «Хмм. Нам не удается найти этот сайт» не возникало даже спустя пару недель работы dnscrypt-proxy.
Вышеизложенная информация может привести к предположению, что лиса после определенного лимита кривых ответов отключает DOH, но поскольку я запретил ей обращаться к системному DNS (network.trr.mode 3), она перестаёт резолвить вообще. А dnscrypt-proxy не имеет такого лимита и стучится до CF во что бы то ни стало. Логично, но дальнейшее тестирование показало, что в лисе отваливаются любые DOH-серверы, а dnscrypt-proxy с любыми (кроме CF) абсолютно стабильно работает неограниченное время. Это значит, что за исключением CloudFlare проблема в клиенте, т.е. в Firefox.

Google DOH работает до 40 минут (ESNI тоже функционирует), затем отваливается, как и CF. В конфиг прописывал:

Источник

Настройка оборудования

Блог о модемах, роутерах и gpon ont терминалах.

Настройка DNS over HTTPS в браузере или роутере

В этой статье я хочу рассказать как включить поддержку протокола DNS over HTTPS (DoH) в веб-браузере, который позволяет шифровать DNS-трафик, тем самым повышая конфиденциальность пользователя в глобальной паутине. Это будет интересно в первую очередь тем, кто сильно переживает по поводу своей анонимности в Интернете и боится, что с введением закона Яровой кому-то потребуется статистика его веб-серфинга. Тем более, что поддержку этого протокола внедрена практически во всех современных веб-браузерах и даже больше — производители роутеров начинают постепенно внедрять его в своё программное обеспечение. Яркий пример — Keenetic OS и OpenWRT. Осталось всего лишь включить и настроить!

Схема работы DoH

Сегодня DNS-серверы это один из ключевых элементов работы глобальной сети Интернет. С их помощью идет обработка запросов пользователя. В самом простом приближении это выглядит так: человек вводит адрес сайта в адресной строке браузере, после этого идёт обращение к ДНС-серверу, который в свою очередь определяет IP сайта и возвращает результат обратно пользователю, чтобы он мог перейти на нужный ему сайт. В таком виде запросы достаточно просто перехватить, просмотреть и даже подменить. Конечно, провайдер подменой заниматься не будет, а вот злоумышленники очень даже могут!

Если же мы используем DNS over HTTPS, то все запросы отправляются напрямую к DoH-совместимому серверу, в обход серверов провайдера и используя для шифрования этих данных протокол HTTPS. Выполняется TCP-подключение на порт 443, как при обычном серфинге и запрос к серверу теряется в общем объёме трафика. Таким образом можно быть уверенным, что ни провайдер, ни владельцы общедоступных или частных WiFi-хотспотов, ни какие-либо злоумышленники не смогут перехватить Ваши данные.

Ещё одна полезная особенность протокола — DNS over HTTPS позволяет обходить простые системы блокировки сайтов, работающие на основе запросов DNS. Но тут не торопитесь радоваться, такие системы работают у мелких операторов связи. У крупных провайдеров вроде Ростелеком, Дом.ру или Билайна обойти блокировки РКН таким образом не выйдет.

Включаем DoH в браузере

В настоящий момент, поддержка протокола DNS over HTTPS реализована во всех веб-браузерах. Главное — обновить его до самой последней, актуальной версии.

Google Chrome

В адресной строке вводим вот такой URL-адрес:

Нажимаем клавишу «Enter» и попадаем вот на такую страницу:

Первым будет параметр «Secure DNS Lookups» — он то нам и нужен. Напротив него в выпадающем списке выбираем пункт Enable и перезапускаем приложение.

Opera

В браузере Opera порядок действий такой же, как и в хроме, только URL-запрос нужно вводить вот такой:

Искомый параметр называется «Secure DNS». Вот он:

Ставим ему значение Enable и перезапускаем Оперу. После этого браузер будет использовать ДНС-сервер Cloudflare 1.1.1.1 через защифрованное соединение.

Microsoft Edge

С этим браузером получилось интересней всего. Старая платформа ( версия 44 и ниже) не умеют работать с DNS over HTTPS. Поэтому сначала надо сходить на сайт Майкрософта и обновить Edge до версии 80 и выше, которая построена уже на движке Chromium.

В адресную строку вводим URL:

Параметру «Secure DNS lookups» ставим значение «Enable» и нажимаем на кнопку «Restart» внизу странички чтобы перезапустить браузер.

Mozilla Firefox

Чтобы настроить DNS over HTTPS в браузере Firefox, нужно зайти в его настройки и в поиске по параметрам ввести запрос — dns:

В результатах видим, что нужно зайти в параметры сети. Кликаем на кнопку «Настроить» и видим вот такое окно:

В самой нижней его части надо поставить галочку «Включить DNS через HTTPS». Что мне больше всего понравилось, это то, что можно выбрать какой сервер будет использован — Cloudflare, Google или какой-то иной. Нажимаем на кнопку «ОК» и перезагружаем Firefox.

Как включить DNS over HTTPS на роутере

Как я уже сказал, некоторые WiFi маршрутизаторы уже умеют работать с этим протоколом. Правда, не из коробки — в каждом случае нужно устанавливать дополнения для операционной системы. Я покажу это на примере роутера Keenetic.

Начинаем с того, что заходим в «Общие настройки», находим раздел «Обновления и компоненты» и кликаем там на ссылку «Изменить набор компонентов». Там надо найти и установить компонент DNS-over-HTTPS proxy. После этого устройство перезапуститься и в разделе Интернет-фильтр появится ещё один подраздел «Серверы DNS over HTTPS».

Кликаем на кнопку «Добавить сервер» чтобы появились поля параметров. Тут нужно прописать имя сервера DNS. Я использую вот эти:

Формат можно использовать JSON, который идёт по умолчанию, либо или DNS message, как у меня. Так же я указал WAN-интерфейс на котором будет работать протокол.
Если Вы пропишите несколько ДНС, то предпочитаемым будет тот, который быстрее отвечает.

Проверка работы протокола

Настраивали мы, настраивали, а как проверить работает ли DNS over HTTPS после всех наших манипуляций или нет. В настоящий момент я для этих целей использую сервис от Cloudflare — ссылка. Выглядит он вот таким образом:

Нажимаем кнопочку «Check my browser» и смотрим что будет показано в результатах. А именно, нас интересует пункт «Secure DNS» — он должен быть помечен зеленой галочкой:

Единственный момент, о котором стоит упомянуть — если Вы используете публичные ДНС от Google то этот тест не всегда удаётся пройти. Всё же Cloudflare продвигает свой сервис и поэтому удивляться не стоит.

Источник

Как настроить DNS over HTTPS в Firefox

DNS over HTTPS – относительно новая технология, которая предназначена для улучшения конфиденциальности, безопасности и надежности подключения DNS.

Системы доменных имен (DNS) играют очень важную роль – они позволяют сопоставлять адреса, вводимые в адресную строку с соответствующими IP-адресами. Обычно поиск DNS осуществляется автоматически и обычно без какого-либо шифрования или защиты от посторонних глаз.

Пользователи сети Интернет всегда имели альтернативы – подключение к VPN-службе, которая использует провайдер DNS, предоставляющий улучшенную защиту данных, или использование DNSCrypt для повышения безопасности и конфиденциальности.

DNS over HTTPS – еще один вариант, который появился сравнительно недавно. Mozilla добавила основную функциональность данной технологии в Firefox 60+.

Как настроить «DNS через HTTPS» в Firefox

Пользователи Firefox Browser могут настроить браузер, чтобы использовать DNS over HTTPS уже сейчас. Если вы используете как минимум 62.x, то вы сможете настроить функцию. Пожалуйста, обратите внимание, что использование DNS over HTTPS может привести к проблемам подключения, но все изменения обратимы.

Как настроить DNS over HTTPS в Firefox через параметры браузера

Перейдите в меню Настройки > Основные > Параметры сети и нажмите кнопку Настроить.
В открывшемся окне включите параметр Включить DNS через HTTPS, в выпадающем меню Используемый провайдер выберите предложенные по умолчанию Cloudflare DNS или NextDNS, или укажите другого провайдера с поддержкой DNS-over-HTTPS, выбрав Другой URL.

Например, чтобы использовать шифрование DNS-запросов с помощью Comss.one DNS укажите в поле Другой URL следующее значение:

Нажмите ОК и ваши DNS-запросы будут зашифрованы.

Как настроить DNS over HTTPS в Firefox через about:config

Для настройки DNS over HTTPS нужно изменить три параметра нового резольвера TRR (Trusted Recursive Resolver) в браузере:

Введите about:config в адресную строку Firefox.
Подтвердите, что вы принимаете на себя весь риск, если откроется страница с предупреждением.
С помощью строки поиска найдите параметр network.trr.mode и дважды щелкните по нему.
- Установите значение, равное 2, чтобы технология DNS over HTTPS была выбрана по умолчанию, а ваш стандартный DNS-сервер использовался в качестве резервного. Это оптимальный вариант с точки зрения совместимости.
- Вы можете установить значение 1, чтобы Firefox выбрал самый быстрый вариант; 3 – чтобы использовать только TRR; 4 – теневой режим: запускает TRR параллельно со стандартным DNS для синхронизации и измерений, но использует только результаты стандартного резольвера; 0 – чтобы отключить TRR по умолчанию, 5 – чтобы отключить TRR по выбору.

С помощью строки поиска найдите параметр network.trr.uri. В Firefox нужно будет ввести адрес сервера DNS over HTTPS. Дважды щелкните по названию параметра. На данный момент доступно множество общедоступных серверов, среди которых можно выделить Cloudflare DNS, Google Public DNS, Cisco OpenDNS:

Вы также можете воспользоваться нашим защищенным DNS-сервером Comss.one DNS:

Найдите параметр network.trr.bootstrapAddress и дважды щелкните по нему
- Установите значение 1.1.1.1 , если выбрали Cloudflare
- Установите значение 8.8.8.8 , если выбрали Google DNS
- Установите значение 208.67.222.222 , если выбрали Cisco OpenDNS
- Установите значение 93.115.24.204 , если выбрали Comss.one DNS
Перезапустите браузер Firefox.

Как проверить работу DNS over HTTPS в Firefox?

После настройки введите в адресную строку Firefox about:networking и нажмите ссылку DNS в меню слева. Откроется страница, на которой показывается содержимое кэша DNS в памяти.
В столбце TRR будет указано «true» для имен хостов, которые используют DNS-over-HTTPS.

Проверить работу DNS также можно с помощью сервиса DNS Leak Test (нажмите кнопку Extended test). Убедитесь, что все найденные DNS-серверы относятся к выбранному в качестве основного DNS. Например, если выбрали Cisco OpenDNS:

Источник

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-записи по меньшей мере от одного из этих главных серверов.

Каждая последующая DNS-зона добавляет ещё один домен к системе имён. Обычно каждая страна обслуживает собственные домены, а домены типа .org или .com, не привязанные к странам, обслуживаются отдельно. Запрос имени хоста через DNS начинается с имени домена (к примеру, .com), затем с названия (например, google), за которым следуют возможные поддомены. Если данные ещё не попадали в кэш, для разрешения запроса может потребоваться совершить несколько переходов по 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.

Источник