Обсуждение из «Блокировка DoH сервера dns.google»

Hmm, but the goal is not to hide the Host header, but to hide the SNI and DNS query. Connecting to dns.google and sending a Host of whatever.google.com may work, but it is still blockable because the censor sees a connection to dns.google. You need the opposite: connecting to whatever.google.com and sending a Host of dns.google. In my tests, the latter technique does not work.

I believe this is what you are describing. It “works” in the sense of returning a response, but the censor still sees a DNS query and SNI for dns.google, which means it can be blocked.

$ curl -H 'Host: docs.google.com' 'https://dns.google/resolve?name=example.com&type=A'
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,"Question":[{"name":"example.com.","type":1}],"Answer":[{"name":"example.com.","type":1,"TTL":13490,"data":"93.184.216.34"}]}

What you really want is the following, but in my tests it does not work:

$ curl -H 'Host: dns.google' 'https://docs.google.com/resolve?name=example.com&type=A'
<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>
  ...
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>404.</b> <ins>That’s an error.</ins>
  <p>The requested URL <code>/resolve</code> was not found on this server.  <ins>That’s all we know.</ins>

Note, in these examples I used the JSON /resolve endpoint, not the RFC 8484 /dns-query endpoint, but I believe the result is the same in terms of domain fronting.

Sending request to 8.8.8.8 or 8.8.4.4 with google.com SNI works for DNS resolving, but not for other (regular) IP addresses.

$ curl --resolve *:443:8.8.4.4 -k 'https://google.com/resolve?name=example.com&type=A'

{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,"Question":[{"name":"example.com.","type":1}],"Answer":[{"name":"example.com.","type":1,"TTL":4786,"data":"93.184.216.34"}]}

Тот пример, что привели вы — не domain fronting. Domain Fronting заключается в подмене SNI (это то, что видит DPI), а вы наоборот подменяете Host.

Ни мне, ни @tango не удаётся найти такой домен, при нормальном обращении к которому (на оригинальные IP-адреса и с оригинальным SNI) можно бы было отправить DNS-запрос внутри установленной TLS-сессии — а именно в этом суть domain fronting.

Есть ненулевая вероятность, что весь этот цирк с конями начали ровно за 10 дней до выборов только из-за одной проги Навальный, чтобы ко дню голосования максимально затруднить получение информаци по кандидатам про УмГ.

Хм, а что, у кого-то есть другие предположения? По-моему, это довольно очевидно.
Сторонники Навального рекламировали SDK NewNode, которое использует DHT, а в Android-приложении вбиты dns.google и doh.opendns.com, но не dns.google.com (поэтому он работает).

Тогда флаг им в руки блокировать или замедлять YouTube. Вроде бы там обещали зачитывать список кандидатов.

dns.google.com может быть указан в качестве DoH, но не DoT-резолвера, я правильно понимаю?

Да, но он отсутствует в Android-приложении Навального, поэтому его не блокируют.

Однако, удалось протестировать dns.google.com в качестве приватного DNS в Андроиде (если я правильно понимаю, там может быть только резолвер с DoT). Хотя точно не знаю. Но оно работает.

А вот сделать запрос формата https://dns.google.com/dns-query не вышло.

Всё верно, на дроиде только DoT и dns.google.com всегда работал

Помогите, пожалуйста, разобраться с тем, как обрабатываются DNS-запросы в Андроиде.
В системе указан “Частный DNS” (Сloudflare) - DoT.
В браузере указан DoH cloudflare-dns.com.
Я правильно понимаю, что прописанное в настройках браузера - первично и все имена резолвятся именно тем резолвером, который указан в браузере? А если отключить DoH в браузере, то резолв ляжет на “частный DNS”, указанный в настройках?

По идее, все должно быть именно так. Но при этом все эти запросы проходят в нешифрованном виде, на 53 порт резолвера Cloudflare (что хоть и работает, но небезопасно) - это видно с помощью вайршарка. Получается, что где-то происходит fallback. Интересно, где… и почему он происходит. Или в Андроиде так задумано - если недоступен DoT, то уходит обычный незашифрованный запрос?

И недавно, как раз с началом новых блокировочных битв, при открытии некоторых (не всех) страниц в браузере возникает вот такая проблема
photo_2021-09-09_22-28-46
Примерно на секунду-две, после этого происходит повторная попытка и страница загружается нормально.
Это просто как мимолетное виденье, не сразу смог поймать и заскринить.

Человек, которому я пытаюсь помочь избавиться от проблем с DNSами, использует Shadowsocks (сервер в Европе, без каких-либо блокировок). Получается, Shadowsocks не проксирует DNS-запросы или такова общая политика Андроида?

Странно получается: трафик вроде бы проксируется, а DNS-запросы нет и усилиями РКН интернет все равно ломается.

В клиенте Shadowsocks, используемом этим пользователем, есть настройка “DNS-сервер”, но, такое впечатление, она игнорируется - что бы там ни было прописано, никакого эффекта это не имеет (если оставлять ее пустой - тоже).

Буду рад, если поможете разобраться и помочь человеку.

Да, важное дополнение - при проверке на https://www.dnsleaktest.com/ выдаются DNS-резолверы, используемые на Shadowsocks-сервере (не имеют никакого отношения к Cloudflare, там резолверы от Google и два резолвера Tor).

This story says that the RKN press service warned DNS and CDN providers over access to the Smart Voting app:

“Роскомнадзор и Центр мониторинга управления сетями связи общего пользования РФ (ЦМУ ССОП РФ) на основании требований Центральной избирательной комиссии и Генеральной прокуратуры России направили в адрес ряда иностранных компаний, в том числе провайдерам DNS- и CDN-сервисов, письма с требованиями прекратить предоставление возможностей для обхода ограничения доступа к приложению и сайту “Умное голосование” на территории Российской Федерации”, - сказали в пресс-службе.

Кроме того, Роскомнадзором и ЦМУ ССОП РФ установлено, что средства обхода блокировок предоставляют более 10 иностранных провайдеров, расположенных на территории США, Украины, Германии, Франции, Японии, Великобритании и других государств. Законные требования о недопустимости предоставления технических средств для обхода ограничения доступа игнорируются магазинами приложений компаний Apple и Google, DNS- и CDN-сервисами Google, Cisco, Cloudflare и ряда других компаний.

“Roskomnadzor and the Public Communications Network Management Monitoring Center of the Russian Federation (PCMC RF) sent letters to a number of foreign companies, including providers of DNS and CDN services, with demands to stop providing opportunities to circumvent access restrictions to the Smart Voting app and website in the Russian Federation, based on the requirements of the Central Election Commission and the Prosecutor General’s Office of Russia,” the press service said.

In addition, Roskomnadzor and the SSOP CMU found that more than 10 foreign providers located in the United States, Ukraine, Germany, France, Japan, the United Kingdom and other countries provide blocking circumvention tools. Legal requirements regarding the inadmissibility of providing technical means to bypass access restrictions are ignored by Apple and Google app stores, DNS and CDN services of Google, Cisco, Cloudflare and a number of other companies.

I found the TASS story through a web search that led me to the following site, which also says something about YouTube:

According to Klimarev, the Russian authorities may block YouTube in the country during the elections on September 18-19.

Прилично поломал голову с этим Shadowsocks, в итоге установил человеку OVPN-сервер и большую часть проблем как ветром сдуло.

И с частным сервером сейчас нет затруднений, и резолвер антизапрета (проверял и этот конфиг) отрабатывает как надо.

На следующей неделе ситуация в России, вероятно, станет вообще веселой. :slight_smile:

Ростелеком рассылает по клиентам запрет на использование DNS-серверов Google и Cloudflare и рекомендует использовать свои DNS-серверы или серверы “Национальной системы доменных имен”.

Об изменении DNS адресации.pdf (229.3 КБ)

Скорее всего, состоятся блокировки крупнейших публичных DNS-серверов перед выборами (и может пострадать множество клиентских устройств).

В клиенте SS есть несколько настроек, которые могут влиять на проксирование DNS-трафика. В частности в опциях маршруты должны быть выставлены в положение “Все”.

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

Никакое множество устройств не пострадает. Большинство роутеров исполтзуют днс от оператора, а значит и их клиенты. Тем, кто ручками вписал вражеские сервера, просто скажут сменить на наши, а открытые днс запросы начнут/уже начали перенаправляться на сервера оператора

Вас послушать, так создается впечатление, что никакого Интернета вещей нет, а есть только “роутеры”.

Это я прочитал, найдя в гугле комментарий об этом от одного из разработчиков SS, да.
Маршрут был установлен именно как “Все”. И, несмотря на это, запросы почему-то не проксировались.

Нет, догадался не только сейчас. Я по натуре пессимист и всегда готовлюсь к худшему. Но какая-то надежда все-таки теплилась.

Что будет делать ТСПУ с открытыми запросами на 8.8.8.8? Спуфить ответы? Сам перенаправлять на рекурсоры НСДИ? Просто заблокируют 8.8.8.8 и 8.8.4.4 по IP-адресам?

Точный ответ не знает никто. На моем операторе, к примеру, запросы перенаправляются на сервер провайдера. Думаю, ничего сложного в том, чтобы прямо на ТСПУ перенаправлять запросы к нужным адресам, нет. Во всяком случае, намного менее затратно, чем блочить wireguard/bittorent, а на это у них мощностей хватает. Блокировать по ip совершенно нельзя, так как в таком случае реально много устройств с прошитыми dns просто отвалятся

Пришло буквально минут 10 назад, спб, skynet.