Pull to refresh
165
0
Leonid Evdokimov @darkk

Пользователь

Не вижу смысла. Этот параграф я больше не считаю релевантным:

Валить в панике из страны? Заворачивать весь трафик в VPN? Зачем! Интернет в России ещё не настолько поломан, чтоб добавлять 50-100ms ко всем своим Zoom-созвонам во времена повсеместной самоизоляции.

Сервис выключен с 04 марта 2022 года.

Ну я в какой-то момент перенёс его на виртуалку пожирнее =)

Ну это скорее в исходниках. Там не сложно, но ничего особо интересного :-)

Ну, например, mozilla.cloudflare-dns.com has address 104.16.248.249, а 104.16.248.249 заблокирован со ссылкой на Октябрьский районный суд г. Ставрополя 2-946/13 2013-06-10.


У 8.8.8.8 и 1.1.1.1 (не путать с dns.google и one.one.one.one) причина тоже понятна — в запросах к ним нет SNI и такое некоторые DPI не любят.

Версия из debian:testing с пересобранным пакетом, т.к. DoH по-умолчанию не собирается. Там не в TLS дело, там в какой-то момент на серверном сокете происходит "нечто", после чего он перестаёт accept()-ить новые соединения, это отлично видно в strace. Я пока уверен, что это баг в Unbound и я попробую с ним разобраться.

Для меня это звучит неожиданно. Если вам интересна причина такого поведения вашей сети — давайте вместе в ней попробуем разобраться.

С технической точки зрения — в точности так!

Сейчас должно работать. Но когда оно опять сломается — я предсказать не берусь пока, но по крайней мере своевременно теперь узнаю. Будем разбираться и починять. Собственно, в том числе для теста технологии я эту конструкцию и собрал :-)

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


Но в целом там accept() завис, даже соединения из очереди не забираются:


State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process 
LISTEN  157     256           0.0.0.0:853        0.0.0.0:*     users:(("unbound",pid=4167,fd=8)) 
LISTEN  197     256           0.0.0.0:443        0.0.0.0:*     users:(("unbound",pid=4167,fd=4)) 
LISTEN  0       256              [::]:853           [::]:*     users:(("unbound",pid=4167,fd=10)) 
LISTEN  0       256              [::]:443           [::]:*     users:(("unbound",pid=4167,fd=6)) 

Кажется, мы нашли какой-то баг в Unbound или его конфигурации. С DNS-over-TLS у меня сейчас тоже наблюдаются проблемы, а DNS-over-HTTPS работает нормально. При том диагностики примерно нуль: сервер просто ИНОГДА не отвечает на Client Hello, а в мониторинге всё хорошо (отсох почему-то только IPv4, а мониторинг предпочитает IPv6 при dual-stack).


Буду разбираться. На smoke-тесте всё работало.

Да так, мелкий самодельный утиль.


В публичном виде это выглядит как @u2ckbot от schors.

Отличные ребята! Спасибо! Я посмотрю немного подробнее, что именно они делают. Жаль, исходников конфигурации не выкладывают.

Нет, это существенно другая конструкция. Примерно вся разница описана в этом параграфе:


выкидывать из DNS ответов заблокированные IP адреса а, если адресов не осталось, заменять их на подходящие адреса с того же CDN

Это нарушение стандартов работы DNS и выкатывать такое "по-умолчанию" большой сервис позволить не может.


Собственно, пару недель тому назад на https://cloudflare.com нельзя было зайти — оба IP адреса из ответа были заблокированы по предварительному обеспечению по "пиратке".

Я в первом приближении сделал, но немного огрёб граблей в процессе. https://habr.com/en/post/538806/

это достаточно просто реализовать в Knot Resolver и PowerDNS Recursor

FFAMax, а меня память подводит, или у тебя был готовый "умный резольвер", который выкидывал из ответа resource records с заблокированными адресами?

И до Санкт-Петербурга тоже добралось внедрение данной конструкции. Всё тот же редирект на r.analytic.press.

Mail.Ru Group

Кстати, а почему https://quantum-a.co/ не вспомнил? :-) Некоторый кусок инфраструктуры от них: редирект идёт на r.analytic.press, который 195.19.216.34, у которого admin-c: PM19270-RIPE, который Pavel Manyakin, у которого тёзка в R&D MegaLabs. Мегафон это всё же не совсем MRG. Так, на две трети :-)

а darkk — вот эти… это крайне регионозависимо

Там подобных историй про Ростелеком десятки и самые старые полуторагодовалой давности. И при том все эти истории про Сибирский макрорегион: Томск, Красноярск, Иркутск, Ангарск, Барнаул, Новосибирск...


Занятно ещё, что Kaspersky_Lab поучаствовали в истории в позитивном ключе, забанив один из доменов, использующихся для раздачи редиректов (не то чтоб это надолго помогло).


В публичных интернетах я такие упоминания ещё нашёл:



*) уже упомянутые выше

Простите, я что-то упускаю один момент — а зачем судьи в идеальном обществе?

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity