- Настроил:
network.trr.mode 3
// Включить DOH в режиме безусловного использования - то есть без обращений к системному DNS даже в случае недоступности указанного в конфиге DOH сервера.
network.trr.bootstrapAddress 1.1.1.1
// Адрес для получения IP ближайшего резолвера. С тем же результатом пробовал 2606:4700:4700::1111, т.к. у меня нативный ipv6.
network.security.esni.enabled true
// Включить ESNI.
network.trr.uri и network.trr.resolvers пробовал оставлять подефолту и прописывать вместо mozilla.cloudflare-dns.com, заблокированного в РФ по ip (104.16.248.249 и 104.16.248.249), dns.cloudflare.com (104.19.199.29 и 104.19.198.29), который не заблокирован.
// Этот домен не используется для отправки запросов, поэтому в любом случае его блокировка не должна влиять на работоспособность DOH.
- После настройки:
Здесь все галки зелёные (ESNI функционирует): https://www.cloudflare.com/ssl/encrypted-sni/ Даже разблокировался сайт 2channel.moe , который ТТК банит по TLS-SNI (трейсроуты до IP проходят, но без ESNI в браузере возникает ошибка "PR_CONNECT_RESET_ERROR").
Тут "CloudFlare" (резолвинг выполняется через CF, а не системный DNS): https://www.dnsleaktest.com/
Сначала всё работает, но проходит несколько часов и ломается без видимой причины, что выражается в ошибках: "Хмм. Нам не удается найти этот сайт" - при попытке открыть любой домен.
- Как выяснилось, с CloudFlare есть проблемы и при использовании DOH/DnsCrypt-клиента "dnscrypt-proxy", только симптомы другие.
Я прогнал DNS-бенчмарк namebench и обнаружил, что каждый 5ый запрос завершается ошибкой: "99 queries to this host failed" (из 500); а ещё есть жалобы на какой-то атрибут после каждого запроса: "'module' object has no attribute 'edns'". Бенч даже не смог построить нормальный график - на него можно взглянуть ниже среди результатов теста прочих DNS-серверов. Однако, резолвинг не отваливался полностью, как в Firefox. Ошибки: "Хмм. Нам не удается найти этот сайт" не возникало даже спустя пару недель работы dnscrypt-proxy.
Вышеизложенная информация может привести к предположению, что лиса после определенного лимита кривых ответов отключает DOH, но поскольку я запретил ей обращаться к системному DNS (network.trr.mode 3), она перестаёт резолвить вообще. А dnscrypt-proxy не имеет такого лимита и стучится до CF во что бы то ни стало. Логично, но дальнейшее тестирование показало, что в лисе отваливаются любые DOH-серверы, а dnscrypt-proxy с любыми (кроме CF) абсолютно стабильно работает неограниченное время. Это значит, что за исключением CloudFlare проблема в клиенте, т.е. в Firefox.
- Google DOH работает до 40 минут (ESNI тоже функционирует), затем отваливается, как и CF. В конфиг прописывал:
network.trr.mode 3
network.trr.bootstrapAddress 8.8.8.8
network.security.esni.enabled true
network.trr.uri https://dns.google/dns-query
network.trr.resolvers [{ "name": "Google", "url": "https://dns.google/dns-query" }]
Quad9 и прочие тоже отваливаются.
Обратите внимание, что бенчмарк показывает не пинги до серверов, а полное время уходящее на получение ответов и ещё количество TimeOut. Все тесты проводил с настройкой на источник запросов "Alexa". Если выбрать в качестве источника историю браузера, результат получается гораздо лучше (но он не релевантен, потому что персонифицирован). Число запросов всегда выставлял 500. Перед каждым тестом стирал кэш командой "/flushdns". Закрывал весь посторонний софт. Пере-Тестировал те же серверы в разные дни - результаты в точности повторялись. Представленные в тестах DNS я оставлял в работе на продолжительное время, а Google DOH использую непрерывно уже год с тех пор, как перешёл с протокола dnscrypt v2. -Поэтому могу с уверенностью сказать, что он никогда не отваливается при использовании dnscrypt-proxy. Теперь к результатам:
- Кривой CloudFlare:
Код:
sdns://AgcAAAAAAAAABzEuMC4wLjGgENk8mGSlIfMGXMOlIlCcKvq7AVgcrZxtjon911-ep0cg63Ul-I8NlFj4GplQGb_TTLiczclX57DvMV8Q-JdjgRgSZG5zLmNsb3VkZmxhcmUuY29tCi9kbnMtcXVlcnk
Код:
sdns://AgcAAAAAAAAAGVsyNjA2OjQ3MDA6NDcwMDo6MTExMV06NTOgENk8mGSlIfMGXMOlIlCcKvq7AVgcrZxtjon911-ep0cg63Ul-I8NlFj4GplQGb_TTLiczclX57DvMV8Q-JdjgRgSZG5zLmNsb3VkZmxhcmUuY29tCi9kbnMtcXVlcnk
- Google показал себя превосходно. Он равен по скорости НЕ зашифрованному 1.1.1.1 ( Ping до 8888 и 1111 одинаковый: 37мс.). И существенно быстрее, чем тот же 8.8.8.8 без криптографии: AVG на 42мс ниже; на 21% больше запросов уложились в 110мс.
Код:
sdns://AgUAAAAAAAAABzguOC44LjigHvYkz_9ea9O63fP92_3qVlRn43cpncfuZnUWbzAMwbkgdoAkR6AZkxo_AEMExT_cbBssN43Evo9zs5_ZyWnftEUKZG5zLmdvb2dsZQovZG5zLXF1ZXJ5
- Для сравнения: Google DOH в среднем на 62мс быстрее, чем DNS моего провайдера; на 30% больше запросов уложились в 110мс:
- Источник запросов - история браузера:
- Quad9 слишком слоу (303мс). Хотя ping до него, как у google - 37мс. Ниже тест с самым быстрым IP Quad9:
(Google и CF не поддерживают работу по DnsCrypt)
- Quad9 по DnsCrypt проявил себя идентично Quad9 по DOH (304мс):
Код:
sdns://AQMAAAAAAAAAEjE0OS4xMTIuMTEyLjk6ODQ0MyBnyEe4yHWM0SAkVUO-dWdG3zTfHYTAC4xHA2jfgh2GPhkyLmRuc2NyeXB0LWNlcnQucXVhZDkubmV0
- Quad9 с поддержкой ECS на 100мс медленнее по AVG. И таймаутов многовато:
- Cisco (Open DNS) медленнее Google DOH на 8мс по AVG и успел дать на 10% меньше запросов уложившихся до 110мс, что объясняется повышенным пингом: 62мс против 37мс. При этом, сколько бы я ни повторял тест, у киски нет таймаутов. А у гугла всегда 2-3шт. Есть несколько IP OpenDns (208.67.222.222; 208.67.220.220; 208.67.222.220; 208.67.220.222) с одинаковым результатом:
Код:
sdns://AQAAAAAAAAAADjIwOC42Ny4yMjIuMjIyILc1EUAgbyJdPivYItf9aR6hwzzI1maNDL4Ev6vKQ_t5GzIuZG5zY3J5cHQtY2VydC5vcGVuZG5zLmNvbQ
- Попробовал активировать параметр "force_tcp". DnsCrypt работает по UDP, в отличие от протокола DOH. force_tcp может пригодиться, чтобы направить запросы через Tor или обойти несложный фаерволл. Отклик замедлился:
1) Mozilla выбрала CF, который и в dnscrypt-proxy нормально не работает. Поэтому, если даже браузерную реализацию допилят, чтобы doh не отваливался, я не буду использовать CF и продолжу сидеть на Google. Если кто-то размышляет, что надёжнее - CF или Google, то скажу, что большие падения случаются у обоих гигантов. И более того, я был свидетелем, как 2 июля 2019ого грохнулся, и CF DOH, и Google DOH в одно и то же время! CF о неполадках отписался, но от гугла ничего слышно не было. Заметил проблему, когда при веб-сёрфинге стал получать ошибки: "Хмм. Нам не удаётся найти этот сайт". Перезапустил службу dnscrypt-proxy - это не помогло. Попробовал чистый профиль firefox - не помогло. Тогда я сменил google doh на CF в конфиге dnscrypt-proxy и опять не заработало. Оказалось, что при комманде в консоли отрезолвить домен оба сервиса отвечают таймаутами. В то же время dnscrypt v2 сервер Cisco работал хорошо. Через минут 20 гугл и CF поднялись одновременно. С чем было связано это синхронное падение абсолютно независимых инфраструктур, я не знаю.
2) Не вижу необходимости использовать DOH именно с помощью браузерной реализации, поскольку dnscrypt-proxy гибче в настройке, поддерживает сразу два протокола, имеет полезные фичи (например фильтры) и работает для всего софта в ОС сразу. С dnscrypt-proxy я теряю поддержку ESNI, но это не является упущением по двум причинам:
- РКН блокирует интернет не только по TLS-SNI фильтру через DPI, но и чёрным списком с миллионами IP-адресов.
Соответственно, спрятав домен в обращениях к серверам, я всё равно буду натыкаться на грубый обрыв соединений по IP. Например, у меня недоступен по ip jabber-сервер на DigitalOcean, на котором не висело веб-сайтов и публичных прокси. Тем не менее РКН забанил его блокировкой подсети. Заблокирован подсетью mozilla.cloudflare-dns.com по решению суда от 2013 года и по сей день - 14 мая 2020. Этот домен указан в конфигурации DOH у Firefox, о чём я упомянул в самом начале поста.
- Не у всех сайтов со своей стороны есть поддержка ESNI.
В случае соединения с такими сайтами при включенном на стороне клиента ESNI, мы будем получать бОльшую задержку.
Проблема с блокировками не решается через ESNI - всё равно понадобится прокси. Зато мы получаем лишнюю задержку. А раз так, то я продолжу сидеть на dnscrypt-proxy с настройкой на Google DOH. И на случай падения гугла буду держать в конфиге пару альтернативных вариантов, которые не долго задействовать (не нужна даже перезагрузка ОС).
js90
На CF жаловались ещё во время разработки . Проверьте насколько работоспособно с настройками
network.trr.uri = https://dns.google/dns-query
network.trr.bootstrapAddress = 8.8.8.8
del
del
Спасибо за выложенные тесты и информацию! Было полезно для меня. Теперь тоже использую Google DoH.
dreamkz
По ссылке чистая вода ни о чём.
такая вот штука после обновления на версию firefox 84. отпишитесь кто сталкивался, и решалось ли каким либо путём
tagnupip
"Старый" ESNI сейчас заменяется на Encrypted Client Hello (ESNI-08) , потому возможны глюки совместимости .
В 85 старая версия , вместе с соответствующей настройкой будут удалены полностью .
Пока можете проверить что бы
network.security.esni.enabled = true
network.trr.mode = 2 (или для гарантии -3)
tagnupip"Старый" ESNI сейчас заменяется на Encrypted Client Hello (ESNI-08) , потому возможны глюки совместимости .В 85 старая версия , вместе с соответствующей настройкой будут удалены полностью .Пока можете проверить что быnetwork.security.esni.enabled = truenetwork.trr.mode = 2 (или для гарантии -3)
именно так у меня и настроено. у некоторых пользователей это работает, у меня ни в какую. пробовал не то что чистый профиль, но и систему в виртуалке. менял страну при помощи vpn. не получается даже закономерность проследить
ESNI ещё проходит положительный результат https://www.cloudflare.com/ssl/encrypted-sni/ ?
А будут ли работать настройки (у меня пока нет результата) если DOH+DOT сервера, прописаны в маршрутизаторе?
Если да, то подскажите как организовать положительный результат?
Хотя с 85 версии что то новое вырисовывается - https://portswigger.net/daily-swig/encrypted-client-hello-upcoming-firefox-85-rollout-builds-momentum-for-esni-successor
network.dns.echconfig.enabled
network.dns.echconfig.fallback_to_origin_when_all_failed