Найти в Дзене
птица говорун

очередной потуг РКН

а может и РКН и не причём. наблюдаем забавную ситуацию: сервер ростелекома: drill rr7---sn-gvnuxaxjvh-n8ves.googlevideo.com @46.61.250.136
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 36996
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; rr7---sn-gvnuxaxjvh-n8ves.googlevideo.com. IN A
;; ANSWER SECTION:
rr7---sn-gvnuxaxjvh-n8ves.googlevideo.com. 5810 IN CNAME rr7.sn-gvnuxaxjvh-n8ves.googlevideo.com.
rr7.sn-gvnuxaxjvh-n8ves.googlevideo.com. 906 IN A 79.133.85.146
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 2 msec
;; SERVER: 46.61.250.136
;; WHEN: Sat Feb 14 00:01:35 2026
;; MSG SIZE  rcvd: 113 остальное покажу сокращённо. сервер яндекс: drill rr7---sn-gvnuxaxjvh-n8ves.googlevideo.com @77.88.8.8
...
rr7.sn-gvnuxaxjvh-n8ves.googlevideo.com. 1447 IN A 79.133.85.146
сервер гугл: drill rr7---sn-gvnuxaxjvh-n8ves.googlevideo.com @8.8.8.8
. . .
rr7.sn-gvnuxaxjvh-n8ves.googlevideo.com. 1800 IN A 79.133.85.146
никаких ан
Оглавление

пролог

а может и РКН и не причём. наблюдаем забавную ситуацию:

сервер ростелекома:

drill rr7---sn-gvnuxaxjvh-n8ves.googlevideo.com @46.61.250.136

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 36996
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; rr7---sn-gvnuxaxjvh-n8ves.googlevideo.com. IN A

;; ANSWER SECTION:
rr7---sn-gvnuxaxjvh-n8ves.googlevideo.com. 5810 IN CNAME rr7.sn-gvnuxaxjvh-n8ves.googlevideo.com.
rr7.sn-gvnuxaxjvh-n8ves.googlevideo.com. 906 IN A 79.133.85.146

;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:

;; Query time: 2 msec
;; SERVER: 46.61.250.136
;; WHEN: Sat Feb 14 00:01:35 2026
;; MSG SIZE  rcvd: 113

остальное покажу сокращённо. сервер яндекс:

drill rr7---sn-gvnuxaxjvh-n8ves.googlevideo.com @77.88.8.8
...
rr7.sn-gvnuxaxjvh-n8ves.googlevideo.com. 1447 IN A 79.133.85.146

сервер гугл:

drill rr7---sn-gvnuxaxjvh-n8ves.googlevideo.com @8.8.8.8
. . .
rr7.sn-gvnuxaxjvh-n8ves.googlevideo.com. 1800 IN A 79.133.85.146

никаких аномалий не видно. но на ютубе народ уже по теме отлаялся:

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

Липову дали последний шанс заблокировать ютуб? проверка от РКН на вшивость? чья-то бесполезная инициатива? какой-нибудь сервер отвалился?

мне судить сложно я об этом узнал из выпуска Каца - у меня все отлично работало правда у меня DoH настроен очень давно.

озвученная версия у Каца критики не выдерживает. ютуб у меня заблокирован по SNI. вернее это не блокировка, а попытка блокировки.

P.S.

а все довольно банально да это проделки РКН. эта атака на хостинг на котором размещался telegram т.е. клаудфлер. сделать можно технологией которая получила в народе название "белые списки". название крайне неудачное - это гибридная технология, а ограничение на XX килобайт следствие её архитектуры, списки тоже могут быть любого цвета. я эту технологию уже описывал, быстро напомню.

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

когда программная управляющая часть выясняет что адрес принадлежит списку, он командует файрволу блокировать пользовательский сокет. фаирвол вспоминает пользовательский сокет и блокиркет его на время тайм аута соединения. после истечении времени тайм аута информация о пользовательском сокете больше ненужна и она удаляется, сам сокет разблокируется. благородя такому подходу высвобождается память. т.е. аппаратной часть может оставаться сравнительно простой. такую архитектуру использует великий китайский фаирвол.

система только кажется неуязвимой, а на в самом имеет особую чувствительность к перегрузке, скорей всего она неуязвима с внутренней стороны. но зато с внешней стороны её легко забросать бесполезными пакетами. возможно все несколько сложнее и система не будет реагировать просто на поток пакетов с внешней стороны без пакетов с внутренней стороны на установку соединения.

эта такая попытка сделать систему более устойчивой. но суть это особо не меняет. в качестве ботнета можно использовать инфраструктуру хостинг-провайдера и оправить ей миллиард пакетов на установку соединения и от неё придет миллиард ответов от веб серверов.

что система сильно зависит от нагрузки видно хотя бы вот по такому признаку. если ночью сделать запрос, то все остановится и вы ничего не получите:

curl -4 -v https://radar.cloudflare.com/traffic/ru
> GET /traffic/ru HTTP/2
> Host: radar.cloudflare.com
> User-Agent: curl/8.17.0
> Accept: */*
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):

однако если тоже самое сделать днём вы получите некоторое количество данных от сервера в зависимости от нагрузки на систему. но закончится это ожидаемо:

* Recv failure: Операция превысила лимит времени
* OpenSSL SSL_read: Операция превысила лимит времени, errno 60
* Failed receiving HTTP2 data: 56(Failure when receiving data from the peer)
* Send failure: Канал разрушен
* OpenSSL SSL_write: OpenSSL/3.5.4: error:80000020:system library::Канал разрушен, errno 32
* Connection #0 to host radar.cloudflare.com:443 left intact
curl: (56) Recv failure: Операция превысила лимит времени