Dns over https или dns over tls что лучше
Google Public DNS тихо включили поддержку DNS over TLS
Внезапно, без предварительного анонса, на 8.8.8.8 заработал DNS over TLS. Ранее Google анонсировал только поддержку DNS over HTTPS.
Публичный резолвер от компании CloudFlare с IP-адресом 1.1.1.1 поддерживает DNS over TLS с момента запуска проекта.
Зачем это нужно
При использовании классической схемы DNS, провайдеры могут лезть своими грязными лапами в ваши DNS-пакеты, просматривать, какие домены вы запрашиваете, и подменять ответы как угодно. Этим же занимаются мошенники, подменяя резолверы на взломанных роутерах, чтобы направить пользователя на поддельный сервер.
C DNS over TLS/HTTPS запросы посылаются внутри зашифрованного тоннеля так, что провайдер не может подменить или просмотреть запрос.
А с приходом шифрования имени домена в сертификатах X.509 (ESNI) станут невозможны блокировки через DPI по SNI (Server Name Indication, специальное поле, в котором передается имя домена в первом TLS-пакете), которые сейчас применяются у некоторых крупных провайдеров.
Как это работает
На порт TCP:853 выполняется TLS-подключение, при этом проверка сертификата резолвера происходит с использованием системных корневых сертификатов, точно так же, как HTTPS в браузере. Это избавляет от необходимости добавлять какие-либо ключи вручную. Внутри тоннеля выполняется обычный DNS-запрос. Это создает меньше накладных расходов по сравнению с DNS over HTTPS, который добавляет HTTP-заголовки к запросу и ответу.
К сожалению, на текущий момент только в Android 9 (Pie) поддержка DNS over TLS встроена в системный резолвер. Инструкция по настройке для Android 9.
Для остальных систем предлагается использовать сторонний демон, а системный резолвер направлять на localhost (127.0.0.1).
Настройка на macOS
Установка
По умолчанию knot будет работать как обычный рекурсивный резолвер, подобно dnsmasq.
Редактируем конфиг
И добавляем в конец файла:
В итоге мой конфиг выглядит так:
Параметр hostname в данном случае — Common Name (CN) или Subject Alt Name (SAN) сертификата. То есть, доменное имя, для которого выпущен сертификат. По нему проверяется подлинность сертификата сервера.
Вот какие значения SAN у сертификата, который используется при подключении на 8.8.8.8:853
Любое из этих значений можно использовать в качестве параметра hostname. Если же вы будете разворачивать собственный публичный рекурсивный резолвер, у вас вряд ли получится выпустить X.509-сертификат на IP-адрес, поэтому в параметре hostname придется указывать доменное имя.
Запуск демона
Проверить, успешно ли запустился демон, можно командой:
процесс kresd должен слушать порт 53 на localhost.
Если что-то пошло не так, смотрим лог ошибок:
Проверка работы резолвера
Проверяем, что локальный резолвер отвечает корректно.
Установка в качестве системного резолвера
Если все работает правильно, можно назначить системный резолвер в свойствах сетевого адаптера:
В чем разница между DNSCrypt, DNSSEC, DNS over TLS/HTTPS.
DNSCrypt может работать по UDP и TCP. Подключение на порт 443. Для шифрования используется собственный протокол, который отличается от HTTPS. Может быть легко выделен с помощью DPI. Это скорее черновик, который тестировали до внедрения DNS over TLS/HTTPS, так как он не имеет RFC, то есть не является официальным стандартом интернета. Вероятнее всего, в скором, времени он будет полностью вытеснен последними.
DNS over TLS (DoT) — TCP-подключение происходит на порт 853, внутри тоннеля передается обычный DNS-запрос. Провайдер видит, что это DNS запрос но не может в него вмешаться. При прочих равных, в DNS over TLS должно быть чуть меньше накладных расходов на каждый запрос, чем в over HTTPS.
DNS over HTTP (DoH) — TCP-подключение на порт 443, подобно обычному HTTPS. Внутри другой формат запроса, с HTTP-заголовками. Однако для провайдера такой запрос будет виден как обычное HTTPS-подключение. Полагаю, этот протокол был придуман на случай, когда DNS-запросы к чужим серверам будут заблокированы, чтобы маскировать под обычный веб трафик. А также, чтобы браузеры могли сами резолвить домены и не создавать при этом аномальный трафик.
По сути, DNS over HTTPS и over TLS — одно и то же, с немного отличающемся форматом запросов. Оба эти протокола приняты в качестве стандартов и имеют RFC. Вероятнее всего, в ближайшее время мы увидим массовое распространение их обоих.
DNSSEC — протокол цифровой подписи DNS-записей. Не имеет отношения к шифрованию, так как все запросы передаются в открытом виде. Может работать как по старому классическому протоколу DNS, то есть UDP/TCP на порту 53, так и внутри DNS over TLS/HTTPS. Целью DNSSEC является подтверждение подлинности DNS-записи. Владелец домена может добавить публичный ключ на корневые сервера своей доменной зоны и подписывать все записи на мастер NS-серверах. По сути, к каждой DNS записи, например, A-записи или MX-записи, добавляется еще одна запись типа RRSIG, содержащая подпись. Процедура валидации DNSSEC на рекурсивном резолвере позволяет установить, действительно эта запись была создана владельцем домена.
О последствиях криптозащиты DNS-запросов
На этой неделе Microsoft объявила о поддержке в будущих обновлениях своей операционной системы Windows 10 протокола DNS over HTTPS (DoH), позволяющего шифровать запросы к DNS-серверам, подробности см., например, здесь. Microsoft объясняет инновацию тем, что сохранить децентрализацию DNS можно только в случае всеобщего принятия и использования протокола DoH, что и может быть обеспечено его поддержкой в Windows. Заявление Microsoft активно обсуждается в России: и специалистов, и обывателей прежде всего интересует, как поддержка DoH повлияет на исполнение закона об устойчивом Рунете. D-Russia.ru предлагает вашему вниманию текст нашего эксперта Александра Венедюхина.
Обычные клиентские компьютеры, а точнее — их операционные системы, используют для поиcка информации в DNS внешние серверы, называемые резолверами. Обычно это сервер, предоставленный в автоматическом режиме ближайшим провайдером доступа (интернет-провайдером). Иногда — общедоступный сервер, вроде хорошо известных 8.8.8.8 (Google) и 1.1.1.1 (Cloudflare), работу с которым пользователь должен настроить вручную. DNS-over-HTTPS — технология, защищающая пользовательский DNS-трафик на «последней миле», то есть на участке между компьютером пользователя и только что упомянутым резолвером (сервер, осуществляющий поиск в DNS).
Технология скрывает от третьей стороны, прослушивающей канал, содержание DNS-запросов и DNS-ответов. В самом простом случае таковыми будут доменное имя (запрос) и IP-адрес (ответ). Традиционно, в классической DNS, соответствующая информация передаётся в открытом виде. DNS-over-TLS (transport layer security, протокол криптозащищённой передачи данных – ред.) – это гораздо более технологичный вариант решения той же задачи, который, тем не менее, в контексте обычного пользователя Интернета можно считать аналогичным DNS-over-HTTPS (собственно, в этом последнем словосочетании, HTTPS – тоже работает через TLS).
Как технология «последней мили» DNS-over-HTTPS может поддерживаться всяким DNS-сервером (резолвером), а не только некоторыми избранными, но такую поддержку должен настроить оператор сервера. Согласно публикации Microsoft, корпорация собирается ввести поддержку DNS-over-HTTPS в клиентские операционные системы, что позволит использовать защищённый канал для работы с DNS. Однако речь пока не идёт о том, что в системных настройках всем будет принудительно установлен некий центральный сервер (например, принадлежащий Microsoft), который поддерживает DNS-over-HTTPS. (Полностью, конечно, такой вариант, как бы ни хотелось, исключать нельзя.)
Технология касается только обмена данными между компьютером пользователя и резолвером DNS, сама по себе она не способна повлиять на прохождение IP-трафика, как-то: позволить обойти «блокировки по IP», изменить маршруты трафика или сделать нечто подобное, что могло бы повлиять на независимость национального сегмента Сети. Это просто метод защиты DNS-трафика от просмотра. Более того, если взглянуть на проблему с другой стороны, ничто, в принципе, не мешает массово внедрить независимые резолверы DNS с поддержкой DNS-over-HTTPS и DNS-over-TLS внутри Рунета (и это было бы очень хорошим шагом) — соответственно, пользователи, при желании, смогут подключаться к ним.
Но есть и аспекты, в которых полный переход на защищённую работу с DNS играет ключевую роль и меняет расстановку сил. Во-первых, эти технологии позволят противодействовать подмене DNS-ответов на транзитных узлах, что нейтрализует попытки простой блокировки доступа, работающей на уровне DNS и перехватывающей ответы других DNS-серверов. Во-вторых, продвинутые системы инспекции трафика не смогут просматривать пользовательские DNS-запросы и, таким образом, обнаруживать в пассивном режиме IP-адреса и доменные имена «подозрительных ресурсов». Но оба этих аспекта имеют смысл только в том случае, если пользователь настроил некоторые «внешние DNS-серверы» в качестве резолверов для операционной системы, а не использует резолверы интернет-провайдера (последние полностью провайдером контролируются).
DNS-over-TLS vs. DNS-over-HTTPS
Настраиваю свой DNS-сервер, выбрал Pi-hole и публичный DNS от Cloudflare. Поскольку хочу DNS-запросы зашифровать, хочу использовать DoT или DoH. Что используете вы и почему? Какие лично для вас преимущества у того или другого варианта? Есть ли тут параноики, использующие DNS-over-Tor или ещё более извращённые варианты?
Пускаю через Tor, работает шикарно.
В роутере настроил DoT и DoH. Что из них для конкретного запроса отрабатывает быстрее я хз.
Везде сейчас используют DoH, остальное можно считать неактуальным.
Использую DoT. HTTP в таком приложении имеет изрядный оверхед и его стоит использовать только понимая, зачем именно: например в сетях, где закрыты другие порты/сервисы или необходимо однозначно ловить ошибки на уровне приложения.
С DNS от Cloudflare есть важный нюанс. DoT и DoH работают поверх TCP, а сервера one.one.one.one очень быстро рвут соединения. В результате практически каждый DNS-запрос претворятся TCP-хендшейком со своей задержкой на разговоры о погоде.
У меня через DNS от Google, где нормальные keepalive, среднее время ответа на запрос в полтора раза меньше, чем с Cloudflare. Хотя время пинга до 8.8.8.8 больше в два раза.
Поставил на openWRT роутере Stubby. От использует несколько серваков для DNS-over-TLS. Никаких проблем нет.
Это личные сервера NSA, лучше уж Google или nextdns.
Я лично через него использую DoT Cloudflare и Google.
И всетаки какие Шифрованные DNS лучше и перспективнее?
Вот и настало время. Мой домашний провайдер был замечен за перенаправлением dns-запросов на свои сервера, позвонил в ТП, те долго отнекивались(ну а что, откуда ТП такое знать?), но я не отстовал и они пошли в ЦОД, откуда вернулись с подтверждением моей теории и сказали что ничего исправлять не будут, всем остальным клиентам посрать и ни вообще ничего не заметили.
Ну ок, пошел на роутер, начал заворачивать роутерский dns трафик через vpn и задумался, а ведь есть более современные решения для этого дела, почему их не попробовать? У меня и одноплатник есть, который можно для этих целей задействовать.
Остался вопрос, что выбрать:
-DNSCrypt
-DNS-over-HTTPS
-DNS-over-TLS
А еще где скачать покет под debian, списки dns-серверов поддерживающие данные протоколы.
И что по настройкам, мне потребуется поднимать BIND/dnsmasq или клиенты самостоятельно могут кешировать и отдавать запросы, без доп. костылей?
Эмм, в России уже почти 10 лет как подменяют днс и сертификаты. Теперь везде в мире перенимают опыт, привыкай.
Началось это не с РФ. Перед тем как что-то сказать, трижды стоит подумать, а после этого еще раз десять раз подумать)
Там же DNS over HTTPS, как ответ может быть нешифрованным?
Ставь DNSCrypt, он умеет все, что тебе нужно. Просто ставишь пакет под свою архитектуру, в wiki найдешь ответы на все свои вопросы.
Молодец, взял и спалился провайдеру, что ты криптоонорхизд и твоя жопа хочет бутылки.
DNSsec оказался слишком сложным, и его никто не осилил?
Кто-то использует провайдерские dns? Есть для этого причины?
забыл про него, навыдумывали стандартов
DNSCrypt умеет все это.
А зачем тогда остальные навыдумывали?
ну действительно, это про тебя
Так кого интересуют страны третьего мира? Тотальное внедрение MITM, с маскировкой под легитимность, в «правовом» государстве, насколько мне известно, началось с РФ и перешло на всех соседей. Это вам не Европа, где люди хотя бы возмущаются на грубые нарушения прав и свобод. В Азии всё можно. Менталитет-с.
Они быстрые и не лежат. Публичные типа 8.8.8.8 и сотни других (включая все корневые) тоже заворачиваются провайдером, но при этом лежат чаще чем нет.
В России не подменяют сертификаты.
Использую DNSCrypt почти полгода. Жалоб нет.
DNSSEC не обеспечивает приватности, только проверку подлинности.
Эм, гугловские тоже быстрые и не лежат (не припомню падения лет за 8. по скорости тоже разница не велика)
+ Провайдеры используют блокировки по dns, а меня это не устраивает.
Ещё как подменяют. Смотри внимательней в следующий раз на то что тебе отдают и сравни хотя бы тут https://www.grc.com/fingerprints.htm
Это не новость на самом деле, ещё в 2010 что ли началось у самых разных провайдеров. Защита ДНС помогала от нелегитимных сертификатов раньше (только если он не подписан). Как думаешь сколько людей не получит поддельные серты? 99% интернета с MITM в РФ.
У гугловских домены 3 уровня сломаны 5 раз на месяц, больше ни у кого такой шляпы не было. И постоянно сайты перестают резолвится на несколько минут. Это очень заметно.
Как ты себе представляешь MITM современного HTTPS без воплей браузера о подмене?
Смотри внимательней в следующий раз на то что тебе отдают и сравни хотя бы тут https://www.grc.com/fingerprints.htm
Разберись в матчасти, что ли. Чтобы подменять сертификаты, нужно выпустить его от доверенного центра, также это не сработает для запиненных сертификатов. Как только доверенный центр выпустит такой сертификат, его корневой сертификат тут же отзовут и он перестанет работать. Это технически нереализуемо.
Ну, вообще это разные вещи. DNSSEC гарантирует только целостность данных (защита от подмены), но не конфиденциальность. А все эти днскрипты, насколько я понимаю, ориентированы в первую очередь на сокрытие запросов.
Никто не мешает положить сертификат в сборочки (собственно так и поступают), распространять с обновлениями, или подождать пока пользователь нажмёт «добавить в доверенные». И всё это делают последние 10 лет.
У гугловских домены 3 уровня сломаны 5 раз на месяц, больше ни у кого такой шляпы не было.
Какие dns прописать запасными? Свой поднимать?
Не сталкивался. Хотя везде гугловские dns прописаны, но не припомню проблем.
никто не мешает квовавой геббебне проникнуть к тебе домой ночью пока спишь и не внедрить сертификатов.
хватит нести чушь.
Это твои фантазии. Хотели бы подменять, просто на сайте провайдера выложили бы корневые сертификаты и инструкции по их добавлению для разных ОС.
В среднем это выглядит как доверенный сертификат от cloudflare или comodo (я уж не буду про то где подписывают «утёкшими» валидными сертами, а так тоже делают).
С lets encrypt всё ещё печальней. Почему-то это считается нормой, следить куда ты ходишь и что ты читаешь.
DNSSEC гарантирует только целостность данных (защита от подмены), но не конфиденциальность. А все эти днскрипты, насколько я понимаю, ориентированы в первую очередь на сокрытие запросов.
Да, днскрипт ориентирован на сокрытие, но среди списка серверов можно выбрать поддерживающие DNSSEC.
Ну да, конечно. А резать запрещённые статьи в интернете они как по-твоему будут без MITM? Только если раньше он был из-за различного рода соседства, то теперь он повсюду. Да что там, почтовые сервера с ним.
Хаха, только что проверил, никаких красных окон не выдаёт. Энжой, что называется.
Какие dns прописать запасными? Свой поднимать?
Все, что идет на 53 в открытом виде по днс-протоколу, провайдер завернет на себя.
Зелёный замочек отключается через некоторое время после загрузки, видимо за этим в хром и добавили защиту от подобного. 100% вручную не добавлялись.
вот кстати DNSSEC я бы с осторожностью дома использовал.
маны systemd-resolved, но емнип там по дефолту включена деградация с ворнингами в лог. т.е. это нужно настраивать или вообще смысла нет.
а настроишь на рестрикт и получишь головной боли, т.к. оно ломается. просто молча ничего не работает или только определённый сайт.
ну вообще то не на свои, а на федеральных хранителей
dnscrypt-proxy v2 умеет всё что тебе нужно.
В «сборочки» и троян можно положить, и майнер, и все что угодно. Просто не надо ими пользоваться.
Re: ну действительно, это про тебя
Так кого интересуют страны третьего мира?
ты сам начал разговор про Россию
Re: ну действительно, это про тебя
Не надо, Россия — это «второй» мир.
Ну здрасьте. Блокируют весь домен, если HTTPS.
Чем хорош и плох «безопасный DNS»
Возможно вы слышали, что в новых версиях Firefox внедрили поддержку нового шифрованного/безопасного/еще более лучшего (нужное – подчеркнуть) DNS, но не знаете что это за DoH такой и нужeн ли он вам; попробую объяснить.
Сперва – что такое старый нешифрованный, небезопасный и менее лучший DNS. Совсем кратко – это «адресная книга» для веб-сайтов: мы набираем в адресной строке браузера pikabu.ru, но браузер не знает, что это и как это найти. Он посылает DNS-запрос к DNS-серверу, и тот уже объясняет: что, как и где. Подробнее можно почитать в Педивикии – тот редкий случай, когда все объясняется четко и по делу.
Одна из проблем DNS заключается в том, что поиски нужного сайта происходят по незашифрованному соединению. Соответственно, все сервера, через которые проходят эти поиски, видят кто и что ищет. Если один из таких серверов контролируется злоумышленниками, чрезмерно «любознательными» компаниями или кровавой гэбней™, то возможны два вектора атаки на пользователя: подмена цели и сбор «телеметрии».
Подмена цели, это когда вы хотите зайти на pikabu.ru, а попадаете на сборник троянов. Или когда набираете адрес любимого сайта с детским проном котятками, а вместо него видите «Доступ к ресурсу заблокирован Роскомпозором». В обоих случаях происходит перехват DNS-запроса и подмена IP-адреса искомого сайта. С «телеметрией», думаю, и так все понятно – обычная история из серии «хочу все знать» и желательно про всех.
Если же DNS-запрос зашифровать, то ваши намерения в Интернете окажутся неизвестны «посредникам», т.е. в ваших поисках IP-адреса сайта pikabu.ru они будут участвовать не зная об этом. Куда идете вы с Пятачком Огнелисом будет известно лишь вам, администрации Пикабу и используемого DNS-сервера, а не всем подряд по дороге к нему и обратно.
Правда евангелисты «безопасного DNS» часто «забывают» уточнить несколько моментов.
Во-первых, вся эта возня с настройками браузера на «безопасный DNS» имеет смысл только в том случае, если вы собираетесь заходить на сайты, которые поддерживают соединение по защищенному протоколу – HTTPS, в противном случае вы получите лишь бронированную калитку в картонных воротах.
Во-вторых, первый запрос к искомому сайту будет содержать незашифрованный идентификатор имени сервера (SNI), из которого будут четко видны ваши намерения. Это нормально, как говорится, by design, но если провайдер использует систему анализа пакетов (DPI), то все напрасно. Чтобы превозмочь провайдерский DPI, вы можете включить поддержку шифрования идентификатора – ESNI (Encrypted SNI): заходите в about:config, находите (или создаете) параметр network.security.esni.enabled (тип – Boolean), и выставляете ему значение true, но…
Но, в-третьих, если провайдер использует DPI, то не обнаружив в вашем запросе ожидаемого там SNI, он, вполне вероятно, просто заблокирует этот запрос и вы увидите вместо искомого сайта сообщение PR_CONNECT_ABORTED_ERROR. Да, это цензура, не имеющая правовых оснований, нарушение положений ФЗ «О связи», прав человека, гражданина, потребителя и это все – жалуйтесь в Роскомпозор, там вас с интересом выслушают и даже посочувствуют.
В-четвертых, если в реестр Роскомпозора внесено не доменное имя, а IP-адрес, то схема с шифрованием DNS-запроса и SNI просто не работает (и не должна).
Таким образом, «безопасный DNS» панацея не столько от цензуры, сколько от излишне любознательных «информационных посредников», в первую очередь – интернет-провайдеров, и интернет-жулья. Но… но пока где-то в сибирской тайге или московском пентхаузе горько рыдает отечественное жулье, отлученное от ваших интернет-логов, в солнечной Калифорнии плачет от счастья сотрудник Cloudflare или другой Корпорации бобра, которой вы добровольно передали отнятые у своего провайдера данные о своих интернет-маршрутах. Упс…
Это было в-пятых? Погнали дальше, в-шестых: если вы блокируете рекламу и прочий мусор с помощью hosts, блокировка работать перестанет, т.к. DNS-клиент операционной системы будет получать от браузера уже зашифрованный запрос к DNS-серверу и проверить наличие искомого сайта в hosts не сможет. Вернее, сможет в теории, но не умеет в разбор пакетов, вычленение из них SNI и сравнение его с записями в hosts, а переписывать код ОС ради этого никто не будет (хотя насчет Linux утверждать не стану).
Как в теории можно было бы реализовать максимально безопасный и удобный для пользователя шифрованный DNS? Я это вижу как «DNS-рулетку»: у пользователя существует список безопасных DNS-серверов, которым он доверяет (т.е. в нем априори нет серверов Google и прочих глобальных шпионов), при подаче DNS-запроса из этого списка случайным образом выбирается один из серверов, к нему и идет запрос.
Следующий запрос – к другому случайному серверу из списка, в который могут входит сотни серверов. Таким образом, каждый из серверов получает некоторые данные о запросах (читай – идентифицирующих признаках) пользователя, но ни один из них не видит всей картины целиком. В каждом запросе еще можно подставлять рандомный user-agent и прочие составляющие «цифрового отпечатка». Мечтать не вредно…
Доведенных до практической реализации) протоколов безопасного DNS существует два: DoT (DNS over TLS) и DoH (DNS over HTTPS). Первый предложен Институтом информационных наук Университета Южной Калифорнии, компанией Verisign и ICANN в 2016 году, второй – спустя два года – той же ICANN и компанией Mozilla, оба до сих пор не утверждены в качестве стандарта.
DoT поддерживается на системном уровне в Android 9 и выше, DoH – в экспериментальных функциях Chrome (начиная с версии 78) и полноценно в Firefox (с версии 62). ESNI, насколько я знаю, сейчас поддерживается только в Firefox.