Начиная примерно с вечера 26 августа, на ТСПУ стали перехватывать открытые DNS запросы к крупным DNS серверам CloudFlare и Google (1.1.1.1, 8.8.8.8), ранее блокировали DoH сервера от данных корпораций.
Результат DNS резолвинга выглядит следующим образом:
~# dig youtube.com @8.8.8.8 ; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> youtube.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59147 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;youtube.com. IN A ;; Query time: 9 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP) ;; WHEN: Thu Aug 27 13:37:35 MSK 2026 ;; MSG SIZE rcvd: 40 ~# dig rutracker.org @1.1.1.1 ; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> rutracker.org @1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23001 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;rutracker.org. IN A ;; Query time: 9 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) ;; WHEN: Thu Aug 27 13:37:20 MSK 2026 ;; MSG SIZE rcvd: 42
Но как это работает на самом деле, с технической точки зрения? Если посмотреть tcpdump, то возвращается сразу NXDomain:
~# tcpdump -n -i ppp0 host 8.8.8.8 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes 13:40:30.834385 IP X.X.X.X.60791 > 8.8.8.8.53: 63359+ [1au] A? youtube.com. (52) 13:40:30.845588 IP 8.8.8.8.53 > X.X.X.X.60791: 63359 NXDomain* 0/0/1 (40)
Однако перехват работает только для UDP протокола, по TCP возвращаются настоящие IP-адреса:
~# dig +tcp youtube.com @8.8.8.8 ; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> +tcp youtube.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48032 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;youtube.com. IN A ;; ANSWER SECTION: youtube.com. 300 IN A 64.233.162.136 youtube.com. 300 IN A 64.233.162.91 youtube.com. 300 IN A 64.233.162.93 youtube.com. 300 IN A 64.233.162.190 ;; Query time: 33 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) (TCP) ;; WHEN: Thu Aug 27 13:41:55 MSK 2026 ;; MSG SIZE rcvd: 104
И тут в ходе экспериментов, возникает следующая интересная ситуация, если отправить запрос резолвинга A записи сначала с ttl 2 (отправка до узла после ТСПУ), а затем повторить отправку, но уже с ttl 64, то тогда возвращается оригинальный ответ:
~# tcpdump -n -i ppp0 host 8.8.8.8 -v tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes 11:48:27.486777 IP (tos 0x0, ttl 2, id 154, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.23121 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54) 11:48:30.533401 IP (tos 0x0, ttl 64, id 11794, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.23121 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54) 11:48:30.683231 IP (tos 0x0, ttl 109, id 1909, offset 0, flags [none], proto UDP (17), length 102) 8.8.8.8.53 > X.X.X.X.23121: 35076 2/0/1 rutracker.org. A 172.67.182.196, rutracker.org. A 104.21.32.39 (74)
При этом отправка рандомного пакета (не DNS запроса) с ttl 2 в начале не изменяет ситуацию, и при повторной отправке с ttl 64 будет получен NXDomain:
~# tcpdump -n -i ppp0 host 8.8.8.8 -v tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes 11:54:00.766581 IP (tos 0x0, ttl 2, id 3798, offset 0, flags [none], proto UDP (17), length 380) X.X.X.X.21631 > 8.8.8.8.53: 20150 updateA Resp11*-| [46423q] [|domain] 11:54:00.899956 IP (tos 0x0, ttl 64, id 22135, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.21631 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54) 11:54:00.911030 IP (tos 0x0, ttl 60, id 9107, offset 0, flags [none], proto UDP (17), length 70) 8.8.8.8.53 > X.X.X.X.21631: 35076 NXDomain* 0/0/1 (42)
В моём случае, отправляя запросы прямо с маршрутизатора, перехват DNS начинается только с ttl 5:
~# tcpdump -n -i ppp0 host 8.8.8.8 -v tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes 12:10:08.061153 IP (tos 0x0, ttl 5, id 33938, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.34240 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54) 12:10:08.080281 IP (tos 0x0, ttl 60, id 31520, offset 0, flags [none], proto UDP (17), length 70) 8.8.8.8.53 > X.X.X.X.34240: 35076 NXDomain* 0/0/1 (42)
И тут самое интересное, если выслать DNS запрос с TTL 2 до 8.8.8.8, тогда в ICMP TTL Exceeded будет содержаться dst ip не 8.8.8.8, а 195.208.5.1 (сервер НСДИ):
Подмена dst адреса происходит только в том случае, если в пакете содержится DNS запрос, у пакетов с рандомным содержимым dst адрес не модифицируется. Получается следующая картина:
При очень быстрой отправке DNS запросов в рамках одного соединения получается очень интересный сбой, сначала отдаёт NXDomain, а затем настоящие IP-адреса:
~# tcpdump -n -i ppp0 host 8.8.8.8 tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes 11:58:27.180858 IP X.X.X.X.24631 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54) 11:58:27.181146 IP X.X.X.X.24631 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54) 11:58:27.181300 IP X.X.X.X.24631 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54) 11:58:27.181424 IP X.X.X.X.24631 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54) 11:58:27.181540 IP X.X.X.X.24631 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54) 11:58:27.199977 IP 8.8.8.8.53 > X.X.X.X.24631: 35076 NXDomain* 0/0/1 (42) 11:58:27.213332 IP 8.8.8.8.53 > X.X.X.X.24631: 35076 2/0/1 A 104.21.32.39, A 172.67.182.196 (74) 11:58:27.213482 IP 8.8.8.8.53 > X.X.X.X.24631: 35076 2/0/1 A 172.67.182.196, A 104.21.32.39 (74) 11:58:27.213542 IP 8.8.8.8.53 > X.X.X.X.24631: 35076 2/0/1 A 104.21.32.39, A 172.67.182.196 (74) 11:58:27.216791 IP 8.8.8.8.53 > X.X.X.X.24631: 35076 2/0/1 A 172.67.182.196, A 104.21.32.39 (74)
Вывод: ТСПУ осуществляет направленный DNAT в сторону НСДИ при наличии DNS протокола внутри пакета, а так же при определённых dst адресах (не на всех DNS серверах происходит DNAT). Оператор связи на выходе после ТСПУ видит не dst адрес 8.8.8.8, а адрес НСДИ (195.208.5.1). С точки зрения оператора связи, трафик к 8.8.8.8 по netflow статистике должен был упасть.
UPD1 28.08.26: могу предположить, что это могли сделать для смягчения нагрузки с ТСПУ, нет резолвинга заблокированных доменов - нет подключения, DPI не анализирует TLS Client Hello
Комментарии (195)
InsiderCrush
27.08.2026 12:30Всегда, когда разбираешь работу этой системы, помни - ребята с "той" стороны тоже хабровчане и скорее всего у них уже открыт тикет с пометкой "срочно" :D
nidalee
27.08.2026 12:30Запрету v1 10 лет скоро, работает. Так что не на все "срочно" есть "решено".
InsiderCrush
27.08.2026 12:30Да, разумеется! Я просто не очень четко мысль выразил. Я имел в виду разбор новых изменений и решений.
Whishper
27.08.2026 12:30Жаль zapret не справляется, когда нет связи с игровыми серверами wb games при игре на playstation.
Но выход все равно есть. Направлять траффик для нужного домена на другой DNS сервер
Таким образом работает умный дом Tuya и мои розетки для аквариума. А также сегодня настроила для Hogwarts Legacy, чтоб не крашится при заходе в игру.
У меня openwrt 24+ doh и zapret2, но я не заметила каких-то проблем с doh, только с dns запросами к игровым серверам. Провайдер Skynet. Долго я с ними ругалась они вместо помощи до сих пор считают, что решать проблемы связи не обязаны, "мы не обходим блокировки" - а где хоть один документ что сервера wb games блокируются? Это вполне легальный трафик, тем не менее поддержка давно болт забила на то что она техническая. Давно пожалела что оплатила по акции до ноября. Никому не советую - будете за свой счёт еб##### при каждом удобном и неудобном случае.
Cbiker
27.08.2026 12:30Это да только они мне заблочили Московский рабочий ВПН, страшно важный для всей страны, ну по крайней мере по словам Мантурова. Хорошо что заметили и починили а то работать через сотовую сеть очень медленно.
Spiritschaser
27.08.2026 12:30СПб, DOCSIS Ростелеком, около часа ночи 24 августа заблокировали DoT 8.8.8.8 и 1.1.1.1 - до этого много лет работало. Не знаю, как там ТСПУ, просто заблокировано.
Moog_Prodigy
27.08.2026 12:30Ростелеком, как замечают люди, пытается бежать впереди паровоза и даже без всяких ТСПУ блокирует (не известно каким образом, но дубово) порой то, что совсем не запрещено, а "им показалось". И делают они это уже давненько.
abaleilo
27.08.2026 12:30У меня кстати не так. В одной квартире Ростелеком, в другой местечковый провайдер, так он гораздо агрессивнее и быстрее всё блокирует
RMavrichev
27.08.2026 12:30Провайдер, с некоторых пор (а именно - с момента установки ему в добровольно-принудительном порядке комплекса ТСПУ), сам по себе НИЧЕГО не блокирует. Так что не грешите на обычных людей, это не они.
edo1h
27.08.2026 12:30емнип, установка тспу никак не отменяет обязанность провайдера самостоятельно блокировать ресурсы из реестра. и я не слушал, чтобы кто-то упразднял «ревизор», который стоит у провайдера и проверяет как он блокирует.
Steelycrack
27.08.2026 12:30работаю в провайдере, ничего сами не блокируем, ревизоры тоже запускаются очень интересным способом)
SerjV
27.08.2026 12:30установка тспу никак не отменяет обязанность провайдера самостоятельно блокировать
Отменяет, и обязанность, и ответственность за неблокировку. В закон было внесено соответствующее изменение, и (по нашим временам) - достаточно давно уже.
Но некоторые провайдеры сохраняют существующую систему в дополнение к ТСПУ.
jpoeaawnyk
27.08.2026 12:30Насколько я знаю имеют место старые решения и старые методы блокировок (через суд), по которому некоторые пространства рутрекера блокируются и по сей день.
SerjV
27.08.2026 12:30Старые - это до принятия поправок в закон "Об информации...", когда вообще по предписаниям прокуратуры блокировали. По нынешним временам - это очень давно.
В данном случае блокировали на основании закона по реестру, и на основании изменений в этот же закон - сняли ответственность (вообще любую, в т.ч. перед абонентами) с провайдеров в случае установки ТСПУ. Но зато наказывается самовольный пропуск трафика мимо ТСПУ.
Но изменение не запретило блокировать собственными силами провайдеров, потому продолжает работать у некоторых провайдеров.
andrei_v
27.08.2026 12:30Подскажите НПА, которым с операторов сняли ответственность за неблокировку? Тоже работаю в операторе связи, у нас нет ТСПУ (мы мелкие), у апликнов конечно есть. Так нам можно теперь убрать систему блокировки?
Meilleur-Q
27.08.2026 12:30Эта норма действует с 1 ноября 2019 года.
Федеральный закон «О связи». Статья 46. Пункт 5.1.“Оператор связи, оказывающий услуги по предоставлению доступа к информационно-телекоммуникационной сети “Интернет”, не обязан ограничивать доступ к информации, распространяемой посредством информационно-телекоммуникационной сети “Интернет”, доступ к которой должен быть ограничен в соответствии с Федеральным законом от 27 июля 2006 года N 149-ФЗ “Об информации, информационных технологиях и о защите информации”, если доступ к такой информации в сети связи оператора связи ограничивается с помощью технических средств противодействия угрозам в порядке централизованного управления сетью связи общего пользования”
ForSokolov
27.08.2026 12:30А, ну это для тех, у кого ТСПУ стоит. Не наш случай.
Meilleur-Q
27.08.2026 12:30В законе формулировка «если доступ к такой информации в сети связи оператора связи ограничивается с помощью технических средств противодействия угрозам» по логике, подразумевает мелкого провайдера с ТСПУ у аплинка.
RMavrichev
27.08.2026 12:30Обязанность ставить "ревизор" - никуда не делась, тут всё по прежнему.
А вот получать выгрузки из реестра и самостоятельно блокировать по ним - походу отменили (сам удивился, когда узнал что теперь этого не требуют).
CherryPah
27.08.2026 12:30местечковый провайдер, так он гораздо агрессивнее и быстрее всё блокирует
Ему страшнее. У него в отличие от ростелекома, не Медведев директор.
Hlad
27.08.2026 12:30Ростелеком, как замечают люди, пытается бежать впереди паровоза
Тем не менее, он отстаёт от Дома.Ру, который начал это практиковать примерно неделю назад.
salnicoff
27.08.2026 12:30«Дом.ру», по моим наблюдениями, начал практиковать забеги перед паровозом еще в 2017.
x86chk
27.08.2026 12:30Да-да, lawfilter.ertelecom.ru только на оголённых DNS-серверах был как раз примерно с 2017.
dartraiden
27.08.2026 12:30Так Роскомнадзор ещё году в 2018 рекомендовал провайдерам перехватывать трафик по 53 порту и заворачивать на провайдерский резолвер.
И дело тут не в беготне впереди паровоза, а в том, что это позволяло снижать нагрузку на провайдерский DPI. Когда абонент, использующий незащищённый DNS, пытается зайти на условный navalny.com, то перед установкой соединения его оборудование запрашивает у DNS-сервера "а какой IP-адрес у этого домена?". Если запрос перехватить и в ответ отдать NXDOMAIN или адрес заглушки, то соединение с navalny.com попросту не случится, следовательно, это соединение не придётся разбирать с помощью DPI, обнюхивая SNI. Завернул трафик по 53 порту через iptables на свой резолвер (который для "определенных" сайтов выдаёт неправильные ответы) - и можно нехило так снизить нагрузку на свой DPI.
В некоторых странах типа Великобритании или Австралии это (фильтрация ответов провайдерского DNS, без перехвата трафика к сторонним DNS) вообще единственный способ, которым провайдеры блокируют доступ к определенным сайтам. Там считают, что если уж пользователь очень захочет, то блокировку обойдёт, поэтому не видят смысла устраивать гонку брони и снаряда. Государство требует хоть как-то блокировать - вот вам формально заблокировано.
angry_agent Автор
27.08.2026 12:30Относительно перехвата DNS запросов со стороны операторов связи у меня есть следующие наблюдения:
-
Эр-телеком: подмены dst адреса нет, при использовании стороннего резолвера используется реально введённый DNS сервер в настройках системы или роутера (это видно по пингу и по всяким различным тестам "DNS утечки"), однако при попытке резолвинга заблокированных доменов по реестру, будет отдаваться IP-адрес заглушки (отдаёт так же только по UDP). Они отдают заглушку даже если резолвить домены извне:
~# dig rutracker.org @188.187.188.255 ; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> rutracker.org @188.187.188.255 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21106 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;rutracker.org. IN A ;; ANSWER SECTION: rutracker.org. 600 IN A 188.186.146.207 ;; Query time: 46 msec ;; SERVER: 188.187.188.255#53(188.187.188.255) (UDP) ;; WHEN: Sat Aug 29 12:38:58 MSK 2026 ;; MSG SIZE rcvd: 47При этом реального DNS сервера на
188.187.188.255- нет~# dig 2ip.ru @188.187.188.255 ;; communications error to 188.187.188.255#53: timed out(IP-адрес был взят наугад)
Уфанет: подмены ответа при использовании других резолверов нет, но на операторских DNS серверах заблокированные домены по реестру не резолвятся
Ростелеком: на их резолверах отдаётся в ответе
127.0.0.1при резолвинге фейсбука или инстаграма, с остальными ресурсами по типу рутрекера всё хорошо, при использовании сторонних серверов отдачи заглушки нет
Принцип работы перехвата DNS эр-телекома и ТСПУ значительно отличаются.
-
EmmGold
27.08.2026 12:30Помнится, лет 10-15 назад у Ростелекома уже был свой 8.8.8.8. Трассировка не выходила за их локалку.
fire64
27.08.2026 12:30Не только он.
Т-Мобайл, который является виртуальным провайдером Т2 тоже очень перегибает палки блокируя многие сети Гугла, из-за чего периодически не работают уведомления, сам Гугл и плеймаркет.
gluck59
27.08.2026 12:30В начале 2026 наблюдал интересное
На моей бывшей работе много лет сервер на Селектеле. В начале года стал работать как-то непонятно как — "то потухнет, то погаснет", сбои классификации не поддаются. Позвонили мне, попросили разобраться.
Перелопатил весь код, все чисто. Сисадмин говорит что у него прекрасно работает, у меня как раз непонятно что: первая страница сайта отрабатывает, а далее начинаются глюки, не поддающиеся классификации.
Устроили с сисадмином мозговой штурм и совершенно случайно выяснилось что сервер прекрасно работает если у посетителя провайдер не-ростелеком. Как только заходишь с ростелекома — всё, приехали.
У Селектела оказались лапки, а воевать с ростелекомом обычному юрлицу не вариант. Пришлось моей бывшей работе переехать на довольно измазанного во всяком хостера. Мы с сисадмином их перевозили — с тех. стороны у этого хостера полный кошмар, зато он весь такой из себя официальный, реклама на госсайтах висит и всё такое.
Cbiker
27.08.2026 12:30Вот да Ростелеком таким балуется. Прям от 30 до 70 % загрузки страницы обрубалось. При этом авторизация всегда 100% и первые 30% примерно всегда. И опять же очень важная работа у людей на тысячи сотрудников и СМИ с государством рапортуют о том как они всем нужны и важны, а Ростелекому пофиг.
yozora
27.08.2026 12:30А зачем этот западный DNS нужен? У нас свой DNS есть. И МВидео есть. Выбирайте.
Gansterito
27.08.2026 12:30Почему же западный? Абоненты билайн в Хабаровске ходят на восток - в Японию:
МТС же ходит через Гонконг:
Еще Ростелеком на коротке был с Google DNS, но он закрыл свой Looking Glass.
ardraeiss
27.08.2026 12:30Это, похоже, шутка про сеть магазинов электроники(и компов) DNS как "У тебя уже есть DNS дома"
Ratenti
27.08.2026 12:30Что на скриншоте с Билайном говорит про Японию?
kisaa
27.08.2026 12:30rtt 24 ms
Gansterito
27.08.2026 12:30+по трассировке видны японские IP-шники (трассировка работает через раз)
Скрытый текст
101.203.88.173 - японский адрес на площадке BBIX Tokyo
Kyoki
27.08.2026 12:30У нас давно все мобильные операторы или перехватывают, или блочат все паблик DNS. Переодически без чего-то типа AdGuard даже до белого списка не достучишься.
achekalin
27.08.2026 12:30С одной стороны, запомнить 77.88.8.8 вроде несложно, но вот что Яндекс, который уже давно ри за что не отвечает, однажды решит там отдавать - вопрос.
RoHaS
27.08.2026 12:30Ой не, эти вообще странные ребята. Поначалу(когда вот эта вся фигня только началась) хотели для стабильности офисный выход в инет на я. Днс перевести. Через день выяснилось, что они по одному ркн известной причине не отдают mx некоторых почтовых серверов в южной Америке. Почему? Хрен знает, но вернули православные 8.8.8.8 и забыли как страшный сон.
nitro80
27.08.2026 12:30у нас в офисе был любитель порно (не последний человек в конторе).
так я ему через dhcp стал отдавать яндексовский детский dns. он ругался, что интернет не работает, но при проверке - все сайты работали. какие именно не работали, человек не мог сказать )
iBljad
27.08.2026 12:30А его хобби приносило какой-то вред окружающим, раз пришлось принять меры?
<s>А то знаете, кто ещё решает за людей, что им смотреть в интернете?.. </s>
WaveLength
27.08.2026 12:30Гораздо интереснее зачем и как он умудрялся это на работе смотреть. Тип рядом же коллеги сидят, другие люди. Или может он по принципу музея "смотреть можно, трогать нельзя")
1A1A1
27.08.2026 12:30Мне коллега советовал: при прохождении курсов, когда начинаешь "плыть" от потока информации, переключаться на пару минут на порно для взбодрения. Но мне тогда курс и так "зашёл", за уши не оттянуть было - дай лабу сделать.
Jorell
27.08.2026 12:30А ведь Вы себя ведёте как РКН.
Добивает ещё и то, что комментарий плюсуют и плюсуют.
Чтож Вы, господа плюсующие, РКН-то тогда недолюбливаете? Или это другое?
В своё время мой директор(если что, очень шарил в IT) следил за менеджерами по продажам. Проверял кто куда лазит. И если человек больше 20% времени лазил не по делу, то вызывал его, показывал логи с развёрнутой статистикой, и конкретно намекал, что со следущего месяца премия будет рассчитываться из рассчёта проведённого времени "там где надо" и "где не надо". Менеджеры схватывали информацию с первого же предупреждения.
Понятно, что директор себя вёл как тов.майор. Но это всё же не так обидно, в отличии еслиб он себя вёл как Вы и РКН.
nitro80
27.08.2026 12:30Это было совершенно недавно, когда у нас канал в 256k считался очень хорошим, а мегабайт стоил около 2 рублей.
Финдиректор (по совместительству - жена председателя) очень скрупулёзно подсчитывала, кто и сколько трафика потребил (отчёт в excel выгружался из Traffic Inspector), если кто-то в обед смотрел допустим новости - вычитали с ЗП. И на меня в итоге ложилось всё это, объяснять, почему кто-то пошёл вот на этот сайт, и почему вообще есть возможность ходить туда.
Признаю, может поступал я тогда и некрасиво, но как же мне тогда обрыдло всё это, лавировать между ними. А после "подсовывания" безопасного dns - проблема ушла сама собой.
maniak
27.08.2026 12:30И это повлияло на эффективность работы примерно никак. Потому что "лазить не по делу" начали с смартфонов вместо компа.
nixtonixto
27.08.2026 12:30Во времена канала 256к смартфоны были с монохромным пиксельным дисплеем... И скорость GPRS...
vikarti
27.08.2026 12:30У яндекса еще прикол есть (ну или был в прошлом году) - почта с Proton mail на все(?) домены что используют яндексовскую почту для домена(или во что ее переименовали сейчас) - отбивается прямо при SMTP мол "спам". Насколько помню - техподдержка яндекса говорила что это РКН так сказал сделать.
Ну с другой стороны - вполне себе был повод устроить скандал с получателем мол у вас почта сломана вот логи (при этом зная что те кто на той стороне - не знают таких сложных деталей) и мол если хотите подтверждение - дайте рабочий адрес.
dartraiden
27.08.2026 12:30Это следствие довоенной истории со лжеминированиями, когда якобы один из кинутых пользователей биржи BTC-E (активы которой, как считается, отжал бизнесмен Малофеев) массово рассылал письма о бомбах. Сделать с отправителем ничего не могли, не реагировать на письма тоже не могли, поэтому российским почтовым сервисам приказали не принимать почту с популярных анонимных почтовиков (там не только Протон) по принципу "нет письма - нет проблемы".
Anywake
27.08.2026 12:30Шутки шутками, а какие альтернативы? Я вот пробовал яндекс ДНС, рабаоет плохо :(
itoolsy
27.08.2026 12:30unbound в режиме рекурсивного ресолвера
Anywake
27.08.2026 12:30на какие DNS? В unbound их и так 6 штук стоит, вопрос на что направлять, если вдруг эти заблочат (а они могут)?
itoolsy
27.08.2026 12:30Вы сейчас о чем?
В режиме рекурсивного ресолвера он не форвардит запрос, он сам ищет ответ, проходя все этапы: от корневых серверов до авторитетных самого домена.
navion
27.08.2026 12:30А запросы к корневым серверам ещё не перехватывают?Проверил, рекурсивные запросы пока работают.РКН требовал от владельцев ASN подключиться к НСДИ при наличии своих резольверов.
angry_agent Автор
27.08.2026 12:30А запросы к корневым серверам ещё не перехватывают?
Пока перехватывают только определённые DNS сервера
itoolsy
27.08.2026 12:30Я бы только аккуратно скачивал список рутовых серверов, проверяя контрольную сумму....
blind_oracle
27.08.2026 12:30Для верности можно вообще делать AXFR рутовой зоны к себе и не ходить к ним больше.
Но когда гэбня решит перехватывать все UDP/TCP/53 внаружу - это уже не поможет, конечно...
JcVai
27.08.2026 12:30Unbound в этом плане не самый лучший вариант.
Лучше обратить внимание на SmartDNS:
1. Параллельные запросы вместо последовательных
2. В режиме response-mode fastest-ip или first-ping с заблокированным маршрутом на "госзаглушки" будет отдавать "правильный a/aaaa" с "удаленного медленного аплинка" даже если быстрый ближний ответит nxdomain или перенаправит на "заглушку"
Kenya-West
27.08.2026 12:30DNSCrypt настроил... На московский DNSCrypt-резолвер, в основном. Сейчас думаю, а не фигню ли я сделал...
dartraiden
27.08.2026 12:30DNSCrypt при желании блокируется легко. Просто пока это неуловимый Джо, которым не шибко много народа пользуется.
Из интересного: перехватывают, похоже, только UDP, поэтому пока можно использовать TCP.
JoshMil
27.08.2026 12:30dnsmasq с разделением по доменам довольно неплохо работает. Часть доменов обслуживает один днс, часть другой. Я понятия не имею что там и как у ни работает но при таком способе настройки днс - перестает ломаться SSH сессия, браузер становится гораздо отзывчивее. И наоборот. Как только весь трафик dns идет в открытом виде - начинаются проблемы буквально со всем.
edo1h
27.08.2026 12:30но при таком способе настройки днс - перестает ломаться SSH сессия
dns никак не влияет на уже установленную ssh-сессию
nojecom
27.08.2026 12:30Ну что, подудосим ТСПУ?
while digyoutube.com@8.8.8.8 | grep NXDOMAIN; do :; donenitro80
27.08.2026 12:30что это даст?
Wizard_of_light
27.08.2026 12:30Там вроде пока ещё есть байпасы, если ТСПУ захлёбывается, часть данных через открытый канал начинает течь.
nitro80
27.08.2026 12:30Т.е. чем больше подобных запросов будет - тем сложнее будет работать оборудованию тспу?
Alonerover
27.08.2026 12:30Это, имхо, атака на свой собственный компьютер, а не на вражеские рогатки. Тут скорее надо запускать сертифицированные средства запутывания от известных товарищей и оставлять их крутиться 24/7/365. Пусть попробуют прожевать.
usiqwerty
27.08.2026 12:30Статью за атаку на служебное оборудование
glebliutsko
27.08.2026 12:30Почему на служебное? 8.8.8.8 - это адрес гугла. Так что это операция по выведению вражеского оборудования из строя.
AngusMetall
27.08.2026 12:30Кажется мы стали забывать как выглядит "атака на служебное оборудование")
*Вспоминает
путинвзрываетдома.рф
dartraiden
27.08.2026 12:30Я слышал, что кто-то эту идею реализовал ещё тогда, когда таким перехватом баловались сами провайдеры. Некто сгенерировал колоссальное количество исходящего трафика к стороннему DNS по 53 порту и в результате завалил DNS-сервер своего провайдера, на который весь этот трафик полетел в результате перехвата.
Чем закончилось, не знаю. Но формально это проблемы провайдера, который чужой трафик, не предназначенный ему, перенаправляет на свой сервис. У меня, скажем, торрент-клиент по 30000 порту отправляет 10 терабайт в месяц. Если провайдеру моча в голову стукнет этот трафик направить на какой-то свой сервис, то он сам себе злобный буратино.
ministr
27.08.2026 12:30Я сменил DNS с 8.8.8.8. Однако, другие серверы DNS выдают для 4pda.to и еще несколько сервисов уже заблокированные ip-адреса, а 8.8.8.8 выдают рабочие. Пришлось вручную задавать для некоторых адресов DNS 8.8.8.8 на роутере.
AlexKF
27.08.2026 12:30(я не программер на столько , на сколько в статье и комментах речь идет) но как понимаю видать еще чуть чуть и вправду на едине с чэбрнтом останемся (
nApoBo3
27.08.2026 12:30Интересно, какие для этого есть законные основания? Или уже даже изображать законность не модно?
nojecom
27.08.2026 12:30Мы подменили вам dns-запросы, и за это мы получим 100500 миллиардов денег на скрепный интернет и домик для утёнка. А вы нам ничё не сделаете *злобный смех*
Jvbx00
27.08.2026 12:30Ну что вы, никто ничего не блокирует. Это просто деградация электронов в проводах и фотонов в оптике, из за этого иногда не доходят пакеты
Kenya-West
27.08.2026 12:30А ведь, когда начнётся деградация (полураспад) протонов, то все по-настоящему офигеют!
git507
27.08.2026 12:30О законности вопроса таких оснований позаботились заблаговременно, приняв пакет яровой и начав борцовую борьбу с якобы экстремизмом/терроризмом.
Разворачивают на московские серваки не только с 8.8.8.8 и 1.1.1.1, но и DoT от циско, квад9 и прочее. Смена публичных DoT серваков спасает, но буквально на пару суток, с каждым разом дедлайн будет меньше - при каждой смене айпишника, дальше видать провайдерских начинают подгонять и они под видом технических работ разворачивают на скрепные серваки запросы.
Я бы рекомендовал всем прекратить мусолить эту тему столь открыто, т.к. решение этой проблемы на поверхности лежит, а в случае нахождения и публикации последней, не хотелось бы искать новые способы подключения к доверенным серверам. Цензоры читают вас и латают свои дыры благодаря вашей коммуникации.
nidalee
27.08.2026 12:30Гейткипинг никогда не был выигрышной стратегией, когда ваше решение с поверхности накроется медным тазом, рабочего решения вам никто не подскажет.
git507
27.08.2026 12:30А оно 100% накроется медным тазом, как только я выкачу гайд, а следом они начнут блочить панически вообще всё, что только может отдалённо напоминать этот способ.
nidalee
27.08.2026 12:30Ну я собственно о чем: если вы считаете себя умнее всех, в том числе людей, что пишут запреты и прочие костыли "для народа", то флаг вам в руки. Если сомневаетесь, то лучше присоединяться к сообществу и делиться решениями.
Kenya-West
27.08.2026 12:30Оно 100% накроется медным тазом, даже если вы не выкатите гайд. Может, на пару часов позже. Перестаньте думать за других.
Security through obscurity никогда не побеждал ни в чём.
Вы ведь сами писали:
решение этой проблемы на поверхности лежит
Значит, оно очевидно и врагу, верно? Или вы их совсем за валенков считаете? Соглашусь, это приятно, но приводит к недооценке преступлений, на которые они способны.
JBFW
27.08.2026 12:30Ситуация давно перешла в режим "поиска дырок в заборе" - работает такое только потому что на все дыры у заборостроителей рук не хватает. Но каждая обозначенная указателем дыра будет срочно заколочена.
Тут надо решать саму проблему существования забора - но это не на уровне рядовых ползователей...
nidalee
27.08.2026 12:30Но каждая обозначенная указателем дыра будет срочно заколочена.
Еще раз повторюсь, что первой версии запрета скоро 10 лет :)
0ka
27.08.2026 12:30Да не 10 лет ей, там было много обновлений за это время, многие стратегии обхода ркн успешно выводили из строя
nidalee
27.08.2026 12:30Многие выводил, еще больше осталось.
0ka
27.08.2026 12:30в иране был момент когда у меня ни 1 моя стратегия не работала. так что если сильно захотят то заблочат
Ndochp
27.08.2026 12:30Это не когда они тупо рубанули физически трансграничный маршрутизатор на некоторое время?
Kenya-West
27.08.2026 12:30JBFW
27.08.2026 12:30Хороший вариант, когда тебе лет 25, никаких сторонних обязательств, да и работы все равно тоже нет.
А потом накапливаются сложности...
AlekseyPraskovin
27.08.2026 12:30Интересно, какие для этого есть законные основания?
Наверняка есть какое-нить постановление правительства. А если и нет, то выпустить - дело на полчаса
Или уже даже изображать законность не модно?
Вас в каком году в криокамеру положили?
Hlad
27.08.2026 12:30Для чего? Происходит просто стремительное устаревание DNS-серверов по всему миру
salnicoff
27.08.2026 12:30Не путайте термины! Сервера, не устаревают, они деградируют!
Hlad
27.08.2026 12:30Точно, я забыл современные правила русского языка. Хотя, конечно, "быстрое окисление углеводородов с выделением тепловой энергии в результате падения обломков и последующего хлопка" мне не переплюнуть
Kurochkin
27.08.2026 12:30"Защита детей", "борьба с терроризмом", "для вашей безопасности", "по просьбам трудящихся" - выбирайте любую (пока есть выбор)
Shizarium
27.08.2026 12:30Защита безопасности детей от трудящихся террористов
Vindicar
27.08.2026 12:30Защита безопасности депутатских детей от террористически настроенных трудящихся...
1A1A1
27.08.2026 12:30Если быть объективным, то террор в данном случае устраивает само государство, поскольку "общественный договор" позволяет.
AlekseyPraskovin
27.08.2026 12:30террор в данном случае устраивает само государство
А не существует никакого абстрактного "государства". Любое государство - это Иван Иваныч, Петр Петрович и Семен Семеныч - вполне себе конкретные люди. Что характерно, не с Марса прилетевшие...
diksrv
27.08.2026 12:30Тспу стоит после bras/pe, и до nat оператора. Называть сие днатом некорректно, это спуфинг.
angry_agent Автор
27.08.2026 12:30В данном случае ТСПУ не занимается подделкой DNS ответа, он просто меняет dst адрес на НСДИ при выходе (только при условии, что в пакете содержится именно DNS запрос). У моего провайдера ТСПУ стоит после BRAS'a (PPPoE сервер фактически), у меня белый адрес, соответственно провайдерского CG-NAT в моём случае нет.
Я пробовал так же из интернета отправить самому себе DNS ответ заблокированного домена подделав src адрес на 8.8.8.8, подмены DNS ответа не произошло.
iDagLab
27.08.2026 12:30Уже около года использую собственный DNS (Unbound) поднятый на vps. Еще с момента блокировок DNS стало понятно, что это только начало. Поэтому любые отвалы, происходящие с тех пор узнаю только из новостей.
slalomjohn
27.08.2026 12:30Некоторые провайдеры уже давно блочат трафик на 53UDP наружу, кроме как на свои DNS сервера... Так что не всегда можно обойти
iDagLab
27.08.2026 12:30Да я не использую вообще незашифрованные DNS. Зачем провайдеру и прочим на пути моих запросов знать, на какие сайты я хожу? Не в то время живем, прошли те времена. Я использую только шифрованные DNS-запросы. Благо их стандартов много разных.
DrewUnknown
27.08.2026 12:30Со всей силы хочется чтобы все эти ТСПУ заблокировали сами себя.
blind_oracle
27.08.2026 12:30Рафик неуиноуат! Это же просто железяка. Надо людей "блокировать"
Shizarium
27.08.2026 12:30Ну в США камеры Flock так массово уничтожают силами трудового народа, что компания-подрядчик уже просит мира и переговоров, потому что финансово не вытягивает общественный гнев (осуждаю и не поддерживаю ужасные противоправные действия и тд и тп)
balamutang
27.08.2026 12:30Просто плохо поработали с электоратом, не объяснили как это полезно что безопасный город наблюдает за тобой
redtom
27.08.2026 12:30Проверил ещё несколько, аналогично тому, как показывал автор. 8.8.4.4, 1.0.0.1, 208.67.222.222 (OpenDNS) <- эти перехватываются тоже
si_12345
27.08.2026 12:30со вчерашнего дня ростелеком заблокировал напрочь lichess.org, не пингуется без впн
sergio_nsk
27.08.2026 12:30cppreference.com блокируют. Он им чем не угодил?
cppreference.net пока работает, но поисковики всегда выдают .com.
edo1h
27.08.2026 12:30Он им чем не угодил?
хостится на cloudflare же. у меня почти все домены на cf недоступны
woloss
27.08.2026 12:30Fastly же тоже давно блокируют?
Сегодня перестал работать dl-cdn.alpinelinux.com на нескольких провайдерах, возможно временно, до этого проблем не было.
p.s. Впрочем, сам дурак, пора уже собрать мегаобраз со всеми нужными зависимостями.woloss
27.08.2026 12:30Вдобавок, скачка с github releases работает 50/50, как раз решил обновить свои образы.
Reddit сначала только статика пропала, сейчас в целом не открывается. ~20 часов прошло, проблема пока только на Ростелекоме.
p.s. pypi.org, kernel.org работают и скачивание тоже
anzay911
27.08.2026 12:30Статья 274 УК РФ — Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей.
gotch
27.08.2026 12:30Сначала свой КВН, теперь свой DNS надо делать.
Такими темпами придется и свой Youtube с Tg поднимать.
Heggi
27.08.2026 12:30Да тут скорее свой интернет надо делать. Тут даже между хостерами РФ пакеты не всегда проходят по банальному 80 порту.
gotch
27.08.2026 12:30Да уже, с чего начинали, к тому и вернемся, правда раньше это фидонетом называли.
JcVai
27.08.2026 12:30Нуу, под BBS-ки модемы сейчас не достать, так что так далеко вряд ли.
А вот локалки со своими помойками... сначала через mesh, а после блокировки всех "несанкционированных" оверлеев - исключительно чистой местной/междомовой физикой - вполне.
nidalee
27.08.2026 12:30Да, была мысль, что возможно сделать сервис vod с ютуба, ну что-то типа tubearchivist выкачивать, что кругу друзей нужно - тогда нет "лишнего" трафика "за кордон". Но все найденные решения работали... Да не работали. Забил.
Heggi
27.08.2026 12:30На пикабу был чувак, еще на заре замедления ютуба, который сделал подобный сервис. В него кидаешь ссылку на ютуб, он выкачивает видос к себе и можно смотреть. Если совместить это с peertube, то, возможно, получится что-то годное.
Destructive
27.08.2026 12:30В ТГ есть подобные боты. Раньше таким способом сильно экономил на мобиле трафик, т.к. мессенджеры были безлимитными.
maximlubyanov
27.08.2026 12:30Peertube умеет не просто скачивать целые каналы с тытрубы, но синхронизировать.
https://docs.joinpeertube.org/use/channel-sync
Shizarium
27.08.2026 12:30Ютуб сильно порезал возможности так качать, в том числе после того, как православный Рутуб в промышленных масштабах пытался сосать видео на свои сервера.
balamutang
27.08.2026 12:30Там сильно совпало с новым этапом принуждения к платным подпискам, гашение Vanced/ReVanced, так что за хилый (в масштабах ютуба) рутуб бы я не топил. Хотя возможно и не без этого
balamutang
27.08.2026 12:30дык и ютубу это невыгодно, просмотры/охваты падают, реклама не показывается. поэтому такие сервисы будут гасить со всех сторон
Jorell
27.08.2026 12:30Так им всего-то осталось в своём dns прописать адрес макса вместо тг и адрес рутуба вместо youtube.
tarielx
27.08.2026 12:30Поднял приватный Invidious для некоторых знакомых. В целом работает, но нужна VPS мощнее, чем самая дешёвая.
Diprog
27.08.2026 12:30О, спасибо большое за оперативный разбор! У меня вчера как раз многие сервисы поломались, и я грешил на DNS. Вот оно что. Даже на местечковом провайдере(
gtsoos
27.08.2026 12:30Честно говоря, ничего в этом не понимаю, но на днях перестал работать Ютуб через zapret, на windows 7 (в роутере ставил dns от google)
Vindicar
27.08.2026 12:30Логично. Насколько я знаю, byedpi и его форки типа запрета полагаются на системный DNS. Если системный DNS не может найти адрес для имени сайта, то запрет не поможет. Нужен полноценный туннель.
nidalee
27.08.2026 12:30Не столько byedpi, сколько сама система Windows. По дефолту она резолвит домены сама, это не дается на усмотрение приложениям.
Vindicar
27.08.2026 12:30<душнила mode>В браузере есть опция "резолвить DNS через прокси". Но так как в случае byedpi прокси целиком на клиентской машине, то он может полагаться только на системный DNS. Как следствие, включение опции не меняет ничего. А вот туннели вроде VLESS могут попросить об этом свой сервер и получить правильный ответ.</душнила mode>
0ka
27.08.2026 12:30поставь 9.9.9.9 в роутере
angry_agent Автор
27.08.2026 12:30Во будет анекдот, если 9.9.9.9 начнут перехватывать, а потом у него снова всё сломается)
Nemoumbra
27.08.2026 12:30Это только A и AAAA записи? Или всякие TXT тоже перенаправляют на национальный сервер?
angry_agent Автор
27.08.2026 12:30Проверил резолвинг TXT записей, они не перехватываются (DNAT не происходит)
Nemoumbra
27.08.2026 12:30А попробуйте после отправки UDP с ttl 2 подождать N мс и только тогда отправить обычный с ttl 64. И покрутить N.
Потому что у вас в примере с реальным DNS был таймаут 3 секунды. А с рандомным пакетом - нет. Возможно, там надо подождать. А в случае с DNS интересно, какой максимальный N.
angry_agent Автор
27.08.2026 12:30Получил NXDomain при отправке DNS запроса через 3 секунды после рандомного пакета:
~# tcpdump -n -i ppp0 host 8.8.8.8 -v tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes 14:45:49.622629 IP (tos 0x0, ttl 2, id 30900, offset 0, flags [none], proto UDP (17), length 922) X.X.X.X.51228 > 8.8.8.8.53: 42463 updateA YXRRSet-$ [3055q], [|domain] 14:45:52.719270 IP (tos 0x0, ttl 64, id 3061, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.51228 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54) 14:45:52.730385 IP (tos 0x0, ttl 60, id 47761, offset 0, flags [none], proto UDP (17), length 70) 8.8.8.8.53 > X.X.X.X.51228: 35076 NXDomain* 0/0/1 (42)Интервала как такового нет, даже через 1 секунду такой же результат
С реальным DNS запросом при TTL 2 такая же ситуация, подождал целую минуту, а в ответ пришли настоящие IP-адреса:
~# tcpdump -n -i ppp0 host 8.8.8.8 -v tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes 14:51:29.036601 IP (tos 0x0, ttl 2, id 63092, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.40231 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54) 14:52:29.133634 IP (tos 0x0, ttl 64, id 37612, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.40231 > 8.8.8.8.53: 35076+ [1au] A? rutracker.org. (54) 14:52:29.300782 IP (tos 0x0, ttl 109, id 5868, offset 0, flags [none], proto UDP (17), length 102) 8.8.8.8.53 > X.X.X.X.40231: 35076 2/0/1 rutracker.org. A 104.21.32.39, rutracker.org. A 172.67.182.196 (74)Nemoumbra
27.08.2026 12:30Хмм... Подозрительно большой интервал. Советую продолжать увеличивать таймаут, одновременно меняя домены, чтобы исключить возможность кеширования. Какой-нибудь кеш может подпортить эксперимент.
И ещё придумал - как насчёт чередования A и AAAA запросов? Ну вдруг A с ttl 2 разблокирует AAAA на тот же домен и наоборот.
Ну и третье - попробуйте в один из запросов (ttl2 или ttl64) докинуть несущественных опций, чтобы побайтно пакеты стали отличаться.
Что-то разыгралось у меня воображение... Можно ещё и просто немного подкрутить DNS и посмотреть, будет ли DNAT (по icmp ответу). Например, рандомных байтов в конец пакета дописать. Один и тот же ID запроса подставлять. QCLASS поменять.
angry_agent Автор
27.08.2026 12:30~# tcpdump -n -i ppp0 host 8.8.8.8 -v tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes 16:31:22.488412 IP (tos 0x0, ttl 2, id 42116, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.30233 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47) 16:31:23.586324 IP (tos 0x0, ttl 64, id 30743, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.30233 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54) 16:31:23.630545 IP (tos 0x0, ttl 108, id 39417, offset 0, flags [none], proto UDP (17), length 102) 8.8.8.8.53 > X.X.X.X.30233: 14557 2/0/1 rutracker.org. A 104.21.32.39, rutracker.org. A 172.67.182.196 (74)Вы можете и самостоятельно экспериментировать, если у вас нет перехвата DNS запросов, то вы можете найти хостинг с подобным явлением из этого списка - https://globalping.io/?measurement=2TnuCfL63NIYzgR1Y001211g2&display=table
Могу лишь предположить, что ТСПУ перестаёт делать DNAT после получения ICMP TTL Exceeded:
~# tcpdump -n -i ppp0 host 8.8.8.8 or icmp -v tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes 16:44:44.926651 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47) 16:44:44.934296 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56) A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36 IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 195.208.5.1.53: [|domain] 16:44:45.928461 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47) 16:44:45.933575 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56) A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36 IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: [|domain] 16:44:46.929807 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47) 16:44:46.932393 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56) A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36 IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: [|domain] 16:44:47.931497 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47) 16:44:47.935700 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56) A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36 IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: [|domain] 16:44:48.933436 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47) 16:44:48.934812 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56) A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36 IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: [|domain] 16:44:49.935547 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47) 16:44:49.937371 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56) A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36 IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: [|domain] 16:44:50.937174 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47) 16:44:50.938080 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56) A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36 IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: [|domain] 16:44:51.938533 IP (tos 0x0, ttl 2, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: 58876+ [1au] A? 2ip.ru. (47) 16:44:51.939320 IP (tos 0x0, ttl 254, id 0, offset 0, flags [none], proto ICMP (1), length 56) A.A.A.A > X.X.X.X: ICMP time exceeded in-transit, length 36 IP (tos 0x0, ttl 1, id 52279, offset 0, flags [none], proto UDP (17), length 75) X.X.X.X.25212 > 8.8.8.8.53: [|domain]Но при резолвинге по несколько раз с TTL 64 в рамках одного соединения отдаёт NXDomain стабильно (за исключением случая кратковременно большого pps/rps, как это описано в статье):
~# tcpdump -n -i ppp0 host 8.8.8.8 -v tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes 16:42:40.789678 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54) 16:42:40.800943 IP (tos 0x0, ttl 60, id 45883, offset 0, flags [none], proto UDP (17), length 70) 8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42) 16:42:41.790464 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54) 16:42:41.801422 IP (tos 0x0, ttl 60, id 45984, offset 0, flags [none], proto UDP (17), length 70) 8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42) 16:42:42.792903 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54) 16:42:42.803986 IP (tos 0x0, ttl 60, id 46022, offset 0, flags [none], proto UDP (17), length 70) 8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42) 16:42:43.794361 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54) 16:42:43.812382 IP (tos 0x0, ttl 60, id 37938, offset 0, flags [none], proto UDP (17), length 70) 8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42) 16:42:44.796254 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54) 16:42:44.807262 IP (tos 0x0, ttl 60, id 46353, offset 0, flags [none], proto UDP (17), length 70) 8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42) 16:42:45.797252 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54) 16:42:45.814865 IP (tos 0x0, ttl 60, id 38123, offset 0, flags [none], proto UDP (17), length 70) 8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42) 16:42:46.799729 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54) 16:42:46.818311 IP (tos 0x0, ttl 60, id 38189, offset 0, flags [none], proto UDP (17), length 70) 8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42) 16:42:47.801971 IP (tos 0x0, ttl 64, id 3983, offset 0, flags [none], proto UDP (17), length 82) X.X.X.X.29231 > 8.8.8.8.53: 14557+ [1au] A? rutracker.org. (54) 16:42:47.819693 IP (tos 0x0, ttl 60, id 38337, offset 0, flags [none], proto UDP (17), length 70) 8.8.8.8.53 > X.X.X.X.29231: 14557 NXDomain* 0/0/1 (42)По пути у меня нет узлов, которые бы не отдавали ICMP TTL Exceeded.
AndreyCodes
27.08.2026 12:30ТСПУ + сертификат минцифры = потенциальная подмена сайтов с "нужным содержимым"
angry_agent Автор
27.08.2026 12:30Если учитывать текущую техническую реализацию (а реализовано оно усечённым, легковесным и одновременно странным DNAT), то 443 порт должен уходить на какой-то сторонний прокси сервер в интернете, этот самый прокси должен по SNI отрезолвить домен, в результате чего исходный IP-адрес клиента просто потеряется (если его не добавлять отдельным заголовком конечно), это сломает веб-ресурсы, которые доступны только по белым спискам src адресов.
Если конечно, ТСПУ не научится в полноценный MITM в рамках TLS без потерь IP-адресов, или если провайдер не разместит прокси сервера у себя.
woloss
27.08.2026 12:30Я не спец, но разве через подмену 53/udp они не могут отдавать какой нужно IP? Контролируя CA, в теории могут подписать любой домен (могу ошибаться). Возможно, Chrome как-нибудь дополнительно проверяет гугл адреса.
angry_agent Автор
27.08.2026 12:30Через DNS тоже можно отдавать A/AAAA записи самого прокси сервера, но в случае использования DoH провести MITM не получится.
woloss
27.08.2026 12:30Я имею в виду теоретический случай, когда DoH/DoT больше нет, остался только 53/udp с правильными записями.
angry_agent Автор
27.08.2026 12:30Ничего не мешает поднять свой приватный DoH сервер и пользоваться им (если публичные перебанят, или если ГРЧЦ/ЦМУ ССОП начнёт путём сканирования всего интернета искать DoH сервера дёргая GET/POST /dns-query и блокировать их)
fLegmatik
27.08.2026 12:30Если вы поставили в систему сертификаты минцифры, не сможет ли промежуточный узел перехватывать запросы к вашему doh-серверу?
j_larkin
27.08.2026 12:30Дома doh до единичек пока работает (правда у CF сервер в мск), а вот на работе столкнулся и с тем, что простые восьмерки не отвечают. Пришлось в срочном порядке инфру нескольких клиентов переключать на другие днс. Происходящее осуждаю.
angry_agent Автор
27.08.2026 12:30А TXT записи резолвятся через восьмёрки в незашифрованном DNS? Если исходящий и входящий трафик проходят через разные ТСПУ, то вряд ли трансляция адресов будет корректно работать в этом случае, ответ придёт далеко не от 8.8.8.8
MrBotikkk
27.08.2026 12:30Заблокированные домены для проверки: rutor.info, flibusta.is, clubtone.do.am, rezka.ag, shikimori.one Незаблокированные домены для проверки: vk.ru, gosuslugi.ru ВНИМАНИЕ: Это независимая проверка и она не использует ваши настроенные DNS! Проверено серверов: 65/65 Итог DNS доступность 28/33 DoH 32/32 UDP Подмена резолвера Cloudflare, Google Подмена ответов у 10/32 UDPfullscreen
TimurZhoraev
27.08.2026 12:30А в чём проблема сделать нормальный захардкоженный утверждённый атлас белых IP адресов и распространять через киоск "Союзпечать", создать Единый классификатор адресов, ГОСТ. Например резольвить aaa.bbb.ccc.ddd 001. - айпишники пожарных организаций, 002 - полиция, 003 - скорая, 004 - сайт Газпром итд
OlegZH
27.08.2026 12:30В ответ следует вставить соответствующую дежурную картинку красного цвета.
TimurZhoraev
27.08.2026 12:30Зачем картинки, когда есть вполне определённый текст - Постановление Правительства РФ от 27.10.2025 N 1667 и № 156-ФЗ. Многофункциональный сервис, наверняка API будет соответствующий. Удобно, можно забыть про всякие netstat, tracert, tcpdump, dig как пережитки прошлого
OlegZH
27.08.2026 12:30Имеют ли к этому какое-то отношение разговоры о том, что некие нехорошие люди ходят, сканируют роутеры, вставляют подменные DNS-сервера и получают всё, что им нужно напрямую?
Komrus
27.08.2026 12:30Чегой-то со вчерашнего вечера (с 28.08) вааще всё отваливаться стало в этих ваших Интернатах...
До этого -"много чего", а вот со вчерашнего - вааще почти всё... :(((
m0xf
Ещё этот DNS очень тормозит и плохо отвечает на запросы.
mumische
Началось пораньше, где-то 23-24 августа. СПб, PIN и Futures Telecom - сначала начали блокировать DOH, а затем запросы к 8.8.8.8 то работают, то отваливаются по таймауту. У Futures Telecom проблема сохраняется, вчера вечером перенастраивал у друзей.