Комментарии 49
Плохо что сетевое оборудование не очень активно продвигается в сторону DNSSEC.
Пришлось пускать DNS запросы через GRE туннель.
На данный момент, возможно, только кастомные прошивки поддерживают из коробки DNSCrypt. С другой стороны, можно под конкретную платформу самостоятельно компилировать. Я как-то собирал под EdgeRouter.
С другой стороны, вроде бы для v2 есть уже под большинство платформ
https://github.com/jedisct1/dnscrypt-proxy/releases
TomatoUSB, AsusWRT Merlin, DD-WRT и OpenWRT вроде бы все поддерживают.
Также ничего не мешает поднять DNS на своем собственном VPS у хостера и использовать его разместив впереди nginx который будет слушать 853 порт и проксировать запросы к локальному резолверу, например, так blog.ispsystem.info/2020/01/dns-over-tls-nginx-proxy-debian-9.html
Я профессиональный параноик. Моя модель угроз отличается от вашей, и я предпочел бы сохранить в безопасности как можно больше своих действий в онлайне. Но учитывая количество нынешних угроз приватности и безопасности из-за манипуляций с трафиком DNS, у многих людей есть веские основания использовать какую-либо форму шифрования DNS. Я с удовольствием обнаружил, что некоторые реализации всех трёх протоколов не оказывают сильно негативного влияния на скорость передачи трафика.
Я хоть и не сильно параноик, но когда обнаружил, что мой провайдер подменяет ответы других серверов для DNS запросов на, якобы, запрещённые сайты, то сразу понял, что пора что-то менять. В итоге выбрал dnscrypt-proxy, установил и забыл. Какой либо заметной просадки в скорости резолвинга не заметил, зато ответы DNS теперь правильные.
Простите, а как вы обнаружили, что провайдер подменяет запросы? Я тоже хочу так уметь! :)
если ответы будут отличаться, значит провайдер не подменяет
Может, наоборот? Ответы не должны различаться? Точно не опечатка?
выполнив команды «nslookup rutracker.cr днс.сервер.провайдера» и «nslookup rutracker.cr 8.8.8.8», если ответы будут отличаться
Увы, много где отличаться они уже не будут. Провайдеры тупо перехватывают все по 53 порту.
Я если делаю запрос вида «nslookup rutracker.org любойсервер» в ответ в любом случае получаю ip адрес заглушки. решается только vpn или dnscrypt, или перечисленными в статье технологиями.
при использовании dnscrypt на openwrt частенько не резолвились домены третьего уровня. В итоге ломались некоторые сайты, например нельзя было скачать драйвер с сайта nvidia. Может конечно я что-то не так настроил, но прописывать домены в исключения в итоге надоело
используемое в соединениях HTTPS, всё равно может показать открытым текстом название сайта
А если используется QUIC/SPDY?
Он также обещает полностью скрыть DNS-трафик от посторонних глаз, используя шифрование.А потом такое:
Тем не менее, важно отметить, что одно лишь шифрование DNS не скроет ваши действия в интернете. Если на сервере хостятся несколько сайтов, то расширение TLS под названием Server Name Indicator (SNI), используемое в соединениях HTTPS, всё равно может показать открытым текстом название сайта, на который вы зашли.А потом продолжаем прятать трафик DNS. Не странно ли?
Кроме того, вот эта формулировка: Если на сервере хостятся несколько сайтов... неверна, ибо решает отправлять в заголовке SNI или нет, решает браузер, а не сервер. И современные HTTPS-клиенты, включая браузеры, сначала пробуют создать соединение указывая домен.
Так что, если хотите конфиденциальности, то нужно заворачивать весь трафик в туннель.
… и конфиденциальность закончится на выходе из туннеля.
Если известен IP юзера и IP сайта, то конфиденциальности уже нет — без SNI на данном IP может быть ровно один сайт, так что достаточно скачать его сертификат и там будет его имя (ну или через reverse DNS посмотреть), а со SNI имя сайта необходимо передать до того, как можно будет установить надёжное шифрование, а значит MitM всегда сможет его перехватить, даже если бы его пытались шифровать (это в ответ на коммент Garrett выше насчёт QUIC/SPDY — вряд ли там это смогли решить, это не проблема конкретного протокола).
Хотите конфиденциальности — I2P или Tor, там крайне сложно связать IP юзера и IP сайта.
А что касается DNS — его шифровать бессмысленно, по вышеописанным причинам. А вот обеспечить защиту от поддельных ответов — стоит.
Если собственный провайдер собирает данные по вашему трафику из DNS запросов как через их DNS сервера так и через DPI (судя по комментариям к оригинальной статье, актуальная вещь в США), то шифрование DNS трафика этот род деятельности как раз таки пресекает. Другое дело что SNI все равно всё палит =)
А проблемы с табами — это не особенность парсера stubby (libyaml), а требование стандарта yaml: «Note that indentation must not contain any tab characters.».
Я что то не понимаю как шифровка DNS запросов СКРЫВАЕТ о провайдера посещаемые сайты ?? От подмены да спасает, но остальной трафик кроме DNS запросов же не шифруется или шифруется по HTTPS, но источник его всё равно известен!!! IP адрес же не шифруется.
Другое дело, что РосКомНадзор в войне с Телеграмом (вернее, с самим собой) блочит именно диапазоны IP-адресов, а не сайты, в этом вся проблема.
Здесь поможет VPN или простой и доступный Tor.
Ну и чтобы зайти на сайт, надо (системе) сначала узнать его IP, а как это сделать, если провайдер DNS-запрос блочит/подменяет или редиректит на заглушку? А шифровка DNS просто скрывает DNS-запросы. Абырвалг по UDP на такой-то IP, и в ответ Йопрст по UDP. Провайдер не знает, куда вы хотите зайти, всё норм.
Оно и не скрывает куда ты ходишь. Оно скрывает запрос (а лучше маскирует под другой тип трафика) по 53 udp на получение ip адреса с днс сервера, которое могут перехватывать/подменять и применить разнообразные другие манипуляции. Например весь 53 udp пропускать через себя и на некоторые сайты выдавать адрес загрушки или фейковый сайт злоумышленника. Например при днс через https днс запросы провайдер от тебя не увидит вовсе, а будет видеть белибербу по https, как обычный веб траффик. В статье же есть информация и некоторые решаемые таски. Ну и стоит помнить, что запрос на конкретный ip ещё значит запрос на конкретный сайт. Их может быть много на одном адресе к примеру, они могут быть спрятаны за клаудфлеир к примеру. Да и не будет запросов минуя средства прокси/vpn/…. Если надо скрыть всё — то нужно много инструментов в связке. dnssec лишь один из них. Сам по себе он анонимности не даст, а от некоторых проблем может избавить.
github.com/aarond10/https_dns_proxy
Вообще, наблюдаю такую тенденцию: чем дальше
В чем отличия у этих двух пакетов dnscrypt-proxy или https-dns-proxy?
Как спрятать DNS-запросы от любопытных глаз провайдера