В браузере ведь есть настройка DNS Over HTTPS. + На уровне системы тоже задан DNS 1.1.1.1
Будет-ли какой-то смысл в использовании DNSCrypt?

Если провайдер не перехватывает обращения к сторонним DNS, то разница вряд ли будет заметна.
Домру перехватывает, других таких я не знаю
Влиять будет только на проги, в которых нет встроенной поддержки DoH

Как узнать, перехватывает или нет?

Даже если нет спуфинга от вашего ISP, то локальный DNS кэш уменьшит задержку перед отображением сайта (у меня, например, по статистике 60-70% запросов разрешаются из кэша). Ещё можно настроить политики фильтрации.

Вроде же кэш DNS и так существует в системе, или я что-то путаю?
Ну тот, который очищается на ipconfig /flushdns

В системном нет Serve Stale (на клаудфлере и гугле он включен, но на резолвере ISP зачастую администраторы забывают включить и тогда можно получить ошибку разрешения при достижении Query Rate Limit). Если в браузере настроен DoH, то системный не используется. В DoH долгий RTT.

В принципе на скорость загрузки сайтов не жалуюсь особо.

Лукапнуть парочку сайтов из запрещенки через 1.1.1.1
Если возвращается один и тот же адрес, значит есть перехват

Как это сделать?

Ещё удобно локальный резолвер использовать для различных политик выбора IPv4/IPv6:

services:
# SOCKS5 с предподчтением IPv4
- name: service-direct-4
  addr: "[::1]:1080"
  interface: "LAN"
  resolver: resolver-local-4
  handler:
    type: socks5
    metadata:
      bind: true
      notls: true
      udp: true
      udpBufferSize: 4096
  listener:
    type: tcp
# SOCKS5 с только IPv4
- name: service-direct-4-only
  addr: "[::1]:1081"
  interface: "LAN"
  resolver: resolver-local-4-only
  handler:
    type: socks5
    metadata:
      bind: true
      notls: true
      udp: true
      udpBufferSize: 4096
  listener:
    type: tcp
# SOCKS5 с предподчтением IPv6
- name: service-direct-6
  addr: "[::1]:1082"
  interface: "OpenVPN DCO"
  resolver: resolver-local-6
  handler:
    type: socks5
    metadata:
      bind: true
      notls: true
      udp: true
      udpBufferSize: 4096
  listener:
    type: tcp
# SOCKS5 с только IPv6
- name: service-direct-6-only
  addr: "[::1]:1083"
  interface: "Tunnel 4to6"
  resolver: resolver-local-6-only
  handler:
    type: socks5
    metadata:
      bind: true
      notls: true
      udp: true
      udpBufferSize: 4096
  listener:
    type: tcp

# DNS resolver
resolvers:
- name: resolver-local-4
  nameservers:
  - addr: "udp://[::1]:53"
    ttl: -1
    prefer: ipv4
- name: resolver-local-4-only
  nameservers:
  - addr: "udp://[::1]:53"
    ttl: -1
    only: ipv4
- name: resolver-local-6
  nameservers:
  - addr: "udp://[::1]:53"
    ttl: -1
    prefer: ipv6
- name: resolver-local-6-only
  nameservers:
  - addr: "udp://[::1]:53"
    ttl: -1
    only: ipv6

В браузерном расширении ZeroOmega можно настроить домены на разные прокси и получать необходимые эффекты.

Не включили у нас

У меня тоже нет, но получаю его на своих тунелях, варпе и проксях.

А при использовании VPN DNSCrypt это вообще безопасно? Я включал DNSCrypt в связке с VPN и проверял у себя ситуацию на Anonymity check

У меня писало что яко-бы утечка DNS.

В DNSCrypt ничего не переделывал перед этим, на стандартных настройках было.

Утечка не связана с тунелированием. В настройках ваших сетевых адаптеров нужно указать один локальный, все остальные убрать. Система использует все указанные резолверы параллельно. Можно даже 53 порт заблокировать в брандмауэре на всякий случай.

Указывал 127.0.0.1

Там у меня выдало какой-то один из DNS, которые эта программа автоматически загружает там с гитхаба откуда-то. Тоесть не мой DNS провайдера.
Но почему-то он был подписан как утечка.

Эти сервисы по проверке утечек подписывают всё как утечка по умолчанию кроме белого списка. На приписку можно забить.

А реальная утечка получается это только когда DNS провайдера выпадает, всё остальное не утечка?

Утечка то, что вы интерпретируете как утечку. Если там нет сетей вашего провайдера, значит скорее всего резолвятся имена не через вашего провайдера. Надёжнее будет посмотреть в снифер пакетов что у вас там бегает в открытую. Сайтов, которые ограничивают региональный доступ по утечке DNS я пока не встречал.

Да сайтов то понятно. А что по поводу провайдера? Он видит какие у меня DNS???

для меня утечка это когда я вижу русские флаги, а по умолчанию в насторйке dnscrypt они будут, те сервера нужно убрать. в том числе и клаудфлер

а вообще в последнее время я все чаще замечаю себя в прописывание любимых сайтов в хостс. в dnscrypt это можно через cloaking-rules

Если видете вы у себя в снифере, то видит и ISP.

А как вы их убираете? Они же берутся откуда-то из интернета в готовом виде уже вся пачка.

Где такой скачать?

Можно так.

Wireshark

в dnscrypt-proxy помимо прочего есть такая опция в .toml

# p2 (randomly choose between the top 2 fastest servers)
# ph (randomly choose between the top fastest half of all servers)
lb_strategy = "ph"
lb_estimator = true

что ИМХО лучше и надежней чем ломится в 1.1.1.1 ИЛИ 8.8.8.8 ну и т.п.
хотя бывают неожиданные результаты (один из серверов dnscrypt не ресолвит vk.com)

p.s. для windows кто не хочет/умеет возиться с командной строкой есть GUI

11260×313 19.8 KB

Почему с DNSCrypt пропала защита SNI???
Когда DoH в браузере включён, она есть.

И посоветуйте какой режим лучше в DNSCrypt
Именно протокол DNSCrypt или DoH??
Ну тоесть сервера какие использовать?
Какой более надёжный??
Или оба варианта можно?

ESNI пока работает через настроенный DoH в браузерах.

Но если я запущу DoH в браузере тогда браузер будет в обход DNSCrypt работать. Я всё-равно не понимаю зачем это нужно в таком случаи. У меня кроме браузера тут особо другого траффика не идёт.

Если нет пока понимания, тогда можно ничего не трогать.

Нет, ну я хочу разобраться, ну если я включу DoH в браузере, тогда браузер мой будет в обход этого DNSCrypt работать. Правильно же?

А если я выключаю DoH в браузере то пропадает защита SNI…

Да. Видимо надо ждать поддержки со строны браузеров. А они этого не делают, потому что у большинства пользователей резолвер от ISP и смысла нет сертификат запрашивать через DNS в открытую для домена чтобы его спрятать потом в TLS хэндшейке.

Ну у меня не резолвер от ISP я DNS провайдера не использую у меня даже на роутере 1.1.1.1. Вот я выключаю DoH если в браузере и выбираю DNS сервера себе в DNSCrypt, тогда по идее DNS-запросы пойдут через те сервера которые я выбрал, но при этом ECH не появляется в браузере. Почему? Простыми словами можно?

ESNI придуман интернет-гигантами чтобы корпоративные файрволы не могли обрубать рекламу сотрудникам, фильтруя DNS запросы, HTTP, SNI в рукопожатиии TLS. ESNI поддерживается браузерами получая ключ для сокрытия SNI через DoH. Получать ключ через обычный DNS смысла нет, т.к. домен виден и возможно применение политики фильтрации. Поэтому разработчики браузеров не добавляют получение ключа по обычному DNS (либо им не заплатили интернет-гиганты).

Понятно, ну тоесть а какие плюсы то по итогу от этого DNSCrypt???

Выше писал, скорее больший плюс от использования локального резолвера для кэширования и фильтрации (винда например постоянно телеметрию дёргает), а DNScrypt позволяет исключить единую точку отказа (на форуме бывают сообщения о блокировках популярных DoH) и ускоряет получение результата ввиду отсутствия рукопожатия TCP/TLS (хотя в DNScrypt большие пакеты проверок DNSSEC всё равно идут через TCP).

Чёртов сайт свои лимиты в 20 сообщений в день мне пихает, но не важно.

Но на браузер кэширование DNS-запросов никак распространяться не будет получается если включённый DoH браузера держать. Загрузку страниц так не ускорить получается, это только отключать DoH браузера, а этого я делать не буду.

И что в итоге
Ускорение телеметрии (???)
(Которую я кстати вырезал из своей винды прогой одной)

В браузере свой кэш, но он почти не управляем.

Да, общий кэш для локальной сети и системы не будет использован, только кэш браузера. В браузерах есть какие-то предзагрузки (dns-prefetch), которые могут нивелировать задержки.

Я тоже вырезал всё что возможно, но всё равно фильтры срабатывают.

Работать будет без изменений настроек браузера. Но ввиду ужесточения цензуры полезно знать что можно сделать, если вдруг браузер перестанет открывать сайты.

А если я выключаю DoH в браузере то пропадает защита SNI

Браузеры могут работать с ECH даже без включенного DoH в них, но менее надёжно. Только в России ECH блочится, без zapret.

Проверял и с Zapret. Тоже самое.

В утилите можно установить определенный список избранных серверов.

Есть ли где-то инструкция, как вообще утилиту идеально можно настроить?

Я вижу Вы специалист по утилите. Можете сюда или в личку скинуть свой dnscrypt-proxy.toml с настройками? Интересуют и настройки, и список избранных серверов.

Проверял

Забыл добавить. Проверять надо бы в Wireshark, виден ли там SNI. Сайт проверки это ненадёжно.

Ссылку с примером выше скидывал. Избранные сервера меняются со временем (я себе настроил от разных администраторов в разных странах). Все настройки с описаниями можно глянуть в example-dnscrypt-proxy.toml (его же можно и запустить без изменений).

В утилите можно установить определенный список избранных серверов

Конечно. Нужно в dnscrypt-proxy.toml указать их имена:
server_names = ['cloudflare', 'google']
взятые из public-resolvers.md.

Прочитал, но так и не понял, как установить и настроить Technitium DNS Server и соединить с dnscrypt-proxy.

у меня много браузеров (firefox, firefox ESR, brave, maxthon) для разных целей
поэтому лично мне проще/удобней dnscrypt-proxy (+как резерв Technitium DNS с 10 разными серверами)

мне DoH не нравится

1. 1 “сервер”
2. много блокировок по IP стало. банят сразу “сеть”/хостера
3. у многих были проблемы с SNI. и как раз с ESNI cloudflare Обсуждение: Блокировка (замедление) ECH Cloudflare

4. если и есть кэш то работает только для 1 браузера

p.s. в dnscrypt-proxy тоже встроено много DoH. хотя у меня обычно отключено по личным предпочтениям
ipv4_servers = true
ipv6_servers = true
doh_servers = false

Скачать с сайта архив, распаковать инсталятор и запустить его двойным кликом левой кнопки мыши. По умолчанию он будет работать как рекурсивный резолвер.

Необходимо добавить форвардеры как написано в сообщении.

про Technitium DNS
решает каждый сам.
но я включил
+Enable Concurrent Forwarding
+Forwarder Concurrency 10 (valid range 1-10; default 2)
p.s.
а еще
+Forwarder Protocol DNS-over-TLS (это где по дефолту :853)
если уж Ростелеком будет блочить/перенаправлять все dns/53-udp
сейчас они вроде только AdGuard DNS блочат. по DoH/SNI или даже по IP гдето

У меня нет в утилите тех кусков кода, которые Вы там скопировали. В общем, для новичка это темный лес. Нужна инструкция со скриншотами настройки и объединения двух утилит. Иначе лично у меня не получается настроить. Я не айтишник.

Использую dnscrypt как запасной, основной - unbound с DoT-forwarders.
Конфигурация dnscrypt зависит от версии, даже при переходе 2.0.х и 2.1.х приходится править конфиги, тот же параметр bootstrap_resolvers вместо fallback_resolver.

Имеет, замени им клоудфлаер. А сам dnscrypt покрой tls

ECH врубал ток через конфиг файл. раньше использовал гуи, потом забил.

На примере Дом.ру:

Резолвим что-то заблокированное через публичный plain-text DNS:
nslookup navalny.com 8.8.8.8

Получаем IP-адрес. Пробиваем через WHOIS, кому он принадлежит. Он принадлежит Дом.ру.

Либо сайт Навального хостится у Дом.ру, что неверноятно, либо Дом.ру просто берёт и весь трафик по 53 порту заворачивает на свой резолвер, который домены, к которым должен ограничиваться доступ, резолвит в “левый” адрес. Запрос до DNS Гугла даже не дошёл.

В этом и заключается недостаток протокола DNS - спрашивали один резолвер, а вместо него ответил вообще другой. Позже для решения этой проблемы к протоколу прикрутили костыль в виде DNSSEC, но он не то, чтобы “взлетел”.

Что касается DNSCrypt, то нужно разделять протокол и эталонный клиент (dnscrypt-proxy). Протокол использовать нет смысла. Он свою роль сыграл - это была первая ласточка в шифровании DNS. Затем пояаились DoH и DoT, которые получили статус стандартов. Кроме того, протокол DNSCrypt стороннему наблюдателю намного легче обнаружить и заблокироать, чем DoH.

Клиент dnscrypt-proxy использовать, может, и имеет смысл (он поддерживает DoH/DoT в том числе), например, он позволяет прикручивать списки доменов, которые запрещено резолвить, тем самым, можно бороться с рекламой. Но с тем же успехом, например, можно использовать AdGuard Home. То есть, использовать если и имеет смысл, то именно ПО, а не протокол.

Если просто нужно шифровать DNS-трафик. используйте DoH, поддержка которого есть и в браузерах, и в современных операционных системах.

Протокол использовать нет смысла

Разве что может быть меньше задержка, т.к. протокол dnscrypt по умолчанию использут udp, а DoH tcp (за исключением dns over quic, кстати dnscrypt клиент и такое поддерживает). Но это надо разбираться и насколько критична первая задержка (остальные запросы могут кэшироваться).

протокол DNSCrypt стороннему наблюдателю намного легче обнаружить и заблокироать, чем DoH

Ирония в том, что когда на йоте кончились деньги dnscrypt запросы проходили. Т.к. маленькие и udp (подтверждение протокола не требовали). Но тогда dnscrypt специально не блокировали. Впрочем, может и обычный dns работал, но DoH врядли.

В общем, dnscrypt протокол вроде как нестандарт и легче детектится (например, в пакетах видны сертификаты dnscrypt серверов). DoH выглядит как https, но публичные сервисы у всех на виду и могут быть заблокированы по IP. Малопопулярные custom решения интересны в обоих случаях, разве что dnscrypt udp не переживёт белые списки протоколов.

Это не аргумент против DoH, т.к. публичные сервисы DNSCrypt тоже у всех на виду и зачастую все эти публичные DNS лежат буквально на одной странице.

DoH там тоже лежат.
Кстати, если dns сервисы заблокируют по SNI, может помочь zapret? Как с ECH.

Почему бы и нет, там же DNS-over-HTTPS, т.е. сначала устанавливается HTTPS-соединение, тут-то zapret и поможет.

А есть смысл на ПК объединять как выше писали dnscrypt-proxy и Technitium DNS? Или несколько серверов в dnscrypt-proxy вполне достаточно с Запретом?
Кстати, есть смысл вместо избранных серверов использовать ДНС штампы?

может быть меньше задержка, т.к. протокол dnscrypt по умолчанию использует udp

С другой стороны, есть ещё такая вещь, если вы постоянно пользуетесь udp based vpn, то udp over udp не очень хорошая идея, я так считаю, в плане скорости. Хотя, в dns размеры пакетов маленькие и может быть некритично. Но кстати, dnscrypt протокол может работать по tcp, вроде как.

Чем мне не нравится DoH в браузере, судя по wireshark, браузер часто держит соединение с ним. У меня же Brave с отрезанными крыльями вообще молчит, это приятно. И DoH запросы выбиваются из этого блаженства. Впрочем, если у вас браузеры стучат налево и направо, как и система, то вы тишину не оцените.

Да, как и в обычном DNS если размер дейтаграммы превышает MaxDNSUDPPacketSize то подключение идёт по TCP, иначе дейтаграмма фрагментируется.

Можно попробовать в аргументы командной строки запуска chromium-based браузера добавить --disable-background-networking --disable-component-extensions-with-background-pages --dns-prefetch-disable.

Поставил dnscrypt-proxy из репы. Чёто с ними столько гемора, как всегда.

Проще взять свежий из гита, скачать в opt и запустить с ключом (не помню, install или service) на люнюксах он сам создаёт юнит и в пакете есть типовой конфиг, который можно немного подкрутить. Готовый конфиг под 2.1 могу кинуть. Единственный момент - из репы он идёт с поддержкой сокета и там listener пустой. С гита он идёт сам по себе и там надо указать адрес в listener.

UPD: dnscrypt-proxy -service install

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

Да, это вроде просто. Я уже и подзабыл команды.

ну там много удобных/полезных вещей

## Forward queries for .onion names to a local Tor client
## Tor must be configured with the following in the torrc file:
## DNSPort 9053
## AutomapHostsOnResolve 1

onion				127.0.4.1,127.0.2.1

www.google.*             forcesafesearch.google.com

www.bing.com             strict.bing.com

yandex.ru                familysearch.yandex.ru       # inline comments are allowed after a pound sign

=duckduckgo.com          safe.duckduckgo.com

www.youtube.com          restrictmoderate.youtube.com
m.youtube.com            restrictmoderate.youtube.com

Это можно настроить в любом DNS сервере. Наоборот, полную спецификацию рекомендаций из RFC по реализации резолвера не поддерживает, поэтому лучше перед ним ставить какой-нибудь bind9, unbound или TDNS с настройками форвардинга, добавив ещё TLD из opennic.org.

Вопрос в том, как новичку все это настроить… Вчера попросил здесь скриншоты скинуть по объединению днскрипто-прокси и TDNS - никто не сподобился создать мини-инструкцию. Зато тратить время и умничать в темах - времени вагон…

Так вы даже не пробовали, и вопросы уточняющие не задаёте.

Что-то уж больно большой overhead в dnscrypt tcp. В конфиге указано два резолвера:
scaleway-fr (212.47.228.136:443)
ams-dnscrypt-nl (89.38.131.38:4343)
Открываю сайт ipecho.net (34.160.111.145).

dnscrypt tcp

dnscrypt1266×393 201 KB

1.1.1.1 udp нешифрованный

dns1266×128 60.9 KB

Как видите на первом скрине уже даже с сайтом коннект начал устанавливаться, а ответы от dnscrypt сервера всё летят.
Попробую udp.

Я установил давно днскрипто-прокси и вчера TDNS. Все работает вместе или после отключения по отдельности. Что дальше делать, какая инструкция? Откуда мне взять 6 стабильных серверов и релеев? Какого вида они должны быть?

Там по TCP гоняются подписи DNSSEC, если кэширование настроено на stub резолвере, то их количество минимально.

Запускаете dnscrypt-proxy с конфигом example-dnscrypt-proxy.toml с опциями

doh_servers = false
odoh_servers = false
require_dnssec = true
require_nolog = true
require_nofilter = true

В выводе консоли будет список рабочих серверов. Их штампы можно скопировать в отдельный конфигурационный файл. Релеи можно пока не настраивать. Со временем какие-то из них будут отваливаться, тогда нужно найти замену.

Для простоты можно для начала настроить работу stub-резолвера на один экземпляр dnscrypt-proxy.

Работающего вида у вашего провайдера.

По udp запросов меньше, но они тоже жирные. Раз в 5 жирнее обычного dns. И чем больше резолверов указано, тем больше запросов.

dnscrypt udp

udp945×70 22.4 KB

А что мне это даст, какие преимущества по сравнению с дефолтным запуском утилиты? Пока не понимаю.

Конфигурацию сохранить в txt файл и рядом с утилитой сохранить? Сейчас утилита работает без вывода консоли.

Concurrency и как вследствие resiliency. Дополнительные настройки политик кэширования, блокировок. Если пока не понятно, то наверное, вам пока и не нужно.

Для запуска с конфигурационным файлом необходимо его указать в аргументах командной строки:

dnscrypt-proxy.exe -config dnscrypt-proxy_1.toml

Да, для меня это пока сложно. Нужна инструкция со всеми пунктами и скриншотами. Иначе не понимаю что делать. Я погуглил и не нашел на русском инструкций. Видимо, мало кто использует такие сложности комбинации двух утилит.

Моя рекомендация предполагала, что пользователь умеет пользоваться этими программами по отдельности. Скриншоты не понятно как делать, т.к. найдётся пользователь, который скриншоты не поймёт и нужно будет делать ещё.

Я днскрипто-прокси устанавливал первый раз по инструкции этого автора. Все написано подробно и понятно для любого новичка. У меня получилось с первого раза.
И утилита прекрасно работает.
А как объединить по Вашим сообщениям я не могу понять.

К тому же по Вашей инструкции утилиту нужно пропатчить. Новичок не сможет все это сделать без подробной инструкции, как у автора выше.
Нужно Вам было скинуть на файлообменник пропатченную утилиту и конфигурации - только убрать свои данные и оставить поля пустыми для самостоятельного заполнения другими людьми.

Смысл будет иметь, в случае, когда doh’и станут dohлые

Вроде бы здесь https://www.dnscheck.tools/ можно проверить задержку dns. Обычно она больше транспортной задержки, т.к. резолверу надо обработать ваш запрос, получить адреса. А может на сервере резолвера канал или проц перегружены и ваш запрос долго находится в очереди.

Для решения проблемы долгого ответа как раз идеально подходит локальный unbound. Во-первых, кэш, во-вторых, у него есть замечательный prefetch, который сам освежает адреса перед их истечением.

У меня сейчас в prefetch больше 8k записей, то есть фактически они запрашиваются заранее, а не в момент обращения.

Ну и соответственно, эффективность обращений высокая, практически 75% запросов разрешаются локально. Это с учетом того, что 6 дней назад был перезапуск и кэш+prefetch обнулялись…

image1632×328 29.3 KB

Это не необходимость, а рекомендация для снижения вероятности ошибки разрешения имени.

jedisct1-bin.7z (2.7 MB)
jedisct1-src.7z (172.1 KB)

dnscrypt-proxy активно развивается и бинарники скоро потеряют актуальность.

В TDNS, например, есть возможность сохранять кэш на диск (включена по умолчанию).

Утилита вчера была обновлена на Гитхабе. Пропатчена уже свежая версия?

Конечно, только что произвёл слияние, компиляцию и накатывание на свой сервер для проверки. Тестовый конфиг тоже проверил несколько раз.

Если у моего провайдера только IPv4, а не 6, то мне в TDNS нужно прописывать форвардеры такого типа?:

"127.0.0.1:1053",
"127.0.0.1:1153",
"127.0.0.1:1253",
"127.0.0.1:1353",
"127.0.0.1:1453",
"127.0.0.1:1553"

[::1] работает по умолчанию начиная с Windows Vista вне зависимости от поддержки провайдера. Для lookpback принципиальной разницы нет. Если у вас нет глобального IPv6 адреса то IPv6 сервера и релеи не будут для вас доступны.

Если не используешь дополнительные функции вроде запрета определённых доменов, перенаправления определённых адресов (например личный кабинет провайдера интернета или локальный сайт) на днс провайдера, замены айпи для определённых адресов (например, для сервера картинок твиттера чтобы он пробивался гудбаем/баем/запретом), то особо нет.

А есть смысл ставить днс с самым малым временем ответа,например, в реальности при открытии сайтов будет видно разницу с днс который допустим отвечает за 30 МС, а другой за 50мс? Или все нивелирует кэширование браузера и всякие фишки типо предзагрузки страницы в хроме

Да, mullvad’овский DoH заблочен, с zapret’ом работает в их браузере

Вы, наверное, пишете про какую-то реализацию протокола, а не сам протокол. Протокол защищает клиента от спуфинга на стороне ISP.

FAQ

Я про дополнительный функционал DNSCrypt.
Как я понял, вопрос автора темы состоял в том, нужен ли ему DNSCrypt если у него в браузере уже есть опция включения защищённого днс.

Смысл есть, т.к. dnscrypt-proxy шифрует все системные запросы. Хотя, на новых виндах DoH тоже можно включить для системы, но не на линуксах.

Враки В арче уже сто лет есть пакет dns-over-https

если я выключаю DoH в браузере то пропадает защита SNI

Brave 1.61.120 (Chromium 120.0.6099.234) в Ubuntu 22.04. В chrome://flags #encrypted-client-hello Enabled (в новых хромах нет этого флага, ECH включен по умолчанию и отключается другими способами). Безопасный dns резолвер в браузере отключен. Установлен dnscrypt-proxy 2.1.7 и в системе указан его dns (127.0.0.1). NL VPN.

1. В Wireshark с фильтром frame contains "rutracker" тишина, т.е. ECH работает.
2. Эти сайты показывают OK https://www.cloudflare.com/ssl/encrypted-sni/ (только определение Secure DNS под вопросом, но оно secure)
   https://tls-ech.dev/
3. Этот не OK https://defo.ie/ech-check.php

Но как я сказал, это менее надёжно. Если DoH включен в браузере, браузер обязан использовать ECH и показывать ошибку в случае проблем. Хромобраузеры так себя и ведут, а лисобраузеры загружают без ECH (в случае, если ECH, блочится провайдером, например) после нескольких обновлений страницы.

Если DoH в браузере отключен, браузер может не знать о наличии шифрования dns в других местах (на роутере, в проге dnscrypt-proxy), но всё равно пытается использовать ECH. И кстати, у него получится даже с plain text dns, не говоря о dnscrypt. Другое дело, что если ECH блочится провайдером, без включенного DoH в браузере, браузер перестанет использовать ECH для домена, т.е. не будет шифровать dns. В этом заключается ненадёжность стороннего шифрования dns. В России как известно ECH блочится провайдерами и нужен zapret. Если вы пользуетесь VPN (как я), ECH будет работать (и с dnscrypt-proxy и с plain text dns). И вы сможете спрятать домены (dns и sni) от владельца VPN при использовании dnscrypt. Но в основном только на сайтах с Cloudflare.

dnscrypt стал ожидаемо тупить. Переключил его на doh, не помогло. Кроме того, в doh overhead ещё больше, в разы и время реакции под 600 мс (cloudflare, google). Снёс.

Топ серверов по времени отклика

[2025-01-20 08:52:50] [NOTICE] -     4ms dnscry.pt-moscow-ipv4
[2025-01-20 08:52:50] [NOTICE] -     7ms cloudflare
[2025-01-20 08:52:50] [NOTICE] -    17ms dnscry.pt-vilnius-ipv4
[2025-01-20 08:52:50] [NOTICE] -    20ms cs-finland
[2025-01-20 08:52:50] [NOTICE] -    22ms quad9-dnscrypt-ip4-nofilter-pri
[2025-01-20 08:52:50] [NOTICE] -    22ms quad9-dnscrypt-ip4-nofilter-ecs-pri
[2025-01-20 08:52:50] [NOTICE] -    22ms dnscry.pt-tallinn-ipv4
[2025-01-20 08:52:50] [NOTICE] -    22ms quad9-doh-ip4-port443-nofilter-pri
[2025-01-20 08:52:50] [NOTICE] -    22ms quad9-doh-ip4-port443-nofilter-ecs-pri
[2025-01-20 08:52:50] [NOTICE] -    23ms dnscry.pt-warsaw02-ipv4
[2025-01-20 08:52:50] [NOTICE] -    23ms nextdns
[2025-01-20 08:52:50] [NOTICE] -    23ms dns0-unfiltered
[2025-01-20 08:52:50] [NOTICE] -    24ms controld-uncensored
[2025-01-20 08:52:50] [NOTICE] -    24ms nextdns-ultralow
[2025-01-20 08:52:50] [NOTICE] -    24ms dnscry.pt-riga-ipv4

Первый запрос:

dig @127.0.2.1 google.com

; <<>> DiG 9.18.30-0ubuntu0.24.04.1-Ubuntu <<>> @127.0.2.1 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4748
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		2400	IN	A	172.217.16.206

;; Query time: 62 msec
;; SERVER: 127.0.2.1#53(127.0.2.1) (UDP)
;; WHEN: Mon Jan 20 09:16:34 MSK 2025
;; MSG SIZE  rcvd: 55

Дальше конечно уже кэш и ответ мгновенный

Ну, не знаю. Лично видел в логе, что cloudflare и google doh в dnscrypt показывали 600 мс. Может, какой-то баг.
В первой таблице dnscrypt проверяет транспортный пинг, я так понял. А во втором логе это уже время на обработку. Кстати, как можете видеть, полная обработка запроса в 3 раза дольше (62 мс против 22 мс). А у меня только пинг до серверов 160 мс, т.к. я под VPN (Сибирь - Нидерланды и ещё сотовая связь 20 мс добавляет).

Судя по wireshark, doh в dncrypt гоняет много трафика туда сюда. Т.е. 160 мс задержки складываются. Поэтому я и говорил об overhead. Вам в Москве до московского doh, конечно будет быстро.

Ну это не москва, но ЦФО. Такие задержки мне не мешают, потому что у меня перед dns-ами стоит unbound, как я выше писал. Он сам обновляет записи через доступные ему способы (прямой Dot или dnscrypt), потому он задержки получает, а я уже нет.

DoH и не может быть быстрым
в том числе потому что оно вначале делает DNS запрос сервера
ну и сам HTTPS имхо далеко от даже TLS и тем более UDP/53

doggo @1.1.1.1 --time --color=false A AAAA HTTPS rutracker.org
rutracker.org. A 104.21.32.39 1.1.1.1:53 34ms

doggo @tls://1.1.1.1 --time A AAAA HTTPS rutracker.org
rutracker.org. A 172.67.182.196 1.1.1.1:853 172ms

doggo @https://one.one.one.one/dns-query --time A AAAA HTTPS rutracker.org
rutracker.org. A 172.67.182.196 https://one.one.one.one/dns-query 235ms

doggo @quic://dns.adguard-dns.com --time A AAAA vk.com
vk.com. A 87.240.137.164 dns.adguard-dns.com:853 2091ms

doggo @https://doh.opendns.com/dns-query --time A AAAA vk.com
vk.com. A 87.240.129.133 https://doh.opendns.com/dns-query 929ms

doggo @tls://dns.google --time A AAAA vk.com
vk.com. A 87.240.137.164 dns.google:853 160ms

Я вам наверное открою заново америку, но домен в doh указывать вовсе необязательно, можно и голый айпишнег

монопесуально.

doggo @https://1.1.1.1/dns-query --time A AAAA HTTPS rutracker.org
rutracker.org. A 172.67.182.196 https://1.1.1.1/dns-query 224ms

doggo @https://one.one.one.one/dns-query --time A AAAA HTTPS rutracker.org
rutracker.org. A 172.67.182.196 https://one.one.one.one/dns-query 250ms

вот на TLS сразу заметно

doggo @tls://one.one.one.one/dns-query --time A AAAA HTTPS rutracker.org
rutracker.org. A 104.21.32.39 one.one.one.one:853 258ms

doggo @tls://1.1.1.1/dns-query --time A AAAA HTTPS rutracker.org
rutracker.org. A 104.21.32.39 1.1.1.1:853 157ms

ps. если бы не РКН …
doggo @1.1.1.1 --time A AAAA HTTPS rutracker.org
rutracker.org. A 172.67.182.196 1.1.1.1:53 40ms

2 26.00 ms 1.net-126.kaluga.ru (95.107.126.1)
3 27.00 ms 213.59.232.180
4 …
5 30.00 ms 95.71.2.226
6 31.00 ms 172.68.8.51
7 32.00 ms one.one.one.one (1.1.1.1)

из репы он идёт с поддержкой сокета и там listener пустой

dnscrypt socket это вообще какая-то наркомания. Как и всякие systemd-resolved. Наплодили всякой фигни. Я теперь понимаю тех, кто ненавидит systemd.