Не вижу смысла. Этот параграф я больше не считаю релевантным:
Валить в панике из страны? Заворачивать весь трафик в VPN? Зачем! Интернет в России ещё не настолько поломан, чтоб добавлять 50-100ms ко всем своим Zoom-созвонам во времена повсеместной самоизоляции.
Ну, например, 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() завис, даже соединения из очереди не забираются:
Кажется, мы нашли какой-то баг в Unbound или его конфигурации. С DNS-over-TLS у меня сейчас тоже наблюдаются проблемы, а DNS-over-HTTPS работает нормально. При том диагностики примерно нуль: сервер просто ИНОГДА не отвечает на Client Hello, а в мониторинге всё хорошо (отсох почему-то только IPv4, а мониторинг предпочитает IPv6 при dual-stack).
Нет, это существенно другая конструкция. Примерно вся разница описана в этом параграфе:
выкидывать из DNS ответов заблокированные IP адреса а, если адресов не осталось, заменять их на подходящие адреса с того же CDN
Это нарушение стандартов работы DNS и выкатывать такое "по-умолчанию" большой сервис позволить не может.
Собственно, пару недель тому назад на https://cloudflare.comнельзя было зайти — оба IP адреса из ответа были заблокированы по предварительному обеспечению по "пиратке".
Кстати, а почему https://quantum-a.co/ не вспомнил? :-) Некоторый кусок инфраструктуры от них: редирект идёт на r.analytic.press, который 195.19.216.34, у которого admin-c: PM19270-RIPE, который Pavel Manyakin, у которого тёзка в R&D MegaLabs. Мегафон это всё же не совсем MRG. Так, на две трети :-)
Там подобных историй про Ростелеком десятки и самые старые полуторагодовалой давности. И при том все эти истории про Сибирский макрорегион: Томск, Красноярск, Иркутск, Ангарск, Барнаул, Новосибирск...
Занятно ещё, что Kaspersky_Lab поучаствовали в истории в позитивном ключе, забанив один из доменов, использующихся для раздачи редиректов (не то чтоб это надолго помогло).
В публичных интернетах я такие упоминания ещё нашёл:
Не вижу смысла. Этот параграф я больше не считаю релевантным:
Сервис выключен с 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()завис, даже соединения из очереди не забираются:Кажется, мы нашли какой-то баг в Unbound или его конфигурации. С DNS-over-TLS у меня сейчас тоже наблюдаются проблемы, а DNS-over-HTTPS работает нормально. При том диагностики примерно нуль: сервер просто ИНОГДА не отвечает на Client Hello, а в мониторинге всё хорошо (отсох почему-то только IPv4, а мониторинг предпочитает IPv6 при dual-stack).
Буду разбираться. На smoke-тесте всё работало.
Да так, мелкий самодельный утиль.
В публичном виде это выглядит как @u2ckbot от schors.
Отличные ребята! Спасибо! Я посмотрю немного подробнее, что именно они делают. Жаль, исходников конфигурации не выкладывают.
Нет, это существенно другая конструкция. Примерно вся разница описана в этом параграфе:
Это нарушение стандартов работы DNS и выкатывать такое "по-умолчанию" большой сервис позволить не может.
Собственно, пару недель тому назад на https://cloudflare.com нельзя было зайти — оба IP адреса из ответа были заблокированы по предварительному обеспечению по "пиратке".
Я в первом приближении сделал, но немного огрёб граблей в процессе. https://habr.com/en/post/538806/
FFAMax, а меня память подводит, или у тебя был готовый "умный резольвер", который выкидывал из ответа resource records с заблокированными адресами?
И до Санкт-Петербурга тоже добралось внедрение данной конструкции. Всё тот же редирект на
r.analytic.press.Кстати, а почему https://quantum-a.co/ не вспомнил? :-) Некоторый кусок инфраструктуры от них: редирект идёт на
r.analytic.press, который195.19.216.34, у которогоadmin-c: PM19270-RIPE, которыйPavel Manyakin, у которого тёзка в R&D MegaLabs. Мегафон это всё же не совсем MRG. Так, на две трети :-)Там подобных историй про Ростелеком десятки и самые старые полуторагодовалой давности. И при том все эти истории про Сибирский макрорегион: Томск, Красноярск, Иркутск, Ангарск, Барнаул, Новосибирск...
Занятно ещё, что Kaspersky_Lab поучаствовали в истории в позитивном ключе, забанив один из доменов, использующихся для раздачи редиректов (не то чтоб это надолго помогло).
В публичных интернетах я такие упоминания ещё нашёл:
*) уже упомянутые выше
Простите, я что-то упускаю один момент — а зачем судьи в идеальном обществе?