Разработчики Mozilla предложили (https://blog.mozilla.org/futurereleases/2018/09/13/dns-over-.../) пользователям принять участие в тестировании функции обращения к DNS поверх HTTPS (DoH, DNS over HTTPS). После успешного эксперимента с включением DNS over HTTPS в ночных сборках, решено протестировать данную функциональность в бета-выпусках Firefox. В конце этой недели части пользователей Firefox Beta из США будет предложено активировать обращение к DNS через HTTPS (при нежелании принимать участие в тестировании пользователь сможет отказаться).
В процессе тестирования DoH в ночных сборках существенное ускорение отклика было замечено только пользователями с медленными каналами связи,в то время как у большинства пользователей наблюдалось незначительное снижение производительности. Тем не менее эксперимент был признан удачным, так как польза от повышения защищённости при использовании DoH перекрывает зафиксированную задержку на уровне 6 миллисекунд, которая незаметна в процессе работы.
Желающие могут присоединиться к тестированию 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".
Напомним, что DoH может оказаться полезным для исключения утечек сведений о запрашиваемых именах хостов через DNS-серверы провайдеров, борьбы с MITM-атаками по подмене DNS-трафика, противостояния блокировкам на уровне DNS или для оганизации работы в случае невозможности прямого обращения к DNS-серверам (например, при работе через прокси). Если в обычной ситуации DNS-запросы напрямую отправляются на определённые в конфигурации системы DNS-серверы, то в случае DoH запрос на определение IP-адреса хоста инкапсулируется в трафик HTTPS и отправляется на HTTP-сервер, на котором резолвер обрабатывает запросы через Web API. Существующий стандарт DNSSEC использует шифрование лишь для аутентификации клиента и сервера, но не защищает трафик от перехвата и не гарантирует конфиденциальность запросов.
Дополнительно, можно отметить активацию (https://groups.google.com/forum/#!topic/mozilla.dev.platform...) для ограниченного числа пользователей ночных сборок Firefox (https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly) системы композитинга Servo WebRender (https://github.com/servo/webrender), написанной на языке Rust. При включении WebRender для выполнения операций отрисовки элементов страницы не используется встроенная в движок Gecko система композитинга, обрабатывающая данные при помощи CPU. Вместо этого используются (http://www.masonchang.com/blog/2016/7/18/a-short-walkthrough...) шейдеры, выполняемые в GPU, что позволяет добиться существенного увеличения скорости отрисовки.
Тестирование затронет около 17% пользователей стационарных ПК с ОС Windows 10 и видеокартой NVIDIA. Для активации WebRender независимо от попадания в группу тестирования в about:config можно выставить переменную "gfx.webrender.all". По оценке разработчиков, система уже работает достаточно стабильно на всех поддерживаемых в Firefox платформах, кроме Android.
URL: https://blog.mozilla.org/futurereleases/2018/09/13/dns-over-.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=49271
Такое надо на уровне системы внедрять, а не в отдельных браузерах.
Такое на уровне системы 10 лет ждать. А здесь уже, и для большинства пользователей это самая важная часть днс-запросов. Шифровать резолвы для клиента стима и мессенджера не так важно.
И это никак не мешает внедрять на уровне системы. Вообще. Внедряйте. Потом можно будет выключить в браузере.
> Такое на уровне системы 10 лет ждать.На последнем андроиде уже сделали.
Только последние Андроиды, даже 8, используется малым процентом. А в браузере фича будет
так внедряйте
я уж по рекомендаци RH ставлю на все системы unbound для кеширования, он умеет поверх https
> unbound для кеширования, он умеет поверх httpshttps://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1200
> Summary: Does unbound support DNS-over-HTTPS (DoH)?
> Status: ASSIGNEDтак вот кто угнал машину времени!
>> unbound для кеширования, он умеет поверх https
> https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1200
>> Summary: Does unbound support DNS-over-HTTPS (DoH)?
>> Status: ASSIGNED
> так вот кто угнал машину времени!упс, сорян, я с DNS over TLS перепутал
Вообще, отдельный вопрос, какого х браузер резолвит в обход системы.
Да они там вообще припухли. DNS навязывают, свою поисковую систему не добавить без геморроя, собирают статистику по приватным вкладкам - это вообще лютая дичь, типа "Никто не узнает, какие ресурсы ты посещаешь. Кроме нас".
Вы ещё скажите "какого х браузер использует прокси в обход системы". А при использовании прокси зачастую лучше резолвить через тот же прокси.
Вот именно что навязывать DoH - всё равно, что заставлять всех ходить через прокси корпорации добра.
> Вот именно что навязывать DoH - всё равно, что заставлять всех ходить
> через прокси корпорации добра.Кто ж навязывает? Галка будет (когда в релиз пойдет), хотите включайте, хотите нет. Как и с настройками отслеживания.
А бета тестеров тоже спрашивают, хотят они потестировать или нет.
А потом галку уберут. И пункт в about:config.
Потому что система не умеет в DoH.
На уровне системы это внедрять не нужно, потому что HTTPS.
Внедрять нужно DNS-over-TLS.
Таки да, оно хоть стандартизовано, а это пока ещё experimental.
не нужно.
используйте dns over tls
TRR prefs https://gist.github.com/bagder/5e29101079e9ac78920ba2fc718aceec
Да да. Только вот люди которые уже давно частенько смотрели на webrender знают что хоть оно и "ускоряет" отрисовку оно так же и нагружает систему. Привыкли что ваша видеокарта от Nvidia/AMD при браузинге работает на низких частотах и холодна? Забудьте.
Покрути, например, карты яндекса на дисплее 4К с WR и без, почувствуй разницу.
И реши для тебя что важнее - плавность отрисовки или холодный GPU.
Вот GPU я бы нагрузил.
Эти люди не замеряли общую потребляемую мощность? Мне кажется, это интереснее, чем температуры отдельных составляющих компьютера. Температуры меня как-то вообще не волнуют, пока они в пределах разумного.
1. Куда им там, они борятся с различными багами специфичные под разные ос/gpu, как на своей стороне, так и в коде ANGLE, при этом жестоко форсятся пул реквесты в сам ANGLE (гугелю либо пофиг на это, либо angle в составе бинарного хрома у них приватный).2. Ноутбуки.
> 1. Куда им там, они борятся с различными багами специфичные под разные
> ос/gpu, как на своей стороне, так и в коде ANGLE, при
> этом жестоко форсятся пул реквесты в сам ANGLE (гугелю либо пофиг
> на это, либо angle в составе бинарного хрома у них приватный).Как это мешает замерить потребляемую мощность?
> 2. Ноутбуки.
Что "ноутбуки"?
Что лучше горячий процессор или видеокарта?
network.trr.uri - прописал локалхост туда, чтобы ненароком не включилось.
Ну и дурак. Этот параметр как раз легко могут тебе перезаписать при обнове, ибо никто не обещал и нефиг полагаться. Для сознательного объявления об отказе нужно ставить network.trr.mode 5, тогда тебя обойдёт стороной в любом случае, даже если станут по дефолту всем включать без спроса.
Ну и зачем отказываться от хорошей функции?
Конечно, не стоит отказываться и выбрать в качестве DoH непременно корпорацию бобра.
Например я хочу что бы *.google.com ресолвились в 127.0.0.1, как это сделать с этой «хорошей» функцией? Не все пользователи хотят что бы за них решали что и как ресолвить.
Ну сколько можно 127.0.0.1 использовать для блокировок, это не глупо.
Всегда пишу 0.0.0.0 - после этого софт даже не пытается подключится, он сразу знает что домен не отрезолвился и делать ничего не надо.
Зачем мне это!?
У меня стоит мой локальный unbound который делает то что мне нужно и как мне нужно.
В частности не резолвит всякие дрянные домены типа дудльадвордс и прочие рекламы, трекеры, мусор.Что до майора, то местным чтобы закрыть трафик не нужен, хранить и анализировать они не могут, нетфлоу вроде 3 года хранят всего.
При этом чужие майоры умеют анализировать и анализируют, хранят хз сколько и тп.
Webrender у меня странно подёргивается и на Nvidia и на Intel. Отрисовка же средствами OpenGL совершенно плавная.
Следующие шаги:
1. Весь трафик начинает идти через сервера одной-двух компании (гугл, амазон), потому что они лучше всех резолвят через https
2. Эти же сервера терминируют HTTPS
3. Ваш личный сайт посчитали плохим, никто на него зайти не может
4. Добро пожаловать в интернет 3.0
> Следующие шаги:Предпочитаю Гугл, товарищу майору.
Выбор даже так не стоит. Гугл — это когда товарищ майор имеет более совершенные инструменты.
Я те предпочту!
Звали меня, товарищ майор?
Молодец, тебя конкретно не вызывал, а сам пришёл. Продолжай и дальше также. Приходи и интересуйся, не находишься ли ты в розыске. Докладывай, с кем общаешься и что обсуждаете. Вот, товарищи, пример достойного гражданина! :)
правильно, а то господин оберлейтенант тоже интересуется (и ему мы тебя тоже продадим)
Местный майор тебя закроет просто так, ему твой трафик не нужен, писать ему его некуда, анализировать тоже.А вот зачем иностранному майору твой трафик ты бы лучше задумался.
Они ведь столько усилий прилагают чтобы трафик со всего шарика к себе завернуть, думаешь это просто так?
> Местный майор тебя закроет просто так, ему твой трафик не нуженразьве хоть один, севший за лайки, оспаривал сам факт лайков? Отож.
доказательная база, она может и не пригодится, но надо ж ему как-то отличать, кого именно сегодня лупить дубиной и тащить в автозак.> Они ведь столько усилий прилагают чтобы трафик со всего шарика к себе завернуть, думаешь
> это просто так?я вот думаю, что нашему майору тоже продадут. Или поменяют на что-то полезное.
Товарищу майору проще подойти к одному Гуглу и взять всю инфу, чем гоняться за каждым юзером. А Гугл - он не откажет, он ведь не хочет рынок потерять. Так что централизация майору на руку.
1 пункт уже реализован в хроме и яндекс браузере, называется если не ошибаюсь сжатие трафика и 3 пункт уже реализован в какой то мере.
Как же блин достали этим. Грёбаные костыли. А всё из-за тормознутости некоторых "контор", которые сочиняли DNS-SEC'и и проч.
DNS over (D)TLS уже существует RFC 7858, RFC 8310.
> DNS поверх HTTPSПятилетка "закостыливаний во имя прогресса"! Everything over HTTPS.
Майор, ты в курсе, что ключи не обязательно распечатывать на бумаге?
1. И как, оно защищает от блокировок на практике?
2. Есть ли смысл включать WebRender на ноуте с Intel HD?
Webrender стоит попробовать, идея то хорошая. Но пока в моём случае мне не везёт, тормозит оно больше отрисовки через OpenGL. Webrender тормозит у меня на Intel и Nvidia, а в OpenGL летает на том же железе.
Никак особо оно не защищает от блокировок, т.к. они по IP адресу блокируются, оно подделку DNS запросов предотвращает. Хотя у меня с DoH открывается web морда telegram, но так и висит в Connnecting... статусе.
На моём ноутбуке с интелом тормозит больше, греется больше, чем opengl композитор.
Абсолютно аналогичная история.
никак
нет
> противостояния блокировкам на уровне DNSИнтересно, а https://t.me блокирован на каком уровне? DNS или TCP/IP?
Вообщем DoH не прокатит ((( Похоже блокировка на уровне IP:https://dns.google.com/resolve?name=t.me
>Статистика Ping для 149.154.167.99:
> Пакетов: отправлено = 4, получено = 0, потеряно = 4
> (100% потерь)
А есть ли какие-то наработки, которые шифруют конечный маршрут в TCP/IP? Ну что-то типа переменного хеша получаемого от DNS вместо IP адреса который может расшифровать только адресат?
> А есть ли какие-то наработки, которые шифруют конечный маршрут в TCP/IP? Ну
> что-то типа переменного хеша получаемого от DNS вместо IP адреса который
> может расшифровать только адресат?IP пакет идет по IP адресу получателя. Только примитивные блокировки режут резолвинг заблокированного ресурса. Нормальные блокировки работают по IP адресу, который содержится в IP пакете.
Так что, только прокси и VPN.
И это, если не вспоминать dlp системы. Там только VPN с обфускацией.
Нет, IP не для этого.
> А есть ли какие-то наработки, которые шифруют конечный маршрут в TCP/IP?Конечно, Tor называется.
более того, это единственное, для чего он на самом деле был придуман.
О! Круто! Спасибо, не знал.
Правильно! А то привыкли в hosts всякую ерунду прописывать и не дают нормальным трекерам да аналитикам свое шпионское дело делать.
Мы вас всех вылечим!
> Правильно! А то привыкли в hosts всякую ерунду прописывать и не дают
> нормальным трекерам да аналитикам свое шпионское дело делать.
> Мы вас всех вылечим!hosts уже несколько лет перестал работать. По крайней мере для яндекс.директ и т.п. Дополнения к браузеру, типа uBlock работают и через DoH. Так что не набрасывайте.
Нет уж позвольте набросить. Блокировка рекламы/трекеров и прочей дряни на уровне ДНС позволяет намного проще решить проблемы для многих приложений/устройств сразу, независимо от того есть там где-то ublock или нет. Тот же проект pihole для этого и был создан. Под благими намеряниями защиты от якобы товарища майора трафик юзверьков просто все больше централизуют. Гугл в хроме выпиливает адресную строку, естественно тож руководствуюясь исключительно заботой о хомячке.
> Тот же проект pihole для этого и был создан.Да говорю же, что все меньше и меньше работает блокировка через ДНС. Кругом https и джава скрипты. Вырезается только тупая реклама и той становится все меньше.
> Кругом https и джава скрипты.И что? Как это с DNS связано?
> hosts уже несколько лет перестал работать.С чего бы?
У меня всё работает.
Но я пишу не в hosts а в конфиг unbound, типа так:
### Yandex
local-zone: "an.yandex.ru" static
local-zone: "analytics-slb.mobile.yandex.net" static
local-zone: "awaps.yandex.ru" static
local-zone: "bar-navig.yandex.ru" static
local-zone: "button.blogs.yandex.net" static
local-zone: "bs.yandex.ru" static
local-zone: "certificate.mobile.yandex.net" static
local-zone: "http-check-headers.yandex.ru" static
local-zone: "mc.yandex.ru" static
local-zone: "metrika.yandex.ru" static
local-zone: "startup.mobile.yandex.net" static
local-zone: "static-mon.yandex.net" static
local-zone: "ysa-static.passport.yandex.ru" static
local-zone: "ymetrica.com" static
local-zone: "ymetrica1.com" static
local-zone: "ymetrica2.com" static
local-zone: "ymetrica3.com" static
local-zone: "webvisor.com" staticПри этом скажем webvisor.com блочит не только webvisor.com но и *.webvisor.com
Вдогонку https://github.com/StevenBlack/hostsИ скрипт для ленивых, который конвертит hosts в зоны unbound:
#!/bin/bashBLACKLIST_CONF="blacklist_stevenblack.conf"
HOSTS="hosts_stevenblack"rm -f ${BLACKLIST_CONF} ${HOSTS} 2> /dev/null
wget https://raw.githubusercontent.com/StevenBlack/hosts/master/h... -O ${HOSTS}
cat ${HOSTS} | grep -E "^0.0.0.0" | grep -v "0.0.0.0 0.0.0.0" > ${HOSTS}_edited
for i in $(cut -f2 -d " " ${HOSTS}_edited); do
echo local-zone: \"${i}\" redirect >> ${BLACKLIST_CONF}
echo local-data: \"${i} A 0.0.0.0\" >> ${BLACKLIST_CONF}
donerm -f ${HOSTS}_edited
каким образом браузер разрезолвит dns.google.com если я пропишу "https://dns.google.com/" в network.trr.uri?
Да не браузер резолвит, а сервис. Сервис отдает JSON объект в котором браузер находит IP адрес для запрашиваемого хоста. Например: https://dns.google.com/resolve?name=t.me
Он, вероятно, имел ввиду, как браузер найдёт IP самого https://dns.google.com/ по доменному имени dns.google.com
Ааа... точно, извиняюсь тогда )))
TRR prefs https://gist.github.com/bagder/5e29101079e9ac78920ba2fc718aceec
network.trr.bootstrapAddress(default: none) by setting this field to the IP address of the host name used in "network.trr.uri", you can bypass using the system native resolver for it.
>По умолчанию используется DNS-сервер CloudFlare, но его можно изменить через параметр network.trr.uri, например, можно установить "https://dns.google.com/".Что-то Мозилка протормозила, ей нужно срочно свои DNS заводить, а не дарить сатистику каким-то Фларям и Гуглам.
Но это же тогда придётся монетизировать как-то, свои сервера-то. Т.е. барыжить данными пользователей. А так они на коне и в белом - мы заботимся о вашей приватности, поэтому вашими данными не барыжим, а всего лишь направляем DNS-запросы на надежные сервера, а уж как они там и что - это мы не знаем.
вполне возможно, что именно этим они сейчас и занимаются
Странно, обычно они любят так:>Разработчики Мазилы обяжут пользователей принять участие в тестировании функции >обращения к DNS поверх HTTPS (DoH, DNS over HTTPS).
да не, что ты. Обычно они любят по другому - потестируют на малом числе пользователей, и, если наши бизнес-аналитики дают добро - тогда обяжут пользователей пользоваться, уже штатно.
Ну конечно же, добавив стопиццотый параметр (лучше всего скрытый), возвращающий штатное поведение ресолвинга - который выпилят еще версий через пять, но "не такие как все" уже не заметят.
А WebRender-то клёвый! Даже викимапия тормозить перестала. По ходу лиса таки снова торт, ну наконец-то торчиком можно будет пользоваться без слёз.
Дальше будет интереснее. Хозяевам captive portals придётся разрешить https трафик на крупнейшие DoH сервера, как сейчас разрешен https. А дальше хитрые граждане смогут бесплатно гонять через эти сервера Tor на любой платной wifi точке. Но поскольку таких изворотливых граждан вряд ли найдётся много, а заморочей прихлопнуть дырку тоже много, прихлопнут её ещё не скоро.
Ну и это окончательно убьёт всякую возможность на гос уровне блокировать Tor, не заблокировав DNS половине интернета.
...как сейчас разрешен DNSимелось в виду, конечно
Я правильно понял, что с этой фичей провайдер не видит на какие сайты я хожу даже без VPN (имеется ввиду VPN со своим DNS-сервером)?
yep
Не совсем так. По DoH ты получешь ip адрес запрошенного сайта, но потом браузер пойдет за страничкой по выданному ip. Самого сайта (домен) провайдер конечно теперь не увидит, но банить по ip все равно будет.
По VPN провайдер видит только один ip самого впн сервера на который ходят зашифрованные запросы.
нет. провайдер не увидит только dns-запросы, заход на сайт увидит (см. TLS SNI). ещё, в зависимости от настроек сайта, увидит или не увидит какие конкретно страницы ты открываешь на сайте
Вроде DNS over TLS уже есть. Зачем пилить еще одно апи поверх HTTP? Все тоже самое и поддержка на тех же серверах. Преимущества идти в эту сторону не совсем понятны.
Для DoT тебе нужно поднять и настроить unbound или хотя бы stubby. Для DoH ты просто делаешь GET-запрос. Хоть браузером, хоть curl-ом.
> Для DoT тебе нужно поднять и настроить unbound или хотя бы stubby. Для DoH ты просто делаешь GET-запрос. Хоть браузером, хоть curl-ом.Интересно, а каким чудом без "поднять и настроить" вдруг что-то ответит на GET-запрос? Любой HTTP(S) сервер умеет отдавать DoH?
При чём тут сервер? О клиенте речь. На сервере пофиг или около того. Конечно там надо что-то поднять и настроить, чтоб отвечало на запросы, лол, будь это даже легаси-днс без шифрования. А вот на клиенте DoH гораздо лучше, см коммент ниже с цитатами.
Есть надежда, что в стандартный резолвер когда-нибудь встроят. Засунули же когда-то туда всякие NIS'ы.
> Преимущества идти в эту сторону не совсем понятны.А люди наоборот считают, что dns over tls никаких преимуществ не имеет и не нужен.
https://github.com/jedisct1/dnscrypt-proxy/issues/68
> Implementing DNS-over-TLS is not planned since it provides no benefits over DNS-over-HTTP/2.https://dnscrypt.info/faq/
> DNS over TLS (RFC7858)
> Uses a dedicated port (853) likely to be blocked or monitored in situations where DNS encryption is useful
> Not well understood even by its proponents. It is a truck, as it is heavy and slow to load, but most if not all implementations perform a full round trip for every packet (even the excellent
> Padding rules haven’t been specified besides a draft that doesn’t have any implementations, and a last-minute hack that requires altering DNS record sets before wrapping them
> Will be bifficult to improve without introducing more hacks. Unlikely to benefit from any improvements besides new TLS versions or homegrown reinventions.
> Questionable practical benefits over DoH
>> Преимущества идти в эту сторону не совсем понятны.
> А люди наоборот считают, что dns over tls никаких преимуществ не имеет и не нужен.Там один людь.
А нас, с тезкой - уже двое. И ссылаться на автора софтины, утверждающего что днс-через-шифроканал днс-через-овердо*ренаинжыниред-гугл-протокол не имеет преимуществ, сама по себе странная аргументация.
> Там один людь.Количество серверов и клиентов DoTLS и DoH и их качество наглядно демонстрирует.
> А нас, с тезкой - уже двое.И какие ваши аргументы?
DNS over HTTPS/TLS для домашнего провайдера не актуален особо. Даже блокировки РКН реализуются не через подмены DNS, а через IP. А вот для публичных сетей такое может быть востребовано, несколько раз сталкивался, когда при открытии VK/FB какие-то умельцы вставляли явно свойские баннеры услуг провайдера и пр. Обычный DNSSEC тут мог бы тоже помочь, но его настраивают 1.5 админа из 10, а используют в 3 раза меньше пользователей.
>> Там один людь.
> Количество серверов и клиентов DoTLS и DoH и их качество наглядно демонстрирует.Какое количество? Что демонстрирует? И почему вы вообще решили, что там есть взаимосвязь?
>> А нас, с тезкой - уже двое.
> И какие ваши аргументы?
> днс-через-шифроканал vs. днс-через-овердо*ренаинжыниред-гуглo-протокол
И где аргумент-то? Если ты назвал протокол оверинженеридгугловским, то от этого он таким не становится.
А вот dns over tls ужасен и настолько недодуман и недоделан, что работает даже хуже чем https (в котором тоже есть tls), как написано в тех цитатах. Есть что ответить на них?
Или вы застряли во временах http 1.1 и ничего не знаете про второй?
> И где аргумент-то? Если ты назвал протокол оверинженеридгугловским, то от этого он таким не становится.Ну, если аноним так говорит, то значит так оно и есть! Куда там всяким Пол-Хеннинг Кампам до него …
https://queue.acm.org/detail.cfm?id=2716278
> HTTP/2.0 is not a technical masterpiece. It has layering violations, inconsistencies, needless complexity, bad compromises, misses a lot of ripe opportunities, etc.
> The IETF, obviously fearing irrelevance, hastily "discovered" that the HTTP/1.1 protocol needed an update, and tasked a working group with preparing it on an unrealistically short schedule. This ruled out any basis for the new HTTP/2.0 other than the SPDY protocol.
>
включил эту штуку, вроде работает и то и другое.
Если у меня dnscrypt-proxy мне это надо???
Что бы провайдер не палил подойдет или тор только спасет?
нет!ты и так весь за криптован, как параноидал, живи спокойно теперь
Включил на последнем Mintlayers.acceleration.force-enabled
и
gfx.webrender.enabledПерезапустил.
Композитинг в about:support всё ещё OpenGL.
ЧЯДНТ?
Делаешь это не на firefox nightly. Скачай бинарную сборку с сайта тормозилы.
MOZ_ACCELERATED=1 MOZ_WEBRENDER=1 firefox — запусти вот так, работает и в stable выпусках.
Кайфец, заработало! Спасибо большое)
> Кайфец, заработало! Спасибо большое)А как с производительностью?
>например, можно установить "https://dns.google.com/".А это собственно как резолвиться будет?
Мозг включи, обыкновенный резолвер никто не отменял, через него он и резолвится, а DNS over HTTPS просто на этот адрес шлёт по HTTPS запросы get, а в ответ получает ответы в JSON, которые интерпретирует как DNS и по указанным там IP тоже шлёт get'ы и получает в ответ уже HTML'ки/JS'ы.
Что будет со всякими сетями которые не Интернет?
Если он не отвечает - будет откат к стандартному dns?
Нужно будет вытащить в интернет, этого и добиваемся
Есть какие-нибудь ещё приватные DoH-серверы?
DoH-серверы - https://en.wikipedia.org/wiki/Public_recursive_name_server
Приватные - во 1, DoH для этого не очень, во 2 - доверять можно только тому, что хостишь самостоятельно (или хотя бы настраивал самостоятельно на арендованном сервере)
> Вместо этого применяются шейдеры, выполняемые в GPU, что позволяет добиться существенного увеличения скорости отрисовки.Майнеры на CSS3 и ECMAScripts одобряют.
Глупость несусветная да и курам насмех типа прятать от одних и показывать все другим, и на это еще расходовать ресурсы... да пускай кто что хочет тот и смотрит в чем проблема ?
э нет, вот в этом-то и проблема - "кто хочет" пусть идет к нам, с длинным чеком на энную сумму, а не каждый сам себе что-то там подглядывает без дележки с нами.
Спасибо автору, для меня много нового и интересного, сп
DoH не нужен.
ЗЫ.
Пользую 8.8.8.8 и счастлив.
нас не устраивает тот факт, что твой провайдер прекрасно может подменить его своим, и мы не увидим твоих dns запросов. Поэтому мы попросили мурзилу сделать вот такое.
network.trr.mode =3
network.trr.uri DNS-сервер CloudFlare
результат IP Address 2500:cv.............
ISP CloudFlare
Location Russia
что то я не хочу днс такой. как изменить на забугорный?
network.trr.bootstrapAddress на любой адрес облака CF. У них же полнейший anycast во все дыры. Можно и сайтам за CF адреса менять в hosts, люди так блокировки по IP обходили.
если network.trr.mode 2 -то видно внутренний ip
если network.trr.mode 3 - нет подключкеия к интернету
ты DoH сервер добавил вообще?
попробуй network.trr.uri https://1.1.1.1/dns-query
ты DoH сервер добавил вообще?
вот я ж написал.
попробуй network.trr.uri https://1.1.1.1/dns-query
тоже самое 172.68.14.195 Russia
2500:cv000 Russia
вот я ж напISP CloudFlare
dns over https не нужен, нужно либо dns over tls (без обверхеда от http), а лучше dnscrypt, либо dnscurve
> нужно либо dns over tls (без обверхеда от http)Скорее без оптимизаций от http. См https://www.opennet.ru/openforum/vsluhforumID3/115285.html#100
> а лучше dnscryptЧем лучше?
После принудительной замены версии браузера, теперь после выставления параметра network.trr.mode 3 только DoH интернета нет.
А как всё весело начиналось. Ребята, долго учившиеся кубировать снег и отморозившие то, где у нормальных людей находится мозг, видимо сильно не довольны.