
Комментарии 96
Проверил, DoT заблокировали, DoH еще в процессе

Как-то так
Trying 8.8.8.8:853…
ALPN: curl offers h2,http/1.1
TLSv1.3 (OUT), TLS handshake, Client hello (1):
SSL Trust Anchors:
CAfile: /etc/ssl/certs/ca‑certificates.crt
TLSv1.3 (IN), TLS handshake, Server hello (2):
TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
TLSv1.3 (IN), TLS handshake, Certificate (11):
TLSv1.3 (IN), TLS handshake, CERT verify (15):
TLSv1.3 (IN), TLS handshake, Finished (20):
TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
TLSv1.3 (OUT), TLS handshake, Finished (20):
SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / RSASSA‑PSS
ALPN: server did not agree on a protocol. Uses default.
Server certificate:
subject: CN=dns.google
start date: Aug 10 08:39:52 2026 GMT
expire date: Nov 2 08:39:51 2026 GMT
issuer: C=US; O=Google Trust Services; CN=WR2
Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha384WithRSAEncryption
subjectAltName: “8.8.8.8” matches cert’s IP address!
OpenSSL verify result: 0
SSL certificate verified via OpenSSL.
Established connection to 8.8.8.8 (8.8.8.8 port 853) from ***.***.***.*** port 31 474
using HTTP/1.x
GET / HTTP/1.1 Host: 8.8.8.8:853 User‑Agent: curl/8.21.0 Accept: /
Request completely sent off
TLSv1.3 (OUT), TLS alert, decode error (562):
OpenSSL SSL_read: OpenSSL/3.6.4: error:0A000126:SSL routines::unexpected eof while reading, errno 0
closing connection #0 curl: (56) OpenSSL SSL_read: OpenSSL/3.6.4: error:0A000126:SSL routines::unexpected eof while reading, errno 0
митма не видно. можете сделать так?
q -v A youtube.com @tls://8.8.8.8
DEBU Name: youtube.comDEBU RR types: [A] DEBU Server(s): [tls://8.8.8.8] DEBU Using server 8.8.8.8:853 with transport tls DEBU Using TLS transport: 8.8.8.8:853 youtube.com. 5m A 172.253.130.136 youtube.com. 5m A 172.253.130.190 youtube.com. 5m A 172.253.130.91 youtube.com. 5m A 172.253.130.93
Всё работает. Очень странно что чекер пишет про какой-то mitm
Запускал на Linux, всякие "специальные средства" были отключены, как на хосте, так и на роутере.
Да просто кривая утилита.
Там походу баг в программе. Такая же картинка, как у вас, однако:

Скорее всего неправильная классификация ошибки и проблема с корневыми сертификатами у питоновской библиотеки httpx. Поправлю в следующем обновлении.
Подскажите что за утилита. Натыкался, теперь найти не могу
уберите, пожалуйста, бред из названия, а именно про "начали блокировать протокол DoH".
дикий кликбейт, минус за это.
сами обьяснили в статье почему это невозможно, но оставили название...
но и c DoT вы нормальной проверки не сделали, блокировка хотя бы по порту или "по протоколу" неочевидна
про ттл трюк вообще непонятно: вы его странно описали, в команде не сделали, и первоисточник откуда про это узнали не указали - https://habr.com/ru/articles/1075272/, хотя я уже просил вас
обьяснили в статье почему это невозможно
Я этого не говорил. Это сложнее сделать, но не невозможно. ТСПУ с этим справляется. Иначе бы никто не жаловался в том числе на doh.
Ссылку добавлю.
DoT действительно начали блокировать. Система на уровне systemd-resolved была настроена на квад9, в конце августа всё ещё работало, в начале сентября отвалился. Хотя хэндшейк действительно проходит успешно, но ничего не резолвится. Раз в 10 минут видимо сфинктер тспу случайно разжимается и проскакивает пара ответов, что только подтверждает предположения.
Нейросеть статью писала?
TTL-трюк. В некоторых случаях поведение перехвата можно изменить, отправив один и тот же DNS-запрос сначала с небольшим TTL, а затем повторно с обычным TTL. Например:
dig @8.8.8.8 youtube.com +bufsize=512 -4 Где тут TTL?
curl -v --resolve dns.google:443:8.8.8.8 https://dns.google/dns-query
-H 'accept: application/dns-json'
-G --data-urlencode 'name=example.com' --data-urlencode 'type=A'Бекслешы пропущены. Да и все равно не работает, ибо правильный урл: https://dns.google/resolve
Если поменять только SNI, оставив IP тот же (например, через
curl --connect-to), и трафик пойдёт — вы нашли SNI-фильтрацию, а не блокировку по адресу:
Приведенная ниже команда 1) не меняет SNI, 2) не работает
Но ведь...
Google Public DNS предоставляет два разных API DoH на этих конечных точках:
https://dns.google/dns-query – RFC 8484 (GET и POST)
https://dns.google/resolve? – JSON API (GET)
Правилен и тот, и тот.
Не знал, что такую неприкрытую нейронку пропускают в статьи.
А еще https://habr.com/ru/articles/1075272/
Не понял. А есть какя то техническая база под тезисом, что блокируется udp трафик на 853 порту? Довольно радикально сбрасывать весь трафик на 853 порт.
DoT на 9.9.9.9 вроде как у всех работает, значит никакого сброса по порту не существует.
Похоже на ростелекоме не работает
Так dot на 443. У меня в целом сомнения по поводу этой истории есть. Я сетевик и не могу поверить в такие вещи пока не проведу диагностику самостоятельно. С начала блокировок слишком уж много некомпетентной диагностики и выводов "все блокируют и замедляют на тспу" на основе этой диагностики. Ну и статей под громкими заголовками.
Почему радикально? Значит до популярных CDN-ов троттлить 443 в нулину нормально, а 853 трогать - фу?
Было бы здорово, если бы кто-то расписал наихудшие сценарии, чтобы не заниматься постоянной перенастройкой
У вас не будет интернета.
почему только у него? или это и есть как раз для него наихудший, когда у всех есть, а у него нет?
Вернее сказать у вас не будет публичного интернета. Так или иначе отключите doh dot doq
У вас не будет интернета.
Наихудший сценарий: у вас не будет интернета и вы будете счастливы.
Ну почему же совсем не будет? Ozon, Яндекс и Гос.услуги подключат прямо в мозг.

удалили за якобы сгенерированный контент
Ну как бы да 😀 и эта новая статья -- поток изощренного многословия от LLM.
Вообщем, мамкины хакеры добрались до хабры и теперь придется видимо их тут видеть и их осковерканный кликбейтный бред...
Коллеги, я очень рекомендую вам смотреть в сторону фингерпринтинга, а не протоколов и адресов.
Не знаю у меня на сервере запущен adguardhome с doh, за обратным прокси, doh идёт без проблем с разных операторов. Проблема значит в сторону публичных dns, смысл перегружать DPI фильрацией всего, адреса DOH известны.
В России начали блокировать
Надеюсь дожить до дня, когда проснусь и увижу Хабр, пестрящим заголовками вида "В России запустили/сделали/создали/построили"... И не что-то деструктивное, а полезное для общества.
Эх, как бы здоровье не подвело.
Бюро 1440 запустило спутники для аналога Старлинка и собирается провести интернет в поезда РЖД, чем не такая новость?
Уже дожили, поздравляю.
Новости с глаголами будущего времени: собирается, планирует, обещает и т.п. только обещают нас обрадовать когда-то потом.
32 спутника уже на орбите. Это не обещание сделать хорошо через 20 лет, это проект который активно развивается в реальности и уже работает. Не хватает только количества этих самых спутников для бесперебойной связи.
Эти спутники интересны только военным
И это хорошо. Военные, которым интересны эти спутники - это финансирование и преференции при импорте нужных комплектующих.
И я лично буду рад, что у наших военных появится устойчивая, быстрая и независимая связь.
PS: Интернет тоже вырос из военных технологий, если что. Вам же не стыдно им пользоваться? )))
Согласно Википедии, число потенциальных абонентов «Бюро 1440» оценивало в 1,5—2 млн. человек в России и до 12 млн. в мире (планируется охватить более 70 стран) при плановой пропускной способности на абонента от 50 Мбит/с до 1 Гбит/с.
По данным Росстата, зарплату выше 200 000 ₽/месяц (2 400 000 ₽/год) в 2025 году получали около 3% работающих россиян. Это порядка 2,2 млн. человек, если учитывать, что общее количество работающих граждан — 74,6 млн.
Если гражданским всё же отсыпят, то расчёт очевидно на людей, имеющих годовой доход более 2 млн.р. Непонятно вот только, зачем люди будут тратиться на значительно более дорогие терминалы и тарифы от "Бюро 1440", если уже есть работающий Starlink с ценой подключения меньше месячной з/п. И это я ещё не учёл, что российский спутниковый интернет будет "суверенный", т.е. по белым спискам. Выходит да, проект нужен только военным, потому что разумные люди подключать чебурнет за млн.р. не станут.
Странная у вас логика. Старлинк у нас запрещен, например. И шанс что его разрешат минимален.
А не надо личный. Самолет, поезд, вахта, общий терминал но почте в деревне. Кейсов много.
Это порядка 2,2 млн
Надо еще учесть, что среди этих 2 миллионов, тех кому понадобится спутниковый интернет будет меньше процента. Т.е. рассчитывать надо тысяч на 20.
32 спутника уже на орбите.
Парочка уже падает, вторая партия никак не может на свою орбиту залезть.
А уж сколько килобаксов будет стоить терминал "как у старлинка" я даже боюсь представить.
Или они сознательно выведены на другую орбиту. Вероятность что вся партия сломалась ничтожно мала. Вероятность что что-то проверили и решили сменить целевую высоту заметно выше.
Так они вроде на той орбите, где остатки атмосферы еще сильно тормозят спутники.
Плюс-минус орбита МКС. Тормозят, но не так чтобы завтра или через год упасть.
Я легко предположу что это специально чтобы военным дать сигнал мощнее прямо сейчас. Потому что с прошлой орбитой где-то не хватило по результатам проверки. Или чтобы окна доступности связи над определенной территорией были чаще. Срок жизни в несколько лет ок для такого применения.
Залезут. Это абсюлютно штатное поведение. Плазменные двигатели дотянут их за ~4 месяца.
Отличная новость, в РФ будем жить и работать в поезде. Поезд "Желтая стрела" называется?
1440 работает под фсб, вероятность, что они сделают что-то хорошее, для населения этой страны, стремится к нулю. Даже если они утверждают, что они занимаются исключительно гражданскими разработками.
Далее, допустим, что их 30 спутников действительно летают. Что это нам дает? Правильно, ничего. Так как чтобы скопировать старлинк нужно большее количество спутников, минимум на 2 порядка. Получается, что либо обещания, либо какая-то не юзабельная система.
И третье, сколько запусков в год делает 1440? А старлинк сколько? Можете не отвечать, это риторический вопрос.
"В России запустили систему ограничения опасных DoT и DoH запросов"
"В России создали национальную инфраструктуру фильтрации вредоносного инетрнет-траффика"
Вроде таких?
Спасибо за разбор с curl-выводом, особенно за момент про обрыв именно на TLS-хендшейке, а не на IP. Заметил похожее у себя: DoT молчит по таймауту, а обычный DNS по TCP пока живёт. Похоже, единственный устойчивый вариант — резолвить внутри туннеля, всё остальное лечится ровно до следующего обновления правил.
Софт с сорцами в студию!
Зачем вы проверяете, что 8.8.8.8 доступен по 53 порту, он у всех доступен. Вы проверьте можете ли вы им зарезолвить, например, youtube.com, посмотрите, что зарезолвится whoami.akamai.net. Например если у меня по открытому сделать запрос на 8.8.8.8 чтобы резолвить youtube.com получаю "dns name does not exist", а если яндексовский сервер 77.88.8.8, то получаю 64.233.163.91. На 1.1.1.1 тоже подменяют, а 9.9.9.9 ещё нет.
Злой мир - выпустили, открыли, создали. Мирный мир - заблокировали, закрыли, посадили.
Спасибо! Два дня не мог понять что стало с проектом)))
Бьёт одновременно и по Google, и по Cloudflare — два независимых поставщика DNS, два разных набора IP‑адресов, два разных протокола.
Какие разные протоколы? Чем DoH (как протокол) от Google отличается от DoH Cloudflare?
Затрагивает разных операторов независимо друг от друга — то есть похоже на централизованно распространённую сигнатуру/правило для оборудования ТСПУ, а не на локальную настройку одного оператора
ТСПУ сейчас стоят не только у провайдеров "последней мили", но и на магистральных каналах. Первые упоминания про них появились в Сети еще в декабре прошлого года (на собственной шкуре это испытал где-то полгода назад).
Ну что - может начинать переходить на использование /etc/hosts, в котором прописать все адреса, а файлик торрентами раздавать? (чувствую, будет немалого размера).
за якобы сгенерированный контент
Ага-ага, Вы ни разу не палитесь. По первым фразам нейронка ощущается. Уже набил оскомину этот вкус.
То же самое, но под windows:
nslookup whoami.akamai.net 8.8.8.8
Если выдает адреса 193-195.x.x.x, значит вместо гугла отвечает MSK-IX.
Небольшой процент ответов могут быть нормальными, видно что-то недоделали в датском королевстве.
те же 193.х.х.х адреса выдаются при запросах к nslookup whoami.akamai.net 1.1.1.1
Полезно, что показана разница в диагностике: при DoT RST после успешного рукопожатия действительно выглядит подозрительно. Для DoH на 443, похоже, без сравнения с другими резолверами выводы делать сложнее.
Чота ору с этих РосКомПаникеров, они "магазин DNS" блочат, прикидываете? На detector404 можно чекнуть. То есть реально когда идет попытка подключения к домену, имеющему в названии "dns", они это подключение рвут =) Ой-ой-ой, а то что они там начали просвещаться по поводу DNS, начали заходить на сайты по обнаружению утечки DNS, непорядок. Так победят ;)
Блин, уже мечтаю о какой-нибудь стране без ркн, газпром медиа и всего этого остального дерьма.
На всякий случай предостерегу, будьте осторожнее с заворотом всех dns запросов в тоннель. Есть сервисы которые полагаются на geodns и например тот же warthunder при получении dns из прокси перестаёт работать(потому что выдаёт ip адреса не доступные в рф). При этом что забавно проблему вызывает не только отправка dns в прокси но и в принципе использование dns без поддержки geodns. В итоге для себя я решил проблему отправив запросы к доменам тундры через яндекс doh напрямую.
Также если отправляете dns через тунель в том же sing-box или xray используйте именно doh версию, это будет наиболее быстрый вариант по задержке тк будет поддерживаться http/2 сессия без постоянного переподключения и нет нужды упаковывать пакеты в xudp для VLESS.
Госуслуги похоже заблокировали Cloudlfare DNS (1.1.1.1) на своих резольверах и просто не отдают ответ для основного домена:
dnslookup.exe www.gosuslugi.ru https://cloudflare-dns.com/dns-query
dnslookup v1.12.0
Server: https://cloudflare-dns.com/dns-query
dnslookup result (elapsed 148.0653ms):
;; opcode: QUERY, status: SERVFAIL, id: 23086
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.gosuslugi.ru. IN A

В России начали блокировать протоколы DoH и DoT