Мэинтейнеры порта Firefox для OpenBSD не поддержали решение по включению по-умолчанию DNS over HTTPS в новых версиях Firefox. После короткого обсуждения было решено оставить изначальное поведение неизменным. Для этого настройка network.trr.mode выставлена в значение '5', что приводит к безусловному отключению DoH...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51471
Наконец-то голос разума среди всеобщего сумасшествия.
Оно не всеобщее, просто Firefox не может угнаться и поэтому играет с картой про privacy. И не важно, что кучу всего по дороге сломает, зато копеечку заработает себе
Шифровать то идея отличная и нужная, но реализация - конечно мда. Все аргументы из статьи в точку
Откуда взялось упоминание CloudFlare?
>По умолчанию используется DNS-сервер CloudFlareиз предыдущей новости https://www.opennet.ru/opennews/art.shtml?num=51439
https://www.opennet.ru/opennews/art.shtml?num=51439Для включения DoH в about:config следует изменить значение переменной network.trr.mode, которая поддерживается начиная с Firefox 60. Значение 0 полностью отключает DoH; 1 - используется DNS или DoH, в зависимости от того, что быстрее; 2 - используется DoH по умолчанию, а DNS как запасной вариант; 3 - используется только DoH; 4 - режим зеркалирования при котором DoH и DNS задействованы параллельно. По умолчанию используется DNS-сервер CloudFlare, но его можно изменить через параметр network.trr.uri, например, можно установить "https://dns.google.com/experimental" или "https://9.9.9.9/dns-query".
у гугла уже официальная поддержка появилась
experimental в конце не надо писать, а как у всех теперь dns-query, но домен вроде сокращенный - без .com в конце
ну или просто восьмерки
но это не точно
> Откуда взялось упоминание CloudFlare?https://support.mozilla.org/en-US/kb/firefox-dns-over-https
"In the US, Firefox by default directs DoH queries to DNS servers that are operated by CloudFlare, meaning that CloudFlare has the ability to see users' queries. Mozilla has a strong Trusted Recursive Resolver (TRR) policy in place that forbids CloudFlare or any other DoH partner from collecting personal identifying information. To mitigate this risk, our partners are contractually bound to adhere to this policy. "
>> Откуда взялось упоминание CloudFlare?
> https://support.mozilla.org/en-US/kb/firefox-dns-over-https
> "In the US, Firefox by default directs DoH queries to DNS servers
> that are operated by CloudFlare, meaning that CloudFlare has the ability
> to see users' queries. Mozilla has a strong Trusted Recursive
> Resolver (TRR) policy in place that forbids CloudFlare or any other
> DoH partner from collecting personal identifying information. To mitigate this risk,
> our partners are contractually bound to adhere to this policy. "В России не будет работать. В принципе, может, оно и к лучшему, но тогда нужно, чтобы хром и ИЕ перешли на DOH, а этого не видно.
Во-первых, будет, но надо включить вручную
Во-вторых, https://blog.chromium.org/2019/09/experimenting-with-same-pr...
Открой about:config и посмотри "network.trr.uri".
> Открой about:config и посмотри "network.trr.uri".В репе старая версия.
Я вот только не пойму. Вроде 0 отключал, а теперь еще и 5, но точно.
Т.е. 0 при желании мог и включить?
Для пользователей из США 0 включает, для остальных — _пока_ нет.
> Шифрование DNS, возможно, и неплохая идея, но отправка по умолчанию всего DNS-трафика в Cloudflare - точно плохая идея.А чем это качественно отличается от отправки всего DNS-трафика на Cloudflare, если DNS 1.1.1.1 или в Гугл, если DNS 8.8.8.8 или IBM если DNS 9.9.9.9, помимо того, что этот трафик не зашифрован и его перехватывает провайдер?
Тем, что по умолчанию у тебя нет таких DNS. Если ты сам их прописал, то либо ты доверяешь CF/GG/IBM, либо тебе пофиг, но в любом случае, если уж всё равно в настройки полез, можешь настроить хоть DoH, хоть DoT, хоть ещё что.
> Тем, что по умолчанию у тебя нет таких DNS. Если ты сам
> их прописал, то либо ты доверяешь CF/GG/IBM, либо тебе пофиг, но
> в любом случае, если уж всё равно в настройки полез, можешь
> настроить хоть DoH, хоть DoT, хоть ещё что.По умолчанию DNS провайдера, полученные по DHCP.
> По умолчанию DNS провайдера, полученные по DHCP.Это же прекрасно! Родной т̶о̶в̶а̶р̶и̶щ̶ ̶м̶а̶й̶о̶р̶ истинно православный провайдер должен знать куда в интернете ходют его п̶р̶и̶х̶о̶ж̶а̶н̶е̶ пользователи. А вот всяческим басурманам из Cloudflare/Google/IBM ентого знать не положено.
А что мешает завести свой кеширующий днс? Зачем вообще нужен гуглоднс опенбздишнику?
> А что мешает завести свой кеширующий днс? Зачем вообще нужен гуглоднс опенбздишнику?А откуда в нём кэш браться будет?
От DNS провайдера, который всё равно к вышеописанным DNS обращается, только ещё может и сам вклинится и меня зароутить по своему желанию.
От DNS провайдера, который всё равно
Вообще-то нет. Провайдерский днс вообще не нужен. Будет полная цепочка запросов от корневых серверов до конечного домена. Причем тут гуглоднс и провайдерский днс (если его конечно насильно не завернут на себя)?
> От DNS провайдера, которыйОт рутовых DNS серверов, а затем от серверов обслуживающих TLD, а затем от, собственно, хостящих сам домен. Удивительно, как много людей не понимает как работает DNS.
>> От DNS провайдера, который
> От рутовых DNS серверов, а затем от серверов обслуживающих TLD, а затем
> от, собственно, хостящих сам домен. Удивительно, как много людей не понимает
> как работает DNS.Подзабыл маленько.
Но в итоге твой провайдер всё равно будет знать куда ты ходил, так как все эти запросы отправляются от тебя в открытом виде.
Во-первых, "знать" он будет только если специально фильтровать DNS трафик. За пределами высокодуховых государств это мало кому интересно. Во-вторых, что вам мешает форвардить запросы через DNS-over-TLS? Собственно, вместо практически насильственного внедрения DoH и нездорового ажиотажа вокруг этого, якобы, "лучшего решения с безопасностью в DNS", надо повсеместно внедрять DoT и DNSSEC. Но крупные игроки и интересанты в этом, действительно решающем проблемы с защитой DNS трафика, процессе, похоже, совершенно не заинтересованы.
Почему - вопрос риторический.
DoT и DoH технически сравнимы. DoT чуть легче блокируется, работают одинаково.и клиентов море, внедряй не хочу. помимо CloudFlare и Mozilla, есть ещё DoH-клиенты от Facebook, Google и менее крупных пассажиров.
> работают одинаковоРаботают не одинаково. Во-первых, это инкапсуляция в HTTP, что сразу же отрезает клиентов без его поддержки. Во-вторых, в случае с DoH вы всегда запрашиваете данные из одного источника, а при DoT при его массовом использовании, будет такая же децентрализованная сеть DNS серверов, но с защитой трафика между ними.
Это две огромные разницы.
кстати, да, DoH в современном виде -- это клиентская технология. тупо потому, что все употребимые серверы in-house, так ничего не мешает научить и сервер-сервер в него. и может это окажется проще, чем допилить DoT, который пока внедрён чуть более, чем никак.DoT и DoH не имеют принципиальных отличий ни по сложности парсинга протокола, ни по времени работы (тут чуть выигрывает DoH, умеющий в multiplexing). моя ставка, что из этих двух приживётся DoH.
DoH сложнее, поскольку использует дополнительную прослойку в виде HTTP которая предполагает конверсию (в случае с GET) пакетов DNS и их парсинг, а равно как и заголовков ответа от веб-сервера. Это помимо того, что в клиентский софт надо ещё и сам HTTP втащить, даже там, где он не используется и не нужен за пределами DoH.
> Это помимо того, что
> в клиентский софт надо ещё и сам HTTP втащить, даже там,
> где он не используется и не нужен за пределами DoH.в клиентский софт надо втянуть резолвер, в обоих случаях.
если написать на коленке отправку и парсинг DNS-протокола прямо в клиентском софте, это будет тоже сложно. и да, очень вряд ли этот протокол понадобится где-то ещё в приложении, в отличие от HTTP.
> в клиентский софт надо втянуть резолвер, в обоих случаяхНе надо, потому что стандартные функции типа gethostbyname() уже есть везде где нужно. Это базовая сетевая функциональность. Вы же предлагаете втягивать HTTP и парсер DoH туда, где это не нужно, к примеру в мессенджеры. На кой там упёрся HTTP вообще не понятно.
>> в клиентский софт надо втянуть резолвер, в обоих случаях
> Не надо, потому что стандартные функции типа gethostbyname() уже есть везде где
> нужно. Это базовая сетевая функциональность. Вы же предлагаете втягивать HTTP и
> парсер DoH туда, где это не нужно, к примеру в мессенджеры.вот как раз не предлагаю. я предлагаю, чтобы системный gethostbyname() уже знал про DoH.
собственно, новость об этом же: в OpenBSD считают, что приложениям in-house колхозить DoH не надо т.к. надо решать DoT/DoH средствами системного резолвера, а не колхозить в приложениях.
> в OpenBSD считают, что приложениям in-house колхозить DoH не надо т.к. надо решать DoT/DoH средствами системного резолвера, а не колхозить в приложениях.Не могу не согласиться. Но большие дяди охочие до наших метаданных теперь и из DNS считают иначе.
и это, в системной gethostbyname() (или его современном варианте) уже дофига логики и реализаций странных протоколов. там кроме DNS-запросов есть и парсинг /etc/hosts, и NIS, и NIS+, и Hesiod, и LDAP. если весь этот зоопарк там уже есть -- лично я не вижу, каким боком HTTPS усложняет эту систему. не более, чем любой из протоколов, которые уже там есть.
> лично я не вижу, каким боком HTTPS усложняет эту систему. не более, чем любой из протоколов, которые уже там есть.Ну, хотя бы, фактом своего наличия, а также прослойки трансляции DNS wireformat из / в HTTP. Равно как и обработка всех его заголовков и рост DoH трафика в разы в сравнении с обычным DNS или DoT.
> парсинг /etc/hosts
Священное наследие до-DNS эры попрошу не трогать :)
Вот только на России процентов эдак 75 провайдеров перехватывают обращения по 53/udp и 53/tcp, заворачивают их к себе и отвечают сами. Так что без DoH/DoT/DNSCrypt никак не обойтись.
подобные проблемы (заодно и блокировки) решаются покупкой самого дешевого впс за бугром.
далее строим опенвпн тунель и пускаем весь или днс + остальной не зашифрованный трафик через него.но если именно днс, то уменя огромные сомнения что владельцы впс в России занимаются такой же ерундой. А у нас самый дешевый впс где-то 120-200 рупей.
> нос забился
> такие проблемы решают заменой носоглотки
> далее дышим исключительно через противогаз или марлевая повязка + пакет на голове
>> А что мешает завести свой кеширующий днс? Зачем вообще нужен гуглоднс опенбздишнику?
> А откуда в нём кэш браться будет?
> От DNS провайдера, который всё равно к вышеописанным DNS обращается, только ещё
> может и сам вклинится и меня зароутить по своему желанию.Ты хоть примерно представляешь себе, как работают DNS серверы и откуда там берётся кэш?
а ты?:)
написаное анонимом вполне себе возможно. угадай в каком случае.
Насколько я понимаю, Firefox запрещает менять дефолты без смены брендинга.
Я вот такое тоже припоминаю.У меня давно зреет мысль добавить во фрёвые порты опции чтобы можно было не ставить покет и прочие предустановленные плагины с дерьмовым функционалом, но вероятно из за этого могут не принять патч.
В принципе можно было бы сделать "ребрендинг" через порт, типа ff-debloat но ломы, проще патч держать приватным или вечно в багтрекере.
Тут меняется только all-openbsd.js, это такой сорт pref.js. Не факт, что запрет накладывается на эту возможность кастомизации (тем более, это не первая специфичная для OpenBSD кастомизация подобным образом).
Но я не настоящий сварщик.
Само «обсуждение» в OpenBSD это уже смешно. Тео выгнали из команды NetBSD за полную неспособность к обсуждению любых вопросов, неспособность аргументировать свою точку зрения и истерики вида «ХАЧУ!ХАЧУ!».А что у Тео не очень хорошо с головой это и так всем известно, как и то, что никто все равно OpenBSD нигде не использует, а значит это изменение никого в мире не затронет. Так что пофигу.
Перейди по ссылке на обсуждение. Там Тео вовсе не присутствует.
> Перейди по ссылке на обсуждение. Там Тео вовсе не присутствует.Ему это и не важно, он с Тео даже по мессейджам из рассылок не знаком. Но мнение имеет! (с)
Справедливости ради, Тел собрал вокруг себя такой же токсичный и малоадекватный контингент.
> Справедливости ради, Тел собрал вокруг себя такой же токсичный и малоадекватный контингент.Ради неё же, упомянутый контингент сосредоточен на собственных вопросах, и не указывает другим как и что им делать. Свобода как она есть.
Upd: собрались тут Теологи. ;)
*отравляет оппонента благодаря своей токсичности*
> Само «обсуждение» в OpenBSD это уже смешно.Да что ты говоришь? Открой тот же marc.info, openbsd-misc или openbsd-tech и убедись в обратном.
> Тео выгнали из команды NetBSD за полную неспособность к обсуждению любых вопросов, неспособность аргументировать свою точку зрения и истерики вида «ХАЧУ!ХАЧУ!».
Странно, а я почему-то регулярно читаю дискуссии, в т.ч. и с участием Тео.
И однообразные, как под копирку, комментарии про Тео, типа вот этого твоего.Послали, когда написал фигню в рассылку, да?)
Ну, Тео и компания никогда не скрывали, что предпочитают называть вещи своими именами и послылают прямым текстом, если к ним пришли с хренью. И правильно делают.
Атмосфера нездоровой терпимости к чужому идиотизму губительна для технических сообществ.
Что писать в network.trr.uri что бы настроить через dnscrypt-proxy
https://127.0.0.1/dns-query
так не работает