Для решения проблемы долгого ответа как раз идеально подходит локальный unbound. Во-первых, кэш, во-вторых, у него есть замечательный prefetch, который сам освежает адреса перед их истечением.
У меня сейчас в prefetch больше 8k записей, то есть фактически они запрашиваются заранее, а не в момент обращения.
Ну и соответственно, эффективность обращений высокая, практически 75% запросов разрешаются локально. Это с учетом того, что 6 дней назад был перезапуск и кэш+prefetch обнулялись…
Это не необходимость, а рекомендация для снижения вероятности ошибки разрешения имени.
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.
Я про дополнительный функционал 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.
frame contains "rutracker" тишина, т.е. ECH работает.Но как я сказал, это менее надёжно. Если 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), потому он задержки получает, а я уже нет.