30 января в 18:20 (MSK) пользователи столкнулись с массовым сбоем определения хостов в доменной зоне RU, вызванный ошибкой при смене ключей, используемых для заверения достоверности зоны RU через DNSSEC. В результате инцидента на DNS-серверах, применяющих DNSSEC для проверки достоверности данных, перестали определяться все домены в зоне ".ru". Проблема затронула только пользователей, использующих DNS-резолверы провайдеров или публичные DNS-сервисы, такие как 8.8.8.8, верифицирующие достоверность запросов при помощи DNSSEC. Пользователей DNS-резолверов, на которых DNSSEC отключён, не пострадали...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60527
>после перехода на новый ключ из-за ошибки перестала проходить проверка подлинностиА в чем ошибка была, собственно?
Записи в зоне RU другим ключом подписали, не тем, что указан в записи DNSKEY. Они параллельно пилят отечественный изолированный DNS (НСДИ, национальная система доменных имён), видимо ключи c ним перепутали. Но подробностей что у них случилось пока нет, лишь общие отписки.
А почему давно не запилили, DNS разве не на СПО зиждится?
Причем тут СПО и зачем что-то пилить?
Косплеить корневой сервер можно хоть на MS ШиндовсВсе и так готово к своим доменным именам.
Делаешь свой корневой сервер, пилишь там свои зоны с поэтессами и настраиешь свой комплюктер на взаимодействие с ним.
Все тоже самое, но в масштабах государства.Если захотят прозрачно, то из-за этих ваших днс-секов и днс-офер-хттп клаудфларесеков - не получится. А так заворачивать 8.8.8.8 на свои научились уже давно.
> Записи в зоне RU другим ключом подписали, не тем, что указан в записи DNSKEY.Похоже, у них там свой набор верхних корневых днс-серверов. Его ключом и подписали. Но выдали в запросах с общепринятых корневых, а не со своих. Ждать осталось недолго, когда теневая система заменит основную. Шифрование/сертификаты - там всему можно перестать доверять уже сейчас.
> там всему можно перестать доверять уже сейчасБлажен кто верует что западным штуковинам можно было доверять
википедия соврать не даст
Думаю, западным спецслужбам до Васяна из опеннета дела нет. А вот нашим - есть. Так что безопаснее использовать то, до чего нет доступа спецслужбам твоей страны, где бы эта страна не находилась.
>видимо ключи c ним перепуталиА какой смысл использовать разные ключи?
НСДИ они тоже положили. Но поскольку это кого надо НСДИ, там быстренько почистили кэш и сделали вид что так и было.Впрочем, второй возможный и даже более вероятный вариант - что "перепутали" намеренно.
>Но поскольку это кого надо НСДИНаверное больше потому, что от НСДИ почти никто из потребительского сегмента пока не зависит, поэтому прошло почти незаметно.
Еще как уже зависят. Просто тебе об этом не доложат.Просто поскольку он сам себе корень - его дернуть можно было без шума и пыли. Ну а насколько оно нечаянно получилось (те кто переключили свои ресолверы на НСДИ вряд ли сегодня отключат) - это вот вопрос к товарищмайору. Но у нас с тобой не те звания чтоб нам донесли ответ.
Докладываю: ни один провайдер долго не проработает, если его днс-серверы не будут подключены к НСДИ. Могу утверждать, как сотрудник провайдера выполнявший данные требования на днс-серверах нашей компании.
А чего тут тогда все у всех навернулось? Они ж там всепачинили через пять минут после того как кто-то умный показал на ошибку.Где-то что-то ты привираешь. Как они могут проверить что и куда у тебя там подключено? Роспозоровская коробка этого не умеет, никаких "ежедневных выгрузок" (где тоже смешно потому что проверяется что ты их скачал а не куда именно засунул) и вроде никаких очевидных способов.
Есть разные схемы подключения к НСДИ.
>НСДИ они тоже положили. Но поскольку это кого надо НСДИ, там быстренько почистили кэш и сделали вид что так и было.Быстренько? Да он минут 20 косплеил под всех отвечая на всё SRVFAIL. А потом там додумались или отключить валидацию или подсунуть свой ключ.
А корень .ru просто за DDoSили резолверы, которые тыкались во все прописанные в зоне адреса, получали подписанный ответ, проверяли, выкидывали и так по кругу.
>Впрочем, второй возможный и даже более вероятный вариант - что "перепутали" намеренно.
Да не, это хорошо. Представляю, сколько лавок вспомнило, что умный админ таки нужен, а не "Петрович из отдела продаж настроил, он умеет".
может железке по середке не установили новый ключ? :)
Здесь все намного проще. Перед выборами шaтaют не только интернет, но и сотовую сеть. У меня и еще нескольких соседей последнюю неделю МТС жестко сбоил (отключалась симка, пропадала связь, либо не работал мобильный инет). Читал, что на днях к опcоcам пришли в гости cилoвики и опять что-то там "модернизировали". Видимо, готовятся к неким событиям ближайшего будущего... Так что впереди нас ждет еще много интересного...
4ебурнет на завершающей стадии
ЯПОЭЗ:https://sockpuppet.org/blog/2015/01/15/against-dnssec/
+1
DNSSec для конечных потребителей устарел с тех пор как гугл всех на https натянул.У меня собственный unbound дома с отвключённым валидатором DNSSec и вчера никаких проблем с инетом не было.
Некоторые провайдеры тоже додумались что так можно починить, остальные просто жевали сопли и не понимали что происходит и что делать.
DNSSec - это защита от недобросовестности Гугла, не?
Нет.
Это когда то ходили байки что можно отравить кеш резолвера посылая ему постоянно фейковые ответы, и однажды когда он пошлёт реальный запрос фейковый ответ может придти раньше и пользователи его использующие пойдут на сервер хакера ничего не замечая.
Тогда https был только у банков и чудиков с деньгами.В те времена с таким не заморачивались :)
Но для обеспокоенных былы варианты:
- перевести резолвер на TCP и наслаждатся медленной работы (TCP Fast Open = TFO тогда не было)
- "use-caps-for-id" - в общем резолвер слал mAIl.Com рандомизируя капитализацию букв и сверял ответ чтобы там было так же, это добавляло расширяло уникальный ID+src port запроса ещё каким то количеством рандомных бит неизвестных атакующему. Но проблема в том, что многие присылали ответ сделав все буквы большими или маленькими и резолвинг отдельных доменов или даже зон ломался.
Как сейчас не знаю, давно не включал :)
> +1
> DNSSec для конечных потребителей устарел с тех пор как гугл всех на
> https натянул.да он и раньше-то нахрен был не нужен. Очередная диверсия от профессоров далеких от реальности и не пользующихся компьюктором, на денежки которые все равно нельзя было потратить на гостинницу в Майами (а вот тут стало можно - мы соберем в ней конференцию по DNSSEC!)
> У меня собственный unbound дома с отвключённым валидатором DNSSec и вчера никаких
> проблем с инетом не было.а там точно нет каких glue records которые просто перестали отдаваться?
Я не дебажил.
Перезапустил пару раз unbound ради интереса, надеялся что отвалится но нет, как работало так и продолжило.Насколько я понял проблема была в том, что для зоны ru ответы всех DNS серверов второго+ уровня стали дропатся как не валидные из за DNSSec.
А раз он у некоторых был отключён то для них ничего не поменялось.
> Я не дебажил.
> Перезапустил пару раз unbound ради интереса, надеялся что отвалится но нет, как
> работало так и продолжило.а там на диске нет кэша gtld ?
> Насколько я понял проблема была в том, что для зоны ru ответы
> всех DNS серверов второго+ уровня стали дропатся как не валидные из
> за DNSSec.там вопрос в том чтоб . тебе glue records отдал - а то он же полезет (или нет?!) проверять в зону ru, ой, ключ неправильный, нибуду нихачю натебе servfail
На диске вроде никаких кешей нет, только рутовые сервера и может их ключи.
DNSSec у меня выключен:
module-config: "iterator"
(если бы включён был то это "validator iterator"), поэтому никаких ошибок в принципе нет и не будет.
Ну да выходит валидатор выключил и не увидел возможной подмены днс, в то время как остальных dnssec защитил от возможной подмены. Безопасность уровня: я отключил антивирус, а то он пищит и мешает файлы открывать.
Покажите мне успешные атаки на отравление кеша, тогда будет иметь смысл продолжать.Атаки от человека посредине - DNSSec им не помеха совсем, ибо можно сразу начать вырезать весь DNSSec либо вместо возни с ним перенаправить на уровне IP трафик на нужный сервер.
Твоя безопасность - это твое дело. Никто не должен тебе ничего доказывать.
Ну не скажите.Допустим у Вас очень большое количество пользователей ведут переписку по email. Руководство озаботилось шифрованием переписки и выбрало для этого s/mime. Ну получили Вы сертификаты s/mime на каждый email адрес. И как теперь распространить это по всей огромной толпе пользователей ? А сертификаты ещё и менять периодически надо !
Всем пользователям устанавливается Thunderbird и плагин к нему Great DANE for Thunderbird, а все сертификаты s/mime помещаются в DNS записи SMIMEA. И всё будет проверяться, шифроваться автоматом у всех и менять сертификаты легко - достаточно запись SMIMEA изменить. Разумеется чтобы это надёжно работало эти записи SMIMEA в DNS должны быть подписаны DNSSEC.
> очень большое количество пользователей ведут переписку по emailБывает.
> Всем пользователям устанавливается Thunderbird и плагин
Не бывает. У всех пользователей уже стоит Outlook, в котором шифрование емейлов из коробки.
> Причины инцидента в зоне RU пока не детализированыСвидетельство канарейки?
> временно отключив в настройках своих резолверов верификацию через DNSEC
Да уж можно и не включать. Наверняка ещё пару экспериментов надо провести, пока научатся
> Да уж можно и не включать. Наверняка ещё пару экспериментов надо провести, пока научатсяИ по http ходить на всякий случай. Вдруг он тоже сломается.
> И по http ходить на всякий случайЧерез http Ростелеком незаконно наталкивает в чужие сайты свою рекламу, а пользователи сайтов не разбираются в том, что эту помойку в сайты наталкивает Ростелеком и обвиняют в этом хозяев сайтов. Приходится использовать https.
Да и когда по требованию РКН сайт блокируют, то на месте http-сайта появляется фишинговая страница с информацией о блокировке сайта (если блокируют порчей отдаваемого с веб-сервера потока, а не заменой ip-адреса сервера в его зоне), а через https такая страница появляться наверно ж не должна (не проверял, ибо после перевода сайтов на httpы их по требованиям РКН не блокировали у нас уж).
По http вроде бы как можно было заблокировать конкретную страницу, на которой и содержится нарушение, т.е сам ресурс мог оставаться вполне доступным
Тогда как с https - вообще всё нафиг рубится
> По http вроде бы как можно было заблокировать конкретную страницу, на которой
> и содержится нарушение, т.е сам ресурс мог оставаться вполне доступнымДа. Можно заблокировать только одну страницу. И РКН в своём требовании к провайдеру требовал заблокировать только одну страницу. А провайдер вместо одной требуемой страницы заблокировал всё от корня веб-сервера: его ж за это никто не накажет - вот и творят что хотят.
> Тогда как с https - вообще всё нафиг рубится
А с https всё отрубится как, если с веб-сервера к клиенту будет идти https-поток, в который никто не сможет вставить спам о том, что "страница заблокирована по решению тра ля ля"?
Это вот если они для блокировки в зоне подменят ip-адреса веб-сервера, то на своём подставном веб-сервере, конечно, напишут про то, что "заблокирована тра ля ля".
>> Тогда как с https - вообще всё нафиг рубится
> А с https всё отрубится как, если с веб-сервера к клиенту будет
> идти https-поток, в который никто не сможет вставить спам о том,
> что "страница заблокирована по решению тра ля ля"?
> Это вот если они для блокировки в зоне подменят ip-адреса веб-сервера, то
> на своём подставном веб-сервере, конечно, напишут про то, что "заблокирована тра
> ля ля".Они порой ничего не пишут - страница тупо не открывается, падая по превышению времени ожидания
>Через http Ростелеком незаконно наталкивает в чужие сайты свою рекламуЛол, таким еще кто-то занимается?
Помню пяток лет назад этим сначала стали промышлять билайны-мтс, пихая ссыль на личный кабинет, потом местячковые провайдеры уже с рекламой. Но и те и другие быстро огребли, да еще насладились радостными отзывами в тех поддержку, из-за чего через пару месяцев прекратили безобразничать.
>>Через http Ростелеком незаконно наталкивает в чужие сайты свою рекламу
> Лол, таким еще кто-то занимается?
> Помню пяток лет назад этим сначала стали промышлять билайны-мтс, пихая ссыль на
> личный кабинет, потом местячковые провайдеры уже с рекламой. Но и те
> и другие быстро огребли, да еще насладились радостными отзывами в тех
> поддержку, из-за чего через пару месяцев прекратили безобразничать.Ага. Занимаются да притом ещё как!
После того, как мы наши сайты на https переключили, то я эти помойки видеть у нас перестал.
Но в интернетах ещё водятся сайты на http, которые по дороге к пользователям наталкиваются рекламой Ростелекома, если путь от сайта к пользователю пролегает через Ростелеком.Я к интернетам подключен через Ростелеком, поэтому на http-сайтах Ростелекомовскую помойку вижу нередко. Опеннетовские страницы, бывает, из rss открываю, и на страницах Опеннета в таких случаях тоже замечаю Ростелекомовские помойки, да такие, что думаешь - как бы их так обойти, чтобы не вляпаться в них да не обгадиться.
Максим тут на Опеннете когда-то во времена подключения Опеннета к https писал чё-то такое, что http отключать не будет, т.к. кому-нибудь он по каким-нибудь причинам может пригодиться.
> Опеннетовские страницы, бывает, из rss открываю, и на страницах Опеннета в таких случаях тоже замечаюМожете точнее написать в каких RSS остаются ссылки на http? Я вроде очень давно везде переделал только на https, но может где-то пропустил. HTTP на opennet должен оставаться только при прямом входе на внутренние страницы, в остальных случаях должно перебрасывать на HTTPS.
Разбор подстановки рекламы от ростелекома: https://opennet.ru/52444
> Можете точнее написать в каких RSS остаются ссылки на http? Я вроде
> очень давно везде переделал только на https, но может где-то пропустил.http://www.opennet.dev/openforum/forum_vsluhforumID4.rss
https://www.opennet.dev/openforum/forum_vsluhforumID4.rssПри открытии потока через https все ссылки в нём - через https.
При открытии его же через http все ссылки в нём - через http.Я думал, что это специально так и задумано для того, чтобы каждый сам решал: что ему нужно http или https. Но в остальных rss-потоках все ссылки только https независимо от того, http или https адрес у rss-потока.
У меня-то долго в rss2email были старинные http-адреса rss Опеннета. Но недавно надоело смотреть на ростелекомовские помойки на сайте и я заменил в rss2email http на https. А сейчас Максим переключит всё на безусловный https и получается, что я адреса в rss2email переправлял зря. :-)
> HTTP на opennet должен оставаться только при прямом входе на внутренние
> страницы, в остальных случаях должно перебрасывать на HTTPS.А я думал, что в начале эпохи перевода Опеннета на https была задумка сделать так, чтобы пользователи сами решали: как им на Опеннет ходить - через http или через https.
> http://www.opennet.dev/openforum/forum_vsluhforumID4.rssПоправил, теперь там только https.
У меня так opennet в закладках оставался как http. После переустановки ос сначала удивлялся, что за дичь лезет, потом посмотрел, что это от ростелекома подарки
На http сайт сейчас еще постараться надо, чтобы зайти. Все хромо-клоны верещат как резаные при открытии http.
Как постоянный пользователь Мегафона подтверждаю, тоже регулярно вставляет рекламу в http.
У меня мой сайт только по http, https есть но там самоподписной сертификат.
Нет смысла ложится под американцев в плане доступности.
> У меня мой сайт только по http, https есть но там самоподписной
> сертификат.
> Нет смысла ложится под американцев в плане доступности.У тебя уже ж есть не легший под американцев аналоговнеимеющей браузер который не покажет при этом пустое место или вообще СТРАШНУЮ СТРАНИЦУ ПОЛНУЮ НЕВЕДОМОЙ ХРЕНИ вместо сайта?
Или твой сайт такое ненужно что еще и к паблик интернету вообще не подключен?
Подключён, и иногда на него даже кто то попадает :)
Но в целом там странное и мало кому нужное :)
> Подключён, и иногда на него даже кто то попадает :)
> Но в целом там странное и мало кому нужное :)ну так с тем же успехом мог бы и вообще его выключить, надежно, безопастно, днс ниннуна.
Большинство-то держит свой сервер чтобы либо поделиться с кем-то информацией, либо коготу...э...поделить.
Мне, любимому, для себя и ftp хватит (и я его адрес кстати помню без всякого dns)
Я тоже чтобы поделится.
В своё время послал хубр и перетащил всё к себе.
Но это весьма специфичная инфа, думаю максимум 10к людям в год такое надо.Я слишком много переезжал и долго сидел на динамическом IP чтобы помнить IP :)
И уже давно по IPv6 тоже доступен.
> У меня мой сайт только по http, https есть но там самоподписной
> сертификат.
> Нет смысла ложится под американцев в плане доступности.Ну когда пользователям на http-сайте пишешь про то, что, дескать, тоарищи, помойку на сайт наталкиваем не мы, а Ростелеком, а пользователи всё-равно плюются и просят эти помойки удалить, то большинству из них объяснения о том, что помойка не наша, а ростелекомовская, являются пустым звуком.
В такой ситуации проще быстро подключить https через letsencrypt, чем изучать ваяние самоподписных сертификатов, и пользователи быстро успокоятся. Их же не убедишь в том, что помойка не наша, а незаконная ростелекомовская.
Да и не нравится мне, что Ростелеком за счёт чужих ресурсов (матеральных и трудовых) зарабатывает деньги себе и даже не только не уведомляет об этом владельцев чужих ресурсов, но и упирается, делая вид, будто он потоки чужих ресурсов своими спамо-помойками не обгаживает.
У меня нет такой проблемы, а проблемы абонентом ростелекома меня не волнуют, впрочем и я им тоже не нужен :)Но вы похоже не очень во всём разбираетесь, ибо помойку ростелека можно было заблочить на уровне браузеров, просто добавив нужные заголовки в ответ.
> Но вы похоже не очень во всём разбираетесь, ибо помойку ростелека можно
> было заблочить на уровне браузеров, просто добавив нужные заголовки в ответ.Какие заголовки надо с веб-сервера отправить вместе со страницей в браузер пользователя, чтобы его браузер помойку Ростелекома внутри этой страницы как-то нашёл и убрал? Это вообще странная задача - браузер-то должен(*) ничего не менять в странице, которая ему пришла со стороны веб-сервера, даже если она по дороге была изгажена ростелекомами там всякими, (*)если только пользователь сам не прикажет своему браузеру менять полученные страницы каким-то способом (рекламо-вырезалками, например). Но это ж браузер так может менять полученные страницы только с разрешения пользователя. А мне-то надо, чтобы к пользователю страница с веб-сервера приехала точно в том виде, в котором веб-сервер её отдал.
Читайте про: "Content-Security-Policy" заголовок.
> Читайте про: "Content-Security-Policy" заголовок.Почитал.
Заголовок-то интересный.
Но узел, через который от веб-сервера к веб-браузеру идёт http-поток (в нашем случае это Ростелеком) имеет возможность удалить этот заголовок из потока и в таком случае установка этого заголовка веб-сервером окажется бесполезной для веб-браузера. А если условный Ростелеком окажется честным и помойки в поток вставлять перестанет, то особой нужны в заголовке Content-Security-Policy наверно и не будет уж.
кстати, когда я увидел таки единственный раз (правда не ростелек а мегафон) на любимом опеннете - я даже не сразу понял, что это неправильная реклама.Потому что она очень аккуратно была всунута вместо рекламы опеннета - на то же место или рядышком (но спалились потому что та заблочена ублоком... ну ок, добавил еще и эту тоже)
Т.е. пострадавших на самом деле вообще было ровно ноль.
Надуюсь подробный публичный отчет будет по инциденту. Не очень красиво получилось.
Надуюсь, если не будет, а так надеюсь. =)
Он будет, но вам его не покажут. Если вы не с той стороны социума, конечно
На днях( кажись, в минувшую пятницу. Ночь-раннее утро ) примерно так же отвалились забугорные ресурсы
Вообще нифига не отрывалось но дзен работал
Примечательно, что вообще никто не заметилНынче - ru-сайты
Уж было думал что провайдер халтурит
Но ему повезло. На этот раз> Он будет, но вам его не покажут. Если вы не с той стороны социума, конечно
Дело не в сторонах социума, а в наличии смысла
Какой толк от того что аноним узнает точные детали ?
Ну пожмёт плечами, скажет "ну ок" и что, он что ли в след. раз будет прибегать исправлять падение сети ?
не падения сети нужно двигать, а...
> Он будет, но вам его не покажут. Если вы не с той
> стороны социума, конечнода, у товарищмайора-то на столе лежит, учения по мягкому принуждению на переключение на национальный чебурнет выполнены успешно, результат достигнут, количество запросов выросло на столько-то... но нам он его, увы, не покажет.
>Надуюсь подробный публичный отчетЭто должен быть не отчет, а процесс! Ибо - повреждение критической инфраструктуры.
>Пользователей DNS-резолверов, на которых DNSSEC отключён, не пострадали
Ждем пополнения списка https://ianix.com/pub/dnssec-outages.html
Фигасебе списочек там. В какую интересно номинацию попадет.Мне очень зашла "Long DNSSEC outages".
Вчера половина рунета отвалилась, да. Затронуло в основном пользователей DoH, остальным можно подсовывать любой левый трафик под видом настоящего.
Максимум увидишь SEC_ERROR_UNKNOWN_ISSUER.
Страшно-страшно, браузер отказался открывать.
Отключил временно DNSSEC на домашнем сервере, всё заработало.
Потому что DoH/DoT и публичные 8.8.8.8 и пр аналоги держат те же дятлы которые не отключают DNSsec, в итоге результат их использования в лучшую сторону не отличался.
Притом локальные провайдеры некоторые додумались DNSSec отключить или он у них был выключен и у их пользователей всё работало.
Ну вот год назад вроде мега отвалилась, сейчас какие-то бесполезные сайты в рунете. Стоит ли отключать из-за очередного человеческого фактора dnssec? Это чтобы добавить ещё человеческого фактора в ситуацию, видимо, да?
А зачем его включать когда большая часть трафика под TLS?
> А зачем его включать когда большая часть трафика под TLS?Чтобы не подменяли сайты на подконтрольные. Толку от tls, когда сертификаты часто совершенно левые? Как много пользователей вручную следит за внезапными сменами сертификатов на любимых сайтах? Я вот припоминаю несколько случаев, когда сертификаты с сайтами таким образом подменяли в РФ.
Вы поддразумеваете что надо проделать огромную работу по отравлению кеша и выпуску левого сертификата - и для чего? Как это ментизировать?И чтобы кеш отравить надо сильно флудить, как минимум 2млрд пакетов каждую секунду с фейковыми ответами, ибо 16 бит ID + 15 бит src port (даже чуть больше 15 может быть).
В реале может чуть меньше можно сделать если подгадать src port, но даже так будет несколько десятков раз по 32к каждую секунду.
Эта атака всегда была теоритической, делали её в лабах где или src port было мало или была возможность его угадать.Это не говоря о том, что допилить резолвер для автоматического отражаения такой атаки - дело получаса: если приходит много ответов без запросов то помечаем домен в ответах как атакуемый, шлём алерт админу а сами этот домен резолвим через TCP.
Всё, досвидос.
Ты ещё скажи митм никому не интересен, а последние 10 лет нам всем приснились. Все технологии давно отработаны.
Так покажите где на MiTM кто то поднялся, я видел всё от госов, а у них для этого все крутилки есть by design.
Они вам и DNSSec ответ подпишут нужный им без проблем.
> Вы поддразумеваете что надо проделать огромную работу по отравлению кеша и выпуску
> левого сертификата - и для чего? Как это ментизировать?пойсон атаки подразумевают некого внешнего злыдня, а если злыдень - это провайдер, которому злобный чекист(tm) приставил маузер к виску?
ему не надо ничего спамить, достаточно перехвать ответы
вот например ответ гугеля на opennet.ru
14:24:10.284333 IP 8.8.8.8.53 > 127.0.0.1.43736: 59855 1/0/0 A 217.65.3.21 (44)
0x0000: 5254 0015 495f 0200 0000 0001 0800 4500 RT..I_........E.
0x0010: 0048 3d6b 0000 6e11 e5c1 0808 0808 566e .H=k..n.......Vn
0x0020: c2fa 0035 aad8 0034 57c7 e9cf 8180 0001 ...5...4W.......
0x0030: 0001 0000 0000 076f 7065 6e6e 6574 0272 .......opennet.r
0x0040: 7500 0001 0001 c00c 0001 0001 0000 0851 u..............Q
0x0050: 0004 d941 0315я разборкой пакетов особо никогда не занимался, но тут же последние 4 байта и есть ответ
разобрать пакет ответа и подменить ойпи скорее всего не представляет особого труда.
Я зато занимался исплементацией DNS протокола и собственного рекурсера с кешем :)DNSSec не от провайдера, и тем более не от госов.
Госы без проблем подпишут DNSSec то что им нужно, а ваш DNS трафик они просто завернут себе не спрашивая и будут отвечать без DNSSec, типа не хотите так - не будет вам инета.
И какие защиты от спуффинга вы в вашем рекурсере применяли? Расскажите, раз вы такой DNSSEC-hater.
Как хорошо что есть личный локальный ресолвер.
Причём тут DoH. Зависит от оператора кто настроил валидацию dnssec, четыре восьмёрки, например включена валидация.
Четыре восьмёрки первыми начали подменять трафик в своё время, осадочек остался. Ну и, главная проблема, они регулярно отваливаются. То домены третьего уровня отвалятся, то просто лежат.
Да-да, и проблема сто процентов в Гугле, а не в твоём провайдере, который 8.8.8.8 прямо у себя на роутере завернул себе на 192.168.0.2, ага.Комменты на опеннет даже смешнее «Смехопанорамы».
О чём и речь. А что смешного тебе? Думаешь, в твоей стране такого не случится? Могу тебя расстроить, большинство стран начали оперативно перенимать опыт. Практически сразу.
В моей стране принято соблюдать законы, регулятор не имеет доступа к инфраструктуре, а ISP без судебного постановления пальцем не пошевелит. Да и с постановлением не факт — успешно оспаривали и будут дальше оспаривать любую тупую полицейскую херню. Для того лоеры на зарплате и нужны.
Даже если так, времени жить в мире розовых пони у тебя буквально до следующей локальной движухи. Наслаждайся пока, но готовься к сюрпризам.
Так то есть маленькие страны, где ты даже если инет отключишь то мобила просто через роуминг поймает из соседней страны, это не говоря о том, что все всех знают и до отключатора толпа дойдёт за 10 минут.
Понимаю, что для мордорцев это мир розовых пони. Только вот я в этом мире розовых пони в провайдере отработал несколько лет, где приходилось заниматься и исполнением судебных предписаний о законном перехвате, так что знаю эту кухню изнутри на личном опыте. Официально задокументированная позиция компании выполнять такие предписания только после личного разрешения начальника юротдела или ио, настолько всё серьёзно.
Времена меняются, да. То, что законодательства (да и сфера айти в целом) отдельных стран на десятки лет отстают от среднего общемирового уровня, едва ли достоинство. Ещё более вероятно, что руководство отдельной организации пока успешно избегало набутыливания и могло позволить себе действовать недальновидно. Результат всегда один.
> Ещё более вероятно, что руководство отдельной организации пока успешно избегало набутыливания и могло позволить себе действовать недальновидно.Компания существует с 1964 года, оказывает телекоммуникационные услуги с 1995, крупнейший провайдер в стране. Но анона с опеннета не проведёшь, он недальновидных не вставая с дивана вычисляет!
Времена-то меняются, но диванные кексперты опеннета не изменятся никогда.
Ты всё правильно понял, крупнейший провайдер это карманный провайдер, других вариантов быть не может. А может быть, ты всерьёз принял ширму, и не был в теме.
Кто вообще управляет DNS'ами?
РОСНИИРОС/КИАЭ
Это прям ну ооочень устаревшая информация.
> Кто вообще управляет DNS'ами?whois ru
ЦМУ ССОП же, что за вопросы
Еще один повод перейти на зону .Onion.
Там домены слишком сложные, еще вопрос что будет проще запомнить домен .onion или ipv6 адрес сайта.
Ты же на сайты, которые посещаешь, не вручную домены набираешь, а по закладкам, автодополнению, строке поиска заходишь?
50 на 50, если домен знаю наизусть то могу себе позволить нажать ctrl+T и начать его писать (скажем первые 4-6 символов), далее Enter.. но это не типичное поведение для большинства пользователей, да.типично: закладки, для "любимых" сайтов и ввод названия, части домена в поиск для не столь любимых
а я чёт закладками никогда не пользовался, в ff по ним абсолютно неюзабельный поиск
* в начале строки и ищет по букмаркам. Еще есть неплохая фишка с keywords, можно сделать шорткаты для самых нужных.
прикольно, спс. я в панельке по ctrl+b пытался искать
> Ты же на сайты, которые посещаешь,
> не вручную домены набираешь,
> а по закладкам, автодополнению,
> строке поиска заходишь?Вручную. По закладкам ходить долго и неудобно. Их, конечно, для удобства могут выводить из меню на всякие более видные и более доступные места. Но это всё-равно не хорошо - мало ли что может оказаться в закладке. Да и для всех сайтов не хватит на экране места для закладок. А если закладки вызывать изнутри меню, то это уже дольше, чем их адреса набрать руками. :-)
Смысл закладок в том, что в поиске в адресной строке они вылезают даже при очищенной истории.
Тут 90% выключают все эти автодополнения в первую очередь — через них гугл и анб им в штаны лазит, как какой-то клоун ниже написал.
> Тут 90% выключают все эти автодополненияЯ того же мнения.
Использую автодополнение только для адресов, которые я раньше руками набирал.
Закладки мне не нравятся ещё и тем, что работать я могу на разных компьютерах и что мне - закладки на каждом компьютере делать или таскать за собой экспортом-импортом да ещё и синхрониировать их между компьютерами? Системы всяких там "облачных" закладок мне не нравятся потому, что свои данные мне нравится хранить только в своих хранилищах, а не в облаках у незнакомых мне дядей.
Закладки ещё нужно чтобы вместо легального сайта не переходить на какой-нибудь "0n1ine.sЬerЬank".
> Там домены слишком сложные, еще вопрос что будет проще запомнить домен .onion
> или ipv6 адрес сайта.главное даже не запомнить а найти в принципе - и быть хоть как-то уверенным что сайт не фейковый.
Там был какой-то преобразователь aw34awfsdfa3rsdfasdf23r3q4rwedzfdsr3rqwefd.onion в opennet.tor
gemini ещё есть. Ещё в i2p неплохая идея, но нет клиентов (один на джаве, второй российский государственный на плюсах)
Gemini не работают без доменных имён, а следовательно и какого-нибудь DNS, что очень печально.
gns от gnu
На .btn, .mob и .ygg!
А зачем вообще менять ключ на аналогичный но параметрам, а не, например, постквантовый? Старый что скомпрометирован?
Время жизни ключа ограничена, поэтому регулярно выполняют ротацию ключей.
Он спросил зачем, а не почему. Ключи меняются на случай утечки, так менее реальная причина (тем не менее законная) на случай взлома за обозримое время.
Раз в три месяца планово заменяются ключи, типа защита на случай если ключ скомпрометирован.
Для "." ключи вообще раз в 15 дней меняют.
> Раз в три месяца планово заменяются ключи, типа защита на случай если
> ключ скомпрометирован.
> Для "." ключи вообще раз в 15 дней меняют.мысль о том что система автозамены ключей и есть наиболее вероятная точка компроментации - зуммеркам в голову не приходила, там все смузей занято.
>мысль о том что система автозамены ключей и есть наиболее вероятная точка
>компроментации - зуммеркам в голову не приходила, там все смузей занято.Случаи подмены ключей палятся очень быстро через сверку ключей полученных их разных концов мира. Если конечно не подделывать ключ для кого-то одного человека не страдающего паранойей. Но кому они нужны? А потом уже будет быстро произведён разбор полётов, каким образом был подменён ключ. Главное, что все подобные системы защищают это от массовой, долговременной подмены интернета какой-то дичью.
>>мысль о том что система автозамены ключей и есть наиболее вероятная точка
>>компроментации - зуммеркам в голову не приходила, там все смузей занято.
> Случаи подмены ключей палятся очень быстро через сверку ключей полученных их разныхтак они будут - одинаковые. Никакой другой подмены в принципе быть не может.
Уровень понимания технологии что экспертами опеннета что теми кто принес нам это ненужное счастье - он вот примерно такой, ага.
> так они будут - одинаковые. Никакой другой подмены в принципе быть не
> может.Не будут. Допустим утёк ключ зоны "." и новый владелец рассылает информацию, что сервера зоны "ru." находятся не там где обычно. И DNSSEC ключ зоны ru. другой(иначе цепочку доверия не продлить). Все ключи ниже "." будут изменены.
> Уровень понимания технологии что экспертами опеннета что теми кто принес нам это
> ненужное счастье - он вот примерно такой, ага.В бан проситесь?
> Не будут. Допустим утёк ключ зоны "." ии?
Ключ у тебя - уже утек. Все ключи правильно подписаны и переподписаны.> и новый владелец рассылает информацию, что сервера зоны "ru." находятся не там где обычно. И
> DNSSECничем ему не помешает.
> В бан проситесь?
мне очень очень страшно что очередной безграмотный васян меня забанит.
>> Не будут. Допустим утёк ключ зоны "." и
> и?
> Ключ у тебя - уже утек. Все ключи правильно подписаны и переподписаны.Только вот помимо липового ключа нужно иметь доступ к каждому корневому серверу в мире, чтобы ответы одного не противоречили другим, отвечающим клиентам в совершенно других странах. Конечно элементарная проверка покажет, что ответ нормально подписанный. Однако работать это будет до первого параноика отправившего дополнительный запрос через proxy-сервер находящийся в далёкой и враждебной стране.
Если ключи одинаковые, то где подмена? "Я вам ключ подменил... на тот же самый. Хахаха, а вы и не заметили"
Хотя, видимо, логикой тут и не пахнет.
DNSSec ни от чего, тем более массового не защищает, не нужно сочинять.
> DNSSec ни от чего, тем более массового не защищает, не нужно сочинять.DNSSEC защищает от подделки DNS-записей. Конечно от полноценного MITM он не спасёт, но от отравления кэша DNS очень даже. Как и от перенаправления запросов при взломе DNS-сервера.
Вы для начала в реальной жизни попробуйте отравить кеш резолвера, потом будете рассказывать как у вас получилось.
От перенаправления при взломе днс сервера оно не защитит и цели такой не было.
>Для "." ключи вообще раз в 15 дней меняют.
Небось ключи в зип архиве случайные люди шлют по электронке, а потом какой-нибудь младший техник (студент 2 курса менеджмент) вручную их устанавливает. Через убогую веб-панельку, написанную формошлепами 15 лет назад, где ни черта не видно и не понятно.
А должен всё это делать аккуратно написанный и протестированный код. И зону составлять, и обновлять, и сверять реальное положение дел с ожидаемым. Процедура отката на предыдущую конфигурацию должна занимать миллисекунды.
я тебя расстрою, наверное, но процедуры отката в dns - нет. Вообще. И любая ошибка там - надоооолго.И вот с такими руками - да, приходят писатели "аккуратно написанного и протестированного" но не на то что на самом деле над тестировать, поскольку про технологию они не в курсе, понадергав копипасты из чатгопоты или стековерфлова не дочитав до ответа.
И не поспоришь, протестировано - вон, юнит тесты все прошли.
На подконтрольной инфраструктуре откат должен происходить мгновенно. Некорректная конфигурация в принципе должна быть невозможна. Защита от дурака должна покрывать ситуации по типу той, что произошла.
80% и более плохого кэша DNS можно отменить достаточно оперативно, разослав крупным операторам оповещение по электронке. Сеть DNS очень даже централизована. Дежурные инженеры кэш сбросят.
Я уже молчу о том, что TTL большим никто давно не делает.Да, если вы думаете, что ручками делать надежнее, то ваш уровень - это как раз младший техник. Даже если в резюме написано что-то более умное. Нет вообще никакой проблемы написать программу, результат работы которой можно проверить до того, как она выполнит действия с боевыми сервисами. Если вы не скриптуете свои рутинные операции, еще раз - младший техник.
> разослав крупным операторам оповещение по электронкеА оно дойдёт по электронке-то ? Она давно завязана на DNS. Или у вас uucp ?
>> разослав крупным операторам оповещение по электронке
> А оно дойдёт по электронке-то ? Она давно завязана на DNS. Или
> у вас uucp ?дойдет, у нормальных-то домены в .net, только вот - noc@ какого-нибудь tele2 (ни разу не в Москве и хрен ты ему сделаешь) только хихикнет и удалит нафиг твою писульку.
Я же говорю - это д-лы с образованием семь классов и еще три - кадетской школы. В принципе, не удивлюсь если такие в росниирос и его отвалившихся клонах и работают.
Думающие что по их писульке все побегут исполнять, а не удивленно спросят - "что это за хрен с горы тут командует? Обос...лись эти узкие в своем днс? Ну так это их проблемы."
У меня для тебя, васенька, еще более печальная новость - DNS не подконтрольная тебе и вообще кому либо в одну харю инфраструктура.Именно по этой причине тебя никогда не пустят им рулить в приличном месте. В национальной этой самой - можешь попробовать, там и не таких брали.
Нет, кэши в dns не управляются ttl. (То есть управляются но совсем не так просто как ты думаешь.)
В общем, твоя судьба - в нациаан@льный днс работать. Там все такие, тебе там будет хорошо.
> разослав крупным операторам оповещение по электронке
васян, мамой клянется - надо кэш сбросить. Я такое удалю даже не читая.
>DNS не подконтрольная тебе и вообще кому либо в одну харю инфраструктураДа-да, примерно как веб, который на 80% обслуживается HTTP и DNS посредством единственной компании. 60% веб трафика идет с мобильных клиентов - еще целых две компании. Остальные 40% - через крупных провайдеров доступа, которых по миру сотни, крупнейших десятки, а по странам - единицы. Ты пойми, маленький украинец, технологии - это не магия и вещи в себе, а то, что люди поддерживают, чтобы осуществлять потребности клиентов. Мотивация у людей не в мелком выпендреже, как у тебя.
Вот просто спроси себя - чем ты лучше гпт? Лучше знаешь технологии? Нет. Лучше умеешь писать конфиги? Нет. Даже если нынешние гпт хуже тебя, будущие будут лучше - без вариантов. Лучше умеешь взаимодействовать по рабочим вопросам? "удалю даже не читая" - и снова нет... Твоя судьба на горизонте 5 лет - строительные работы или клининг.
> Вот просто спроси себя - чем ты лучше гпт? Лучше знаешь технологии?
> Нет. Лучше умеешь писать конфиги? Нет. Даже если нынешние гпт хуже
> тебя, будущие будут лучше - без вариантов. Лучше умеешь взаимодействовать по
> рабочим вопросам? "удалю даже не читая" - и снова нет... Твоя
> судьба на горизонте 5 лет - строительные работы или клининг.Пока на коммерческом уровне все начальники позвонили своим яйцеголовым и сказали: срочно делай (свой аналог чата GPT и т. д.), и не обсуждай вопрос, надо это или нет. Потому что этого начальника суперкорпорации его более старший начальник, который ему позволяет эту корпорацию строить, зарабатывать, госденьги получать — он же его тоже спросит: а чего вы-то не сделали?
И этот хочет знать, что тому ответить. Если он может ответить, что работа ведётся, скоро будет — то всё нормально. А если — нет? Получается, он дурак. То есть это в общем, по-другому и не могло быть. Но на самом-то деле — мы должны это делать или нет? Это большой вопрос.
Ну тебе на твоей впс и правда не нужна никакая атоматизация, быстрее руками DNSSEC отключить, чем разбираться зачем он нужен и как им пользоваться.
> Небось ключи в зип архивеХорошо Вы о них думаете. В rar архиве.
Вопрос не совсем в тему. В связи с блоком wg/openvpn кто-нибудь проверял, по ipv6 тоже блочат или еще нет?
> Сбой в доменной зоне RU из-за ошибки при замене ключей DNSSECНо виновных как всегда нет и наказывать никого не будут? :)
Да, было бы неплохо возродить публичные порки на Красной Площади
А почему вы решили, что за это не накажут вас?
Может ли это быть связано с массовыми просьбами заблокировать Ютуб?
(Неужели чебурнет все ближе?)
Или просто так совпало и можно не беспокоиться?
А заблочили рутуб?
Даже для больных это перебор :)
> Может ли это быть связано с массовыми просьбами заблокировать Ютуб?
> (Неужели чебурнет все ближе?)
> Или просто так совпало и можно не беспокоиться?Логику по тиктоку не преподают, но можно прояснить - как связанны проблемы с зоной .ru и твой воображаемый чебурнет, о котором зумерки толдычат лет десять? Делаем зону ру недоступной, чтобы что? Чтобы пропиарить рутуб? Как это работает в воспаленном мозгу мамкиных революцинеров? Не могу распарсить.
> воображаемый чебурнет
> воображаемыйТакой воображаемый, что половина сайтов без VPN уже давно не открывается. ;)
Да и работающий VPN попробуй найди. Мобильный инет через день глушат. Но да, повторяй дальше свои мантры, незумерок.
>(Неужели чебурнет все ближе?)Тут, скорее, тестировалось отключение зоны .ру от макдакнета.
Вообще не заметил никаких сбоев. Узнал о них лишь из новостей.
Вам повезло, ваш DNS сервер выполняющий рекурсию был с отключённым DNSsec.
У меня все такие.
Аналогично.
Я вечером тоже сидел с выключеным инетом..
Вообще не заметил работает ли он
На самом деле сбои были, но куда менее сильные чем писал народ. Ну да, кое что упало, вырубившийся Я.Такси когда тебе "ннада" это и правда неприятно, но в целом ничего такого страшного.
Не знал, что в москве есть технический центр всего интернетаcontact: technical
name: Technical Center of Internet
organisation: Technical Center of Internet
address: 8 Marta street 1, bld 12
address: Moscow 127083
address: Russian Federation (the)
phone: +7 495 730 29 69
fax-no: +7 495 730 29 68
e-mail: ru-tech@tcinet.ru
Если бы всего интернета он бы назывался Technical Center of the Internet само собой.
А я вчера ловил лулзы с беспомощных ИТ специалистов как на хубре так и у провайдеров.На хубре калеки всё что смогли придумать - прописать ещё раз 8.8.8.8, который тоже использует DNSSec и точно так же не работал.
Через час до некоторых стало доходить но прочитать man unbound они не смогли, потому вместо module-config: "iterator" удаляли опцию с путём до публичных ключей корневых днс серверов.У провайдеров народ тоже не вдуплял что проблема в DNSSec и что это ваще такое. Но это видимо касалось тех кто на форуме отписался, у адекватных видимо DNSSec изначально был отключён и о проблемах рунета они узнали от других пострадавших сильно после.
В итоге пострадавшие разделились на группы:
- те кто выключил сам DNSSec и излечился
- те кто боялись что то трогать, типа мы нипонимать, не хотим больше сломать
- те у кого своего DNS сервера нет, они бомжи паразитирующие на других
- те кому нсдпи или как его там запихали по самые гланды и сами они шевелится боятся, ибо как бы чего не вышло, вдруг кто то запрещёнку увидит
Ну ты нашёл где помощи искать - на околотехническом хабре. Там только поливать говном всё отечественное могут, вроде.
Мне помощь не нужна, у меня на unbound домашнем DNSSec всегда выключен и проблема меня не задела.
Зачем вам вообще интернет? Идите в пещеру.
> на околотехническом хабреИ вполне логично, что они не сильно разобрались)
Ха, ты так пишешь, как-будто куча отечественного софта используется для dns.
Прям наша страна - центр разработки.
> Ха, ты так пишешь, как-будто куча отечественного софта используется для dns.
> Прям наша страна - центр разработки.При чём тут именно dns? Там разве не всё обсирают, что не сделано иммигрантами на западе?
А что, не за дело обсирают?Последнее, что было сделано так, что не стыдно показать -- это Heroes of Might and Magic V. В 2006 году.
А, ну Касперский, конечно. Ещё раньше сделан, в 90е.
> А что, не за дело обсирают?На хабре? В основном нет, конечно. Там от некоторых сообщений за километр несёт оттопыренным мизинцем.
Хабр это где две статьи из десяти про IT а остальные восемь про релокейшен в Грузию? Это ж донный сайт.
поцреоцкие поделки я и зесь поливать могу, как собственно и хабр, рекламирующий всякое барахло уровня каспер+
Достаточно было в логи залезть, чтобы понять, что косяк в DNSSEC. И да, я юзаю DNSSEC.
Даже не нужно в логи лезть. Пару dig, что бы понять, что это глобально сломалось и всё.
> На хубре калеки всёНе смешно. Там вообще хоть одна буква ценной информации бывает?
В официальной инструкции есть способ отключения dnssec как удаление пути до файла. Хотя отключить модуль было бы логичнее.
Мы у себя проблему в 19:17 увидели, а в 19:40 уже вырубили нахер dnssec.
Аха, вот такие, когда видят ошибку сертификата, тоже клацают "Игнорировать".
Я клацаю игнорить, потому что на 99% сайтах которые я посещаю TLS не нужен, я там даже не авторизуюсь, потому мне абсолютно всё равно хакнули их или нет.
И большая часть ошибок это про истёкший сертификат.
А потом, в тот момент, когда не нужно что-то делать, ты задним числом понимаешь, что зря это УЖЕ сделал на автомате. Что тебя остановит от клацания на автомате "Ignore"?
Не нужно проецировать свои проблемы на других.
Я смотрю на сертификат только для тех сайтов где я авторизован и где эта авторизация чего то стоит.
Вот тут она ничего не стоит. А на сайтах банков стоит.
У гугла и некоторых других сертификаты припинены, и всякие мерзские HPTS автопиниги, так что там даже кнопки игнорирования нет.
> Не нужно проецировать свои проблемы на других.Видал я таких умных, которые отправляли на автомате несколько миллионов в утиль, а потом оправдывались, что просто привыкли клацать. Нет у тебя такой защиты от дурака, ибо дураки все и я в том числе. Не надо вырабатывать у себя вредных привычек просто.
Ему DNSSEC не нужен, TLS не нужен. Зачем он вообще сюда зашел, не ясно.
Не знаю чем надо заниматься, чтобы часто видеть эти ошибки. Мне может раз в месяц показывается
> Аха, вот такие, когда видят ошибку сертификата, тоже клацают "Игнорировать".Какие такие, чудо? Какой большой смысл от dnssec у провайдера (имеется ввиду, не между клиентами и провайдером, а провайдером и апстримом)?
Увы, таких помойных провайдеров полно. А DoH как раз и существует в том числе из-за того, что всегда найдётся подобный человеческий фактор и отключит dnssec.
> Увы, таких помойных провайдеров полно. А DoH как раз и существует в
> том числе из-за того, что всегда найдётся подобный человеческий фактор и
> отключит dnssec.А doh тебе зачем, болезный?
Для исключения человеческого фактора у провайдера, говорю же. По факту лишняя работа, конечно, если бы нанимали только профессиональные кадры, этого бы не понадобилось. А так доверия из-за подобных инвалидов сегодня никакого.
> Для исключения человеческого фактора у провайдера, говорю же. По факту лишняя работа,
> конечно, если бы нанимали только профессиональные кадры, этого бы не понадобилось.
> А так доверия из-за подобных инвалидов сегодня никакого.Блин, как тяжело с такими... Ты на вопрос не ответил. Перечитай, не в падлу.
А что тебе перечитать, если ты не осознаёшь, что защищать от провайдера до клиента смысла вообще около нуля? Я прямо ответил, это мера защиты от недобросовестных/некомпетентных сотрудников у провайдера, но она является костылём и смещением контроля от незаслуживающего доверия провайдера (который вообще-то получает деньги за свои услуги) левому васяну (действующему "бесплатно").
> А что тебе перечитать, если ты не осознаёшь, что защищать от провайдера
> до клиента смысла вообще около нуля?Ты с больной на здоровую голову не перекладывай. Что ты собрался защищать и почему смысла 0? DoT и DoH тебе помогут от всех защитить. Я уже запутался в твоих показаниях.
> Я прямо ответил, это мера
> защиты от недобросовестных/некомпетентных сотрудников у провайдера, но она является костылём
> и смещением контроля от незаслуживающего доверия провайдера (который вообще-то получает
> деньги за свои услуги) левому васяну (действующему "бесплатно").Т.е. DoH это мера защиты от провайдерских сотрудников, так? ДОпустим. А в чём их недобросовестность?
Ты не понял, DoT/DoH так же держат DNSSec включённым и точно так же вчера всех слали в /dev/null.
А провайдеры делают по тех регламентам и в пределах закона.
> Ты не понял, DoT/DoH так же держат DNSSec включённым и точно так
> же вчера всех слали в /dev/null.
> А провайдеры делают по тех регламентам и в пределах закона.Квадовский 9.9.9.10 без dnssec
> Квадовский 9.9.9.10 без dnssecUnsecured: No Malware blocking, no DNSSEC validation (for experts only!)
> Квадовский 9.9.9.10 без dnssecNote: We do not recommend mixing the secure and unsecured IP addresses in the same configuration. Your devices will not be protected 100% of the time and it leads to confusion when debugging potential problems.
То есть ты просто доверяешь человеческому фактору другого провайдера?
Я доверяю тому, что dnssec не будет отключен. Особенно, когда в конфиге доверие только провайдерам с dnssec, но и в целом там нет таких ламеров.
Ну и сидите без доступа к сайтам при каждом чихе :)
Во-первых, не при каждом. Большинство операторов всё же умеет пользоваться DNSSEC. Во-вторых, даже если завтра весь рунет погаснет, мир вряд ли заметит. В .ru ничего ценного за почти тридцать лет его существования не появилось, только убогие местячковые копии крупных зарубежных сервисов, интересные только совкам, твоя домашняя страничка на narod.ru.
DoH не исключает необходимости проверять DNSSEC. Вообще никак.
> DoH не исключает необходимости проверять DNSSEC. Вообще никак.DoH действует в обход провайдера с некомпетентными сотрудниками. Естественно, не исключает. Но можно было бы обойтись и без него, не перекладывая заботу проверки на пользователя.
Вообще то исключает, за тебя это делает владелец DoT/DoH сервиса.
> Вообще то исключает, за тебя это делает владелец DoT/DoH сервиса.Не придумывай. Нигде об этом в протоколе не говорится. Раз уж DoT упомянул, то тот же stubby специально оговорку об этом делает, и может делать проверку DNSSEC сам, а можно и при помощи dnsmasq.
Нет.
DoH/DoT это желание гугла/анб залезть в штаны хомякам против их воли, под предлогом бизапаснасти.
Если раньше хомяк должен был сам прописать 8.8.8.8 чтобы слить всё своё гуглу и обойти примитивный блок на уровне днс провайдера, то теперь DoT/DoH впихнули прямо в браузер и включили по дефолту. С такой штукой никакая телеметрия не нужна, вы сами всё слили.
DoT/DoH защищает от насильственного перенаправления днс трафика на свой днс провайдером, это такая телеметрия которая против античеловечных режимов, только её зачем то по всему миру включают :)
DoH вполне может быть и подконтрольным. К примеру, тот же dnscrypt гарантирует, что айпи и сайт настоящие, а в трафик злоумышленники не могут вмешаться. Проверки в браузере могут быть перенаправлены на него, это штатная функциональность.
Чушь.
dnscrypt как и DoT/DoH гарантируют ровно тоже что и TLS: в ваш днс трафик никто не залез и не подсмотрел.То что сайт настоящий - ну это ваще смешно, тут мало что поможет, кроме пининга самоподписных сертификатов и это при условии что сервер не взломают и не угонят TLS ключ или не заставят его проксировать откуда то.
Всё же, это уже не те случаи, которые стоит рассматривать. Но на уровне днс вполне обеспечивает гарантии соответствия. Провайдеры-монополисты doh вполне могут быть и атакованы одновременно, вероятность того, что посыпется сразу куча нонейм dns-провайдеров как-то ниже (хотя можно попытаться вызвать отказ "лишних" и перенаправить трафик подконтрольному). Если только отключить dnssec, и вот бы в трафик как-то вмешаться, да. А можно не отключать и шифрованный трафик на то и шифрованный.
Я вам по секрету скажу - рекурсер с кешем можно дома даже держать :)
У меня оно даже на мобильных карманных роутерах есть.
> Какой большой смысл от dnssec у провайдера (имеется ввиду, не между клиентами и провайдером, а провайдером и апстримом)?С терминологией разберись сперва.
> Какие такие, чудо?
Вот такие, которые даже терминологии не освоили, но уже лезут отключать то, смысл чего ещё не поняли.
>> Какой большой смысл от dnssec у провайдера (имеется ввиду, не между клиентами и провайдером, а провайдером и апстримом)?
> С терминологией разберись сперва.А что тебя смущает?
> Вот такие, которые даже терминологии не освоили, но уже лезут отключать то,
> смысл чего ещё не поняли.Какие такие?
Клиентам DNSSec не нужен, да и провайдерский сервер его может разве что ретранслировать, нагружая ничего не стоящую полосу бесполезным трафиком.А вот говорить про апстримоский DNS - моветон.
Технически у провайдера должен стоят свой рекурсер с кешем, а не побирайка от апстримов или всяких 8.8.8.8.
И вот в этом месте некоторые считают что DNSSec нужен. Но я с этим не согласен, ибо как показывает практика проблем от его включения больше и они эпичнее :)
> Технически у провайдера должен стоят свой рекурсер с кешем, а не побирайка
> от апстримов или всяких 8.8.8.8.Так и делают. Давно уже не помню, что бы магистралы dns давали, но и когда давали их не брали. Нет смысла. Лишняя точка отказа.
> И вот в этом месте некоторые считают что DNSSec нужен.
Ну вот, я ж и спрашиваю у местных параноиков - зачем? Какую-то мантру бездумно повторяют заученную и ничего вменяемого не пишут...
На наге одмины провайдеров тоже не могут объяснить зачем им DNSSec нужен, в книжке прочитали и поверили :)
> На наге одмины провайдеров тоже не могут объяснить зачем им DNSSec нужен,
> в книжке прочитали и поверили :)Давно там не был :-). Но на наге так-то школьников разы меньше, чем здесь. Так что странно, конечно.
Перечислишь админов и провайдеров по именам или ты это «чисто по ощущениям» знаешь?
Сам у них спрашивайте: https://forum.nag.ru/index.php?/topic/129992-xyz-upal/page/37/
А кто же это сделал?
ессественно новенький админ, которого не курсанули, что при смене ключей необходимо заранее сообщить тов. майору :)
Если бы новенький админ, то не выпускали бы отчет со смыслом "это не мы такие, это DNSSEC такой. И вообще, переходите все на НСДИ.".
https://cctld.ru/media/news/kc/35566/
> https://cctld.ru/media/news/kc/35566/"""
Возникшая коллизия ключей, в причинах которой в настоящее время продолжают разбираться специалисты Технического центра интернет (ТЦИ) и MSK-IX, привела к временной недоступности зоны .RU для части интернет-пользователей.После обнаружения сбоя обновленные ключи были отозваны, и работоспособность зоны .RU в полном объеме восстановилась, что заняло, включая распространение данных по системе DNS, около двух часов.
""""Какая нахрен коллизия? коллизия с чем? с каким другим ключем? если ключи независимые. Там можно записи подписывать одновременно обоими ключами (ZSK).
Раздел 4.1.1.2. Double-Signature Zone Signing Key Rollover
https://www.rfc-editor.org/rfc/rfc6781
Да это все работало даже в том случае если добавили бы один и тот же ключ с другим key_id и подписали бы записи. Какой нафиг отзыв? Это термин из PKI. А что за бред про "в полном объеме восстановилась, что заняло, включая распространение данных по системе DNS,". Никто не кеширует богусную зону. Восстановилась именно сразу после того как "правильно все было переподписано". Хотя по моей версии все там правильно было переподписано, ибо этот процесс происходит каждый квартал. Нового админа не курсанули, чтобы ключи вовремя отослал тов. майору, вот и все.
Коллизия - это, например, когда хеши от разных данных совпали. Тут требуется квалифицированный конспиролог, способный объяснить, почему поля Галуа весьма далеки от Эйфелевой башни.
- Почему у тебя нос сломан?
- Потому-что он столкнулся (коллизия) с чужим кулакомСчастливое число Слэвина (ц)
Допускаем, сгенерировали 1024 битный ZSK ключ rsa, его хеш sha256 (ибо algo_id=8) как вы говорите столкнулся c хешем какого ключа? Со старым ключем ZSK? Ну и что?
Тут задача из разряда "кто даст правильный ответ - тот получит 10 лет".
> Тут задача из разряда "кто даст правильный ответ - тот получит 10 лет".ага, "кто купит билетов пачку" ... XD
Обратим внимание на данное утверждение:
"""
что главной причиной сбоя стало несовершенство программного обеспечения, используемого при создании ключей шифрования.
"""Вопрос, какого ПО? Сделаю предположение - самописного, своего рода "панель управления", в которой можно сгенерить ключ для зоны и подписать записи. Отсюда:
"""
Как и любое другое технологическое решение, DNSSEC требует усовершенствования с течением времени, чтобы исправить обнаруживаемые ошибки работы.
"""Вопрос, так DNSSEC требует усовершенствование или ваше "самопальное" ПО?
"""
Возникшая коллизия ключей
"""Предполагаем возникновение коллизии созданного ключа. Как вы заметили, коллизия с хешем может быть от ключа, но с каким другим ключом? При генерации нового ключа (ZSK) существует ОДИН текущий актуальный активный ключ. Вероятно их ПО при запросе на переподписывании выбирало ключ из (где они там хранят ключи - не знаю) "базы" по хешу ключа, и напоролась на актуальный активный текущий ключ, взяла его и переподписала зону. Если коллизия произошла именно с этим ключем, то в чем проблема? Разве подпись ресурсных записей должна была быть невалидной? Ключ ведь актуальный активный никто ведь не удалял. Может key_tag неверный был у ресурсных записей? - НЕТ. Судя по dnsviz второй ключ был добавлен еще числа 26-го.
256 3 8 AwEAAbjj3GP0TUwaNI7BIIw/fvwKTmdR +oZsEPk64pl8VYn4dfdbGHWpYIooxcgEbuBEYrnC/oqnKhad38nTxrZ9SAK3qV5qShntFdgozS5IKs5m1ebNmg2sotlhXRhJ4vqgH+BQh/lw6T4vdB8FE5tHGE1vwPs9Vhj0vLTBhX8TwB6/ ; key tag = 52263
256 3 8 AwEAAcBtr/w2hP6OQjiCacPFzK6xh0pR 7QsHV9lxprIXG9WBoBB5XWPVc5q17F3yt3wpJ7xmedt80gxVMaicPYNYAa8YUFyMxTGVBDVQlz5gCmXQKlr0yImI78sdwzWNmgKHap0BLypTBVxAKxpcvuwTmqXQUSONkjq9werHvogrvkUb ; key tag = 44301
key tag - по сути должен храниться вместе с ключевой парой, и ситуация с коллизией описанной выше, по идее должна была выставить в качестве key tag в RRSIG не новый key tag = 52263, а "старый" текущий актуальный key tag = 44301.
НО - судя по dnsviz
NS 8 1 345600 20240305102631 20240130141847 52263 ru. kw9oqgvi/l0MZp/6FY0Ha+VZDWRR3+iDUCYqAY5W7D2wCfIXXdOOvdd58nNY7z/3b4fRK6tlTF3wQpCDSpeKrmkWmric4kcUptaj1rp71lC0GHXHmGwDsx8Zi/lvo6sJEk0guBbJYBJkzKqeseD4u1Pw29jkRHhQEJKk2seP+Zk=
у битой сигнатуры был выставлен key tag = 52263 - нового ключа, так почему же она оказалась битой?
Представим примитивное хранение ключевых пар
key_tag, pub_key, priv_key, hash
44301, pub_cur, priv_cur, hash_cur
52263, pub_new, priv_new, hash_newНу вот тут если hash_cur==hash_new и сделать выборку по hash, то какая разница какой из ключей выбрался бы, результат был бы - валидная сигнатура, ибо ситуация возьми priv_cur (текущий приватный ключ) и выстави key tag от ключа priv_new - ИСКЛЮЧАЕТСЯ!!!.
Так в чем же причина битой сигнатуры? А теперь допустим куда реалистичную ситуацию. Опять представим примитивное хранение ключевых пар:
key_tag, pub_key, priv_key, hash44301, pub_cur, priv_cur, hash_cur
52263, pub_new, priv_new, hash_new
12345, pub_old, priv_old, hash_old
22222, pub_001, priv_001, hash_001
33333, pub_002, priv_002, hash_002
52263, pub_123, priv_123, hash_123Допускаем, что они не удаляли старые ключевые пары, и среди ключей коллизия должна была быть не только по hash, но и одновременно по key_tag, так как key_tag в битых сигнатурах был от якобы нового опубликованного ключа. Но коллизия по hash двух 1024 битовых rsa ключевых пар мне кажется мало вероятной, склоняюсь к тому, что коллизия могла произойти по key_tag.
Вывод: Читаем внимательно https://datatracker.ietf.org/doc/html/rfc4034#appendix-B
key_tag не обязан быть уникальным, отсюда вся беда с коллизией в том, что НАКОЙ ХРАНИТЬ СТАРЫЕ КЛЮЧИ?
для истории"""
Из письма ТЦИ следует, что сбой длился 30 января с 18:28 до 21:00 мск и затронул сайты в доменных зонах *.RU, .tatar и .дети. Сбой произошёл при замене старого ключа для проверки подлинности записей в файле зоны на новый. Подобные замены — плановые, для домена *.RU они производятся четыре раза в год, очередная началась 24 января. «В результате сбоя конфигурации в системе [30 января при активации нового ключа] оказались две пары ключей с одинаковым keytag (16-битный тег, который вычисляется по алгоритму от данных ключа», — отмечается в разъяснении ТЦИ. Коллизия с одинаковыми keytag в системе в нем объясняется «сбоем программного обеспечения».
"""
> А кто же это сделал?и прикол в том, что они на протяжении нескольких часов не вкуривали почему сигнатуры битые :) и тут вовсе не в кеше резолверов дело (зона богусной была и в кеш не сохранялась). Второй ключ был добавлен по рфц - заранее, а потом после определенного периода необходимо было просто переподписать записи новым ключем. Вот и переподписали, как и всегда переподписывали, но что-то пошло не так :)
я подозреваю в их офисе резко отвалился интернет, 4ge тоже пошло по п-де (кто не в курсе там без dns даже симку не зарегистрировать) и стало ну ооочень сложно что-либо траблшутить.А националпредатели типа тебя, у которых вся внутренняя, внешняя и домашняя инфра не на gtld ru и которые наоборот не сразу даже заметили что что-то не так - в таком месте не работают.
> А националпредатели типа тебялол, кек у меня opennet.ru не открывался, вот и заметил :) а байки про то, что не тем ключем подписали или ПО днссека какое-то не такое, будете внукам рассказывать.
Или их хакнули или они в очередной раз попробовали пропихнуть свои интернет по паспорту. И то и то не сработало. И то и то плохо. Может быть отключение защиты DNS на стороне провайдеров - это как раз то, чего они ждали? Может не стоит? Может пора переходить на CloudFlare?
Еще Воланд говорил Канту за завтраком про DNSSEC: «Вы, профессор, воля ваша, что-то нескладное придумали! Оно, может, и умно, но больно непонятно.»
В очередной раз убедились, что DNSSEC отлично работает. И в том, что людей понимающих как он работает и как им пользоваться крайне мало. Последнее так же хорошо видно по переписи отключающих DNSSEC. Неуловимо напоминает рассказы «бывалых» про ненужность ремней безопасности.
Зачем нужен ремень безопасности когда ты находишься в жидкой среде близкой по плотности к твоему телу и всё вместе это находится в поле поглощающем инерцию?!Фонаты включения DNSSec так и не могут объяснить зачем оно надо когда везде TLS.
И не могут показать ни одной успешной атаки в реальном мире по отравлению кеша.
Но DNSSec дОлжон быть включён, ведь в книжке же написано!А мутанты радеющие за суеверность или суверенность чебурнета не могут объяснить как чебурнет будет работать когда амеры/ican разделегирует .ru зону или "неудачно" что то там поменяют с DNSSec для этой зоны.
> Фонаты включения DNSSec так и не могут объяснить зачем оно надо когда везде TLS.«Фонаты» действительно много чего не могут. Попробуй спросить знающих людей.
> И не могут показать ни одной успешной атаки в реальном мире по отравлению кеша.
Вчера вкатился в айти по трёхмесячным курсам? Атаки по отравлению кэша перестали хорошо работать в какой-то момент, и причина тому отчасти DNSSEC.
> А мутанты радеющие за суеверность или суверенность чебурнета не могут объяснить как чебурнет будет работать когда амеры/ican разделегирует .ru зону или "неудачно" что то там поменяют с DNSSec для этой зоны.
Вижу, что как работает DNS и DNSSEC в частности ты просто не знаешь.
> Попробуй спросить знающих людей.Те не вас?)
> Атаки по отравлению кэша перестали хорошо работать в какой-то моментПокажите примеры успешных атак, потому что я читал только про лабораторные опыты в контролируемых условиях.
На практике слать 2^15 пакетов с фейковым ответом и надеятся попасть раньше ответа - такое себе.
> Те не вас?)Как скажешь.
> Покажите примеры
Я тебе покажу, а ты скажешь, что я «фонат» и придумаешь, почему это тоже лабораторный опыт. Не первый месяц тебя наблюдаю, знаю что ожидать. В очередной раз убедился, что доказывать кому-то что-то на опеннете — такое себе.
> На практике слать 2^15 пакетов с фейковым ответом и надеятся попасть раньше ответа - такое себе.кек, а че это много разве? одновременно досишь неймсервер, который должен прислать ответ, и шлешь 2^n пакетов на сервер рекурсивного резолвер, кеш которого хотим отравить. (ток не забываем врубить спуфинг)
А вот в случае с подписью днссек отравить кеш не получится. Даже если проспуфить и подсунуть ключ этого неймсервера. Надо проспуфить всю цепочку ключей от корня.
Нет, не много, но 2^16 надо слать на все порты, обычно это 1024-65535.
Те примерно ближе к 2^30 - 2^31.Я там выше уже описал простой механизм противодействия этому: когда на сервере видим кучу ответов для которых не было запросов то помечаем домен как атакуемый и резолвим его по TCP.
Худьшим вариантом станет возможность переключить на резолвинг через TCP и немного увеличить задержки при первом резолве. Юзеры не заметят.
> когда на сервере видим кучу ответов для которых не было запросов то помечаем домен как атакуемый и резолвим его по TCP.Это ты отлично придумал! Теперь можно не только замедлить разрешение имён в атакуемом домене, но ещё и повалить твой рекурсор банальным TCP досом.
> немного увеличить задержки при первом резолве. Юзеры не заметят.
Не только заметят, но ещё и начнут жаловаться. Для многих компаний увеличение задержек ответов от рекурсора на 1ms — нештатная ситуация, требующая немедленного вмешательства. Кексперт опеннета как есть.
> ля многих компаний увеличение задержек ответов от рекурсора на 1ms — нештатная ситуация, требующая немедленного вмешательства.Примеры таких компаний?
Когда "амеры" это сделают, по ТВ просто скажут что надо везде прописать суверенные DNS серверы и все.Примерно так получилось с выключением Мастеркарда\Визы - локальный эффект никакой.
С удалением приложений банков из Гугль Плей в общем эффект вышел почти обратный - сначала sideloading помог, а потом по факту добились запуска локальных альт-магазинов приложений.
> Фонаты включения DNSSec так и не могут объяснить зачем оно надо когда
> везде TLS.TLS у вас от вашего браузера до "8.8.8.8". А DNSSEC от "8.8.8.8" до остальных неймсерверов.
> Но DNSSec дОлжон быть включён, ведь в книжке же написано!
Да, включен должен быть на рекурсивном резолвере.
> А мутанты радеющие за суеверность или суверенность чебурнета не могут объяснить как
> чебурнет будет работать когда амеры/ican разделегирует .ru зону или "неудачно" что
> то там поменяют с DNSSec для этой зоны.Делов то, попросят всех добавить "корневые-скрепные" сервера в файлик named.root :)
А ведь ~47 минут назад подпись всё-таки успешно поменяли...
https://dnsviz.net/d/ru/ZbpWZg/dnssec/
На уровне слуховых слухов вся ситуация с заменой ключей DNSSEC отлично ложится на активизацию продвижения суверенного Нацсертификата. Сейчас даже Тинькофф на своих страницах оплаты\подтверждения карточных операций стал настойчиво просить поставить сертификат.
> На уровне слуховых слухов вся ситуация с заменой ключей DNSSEC отлично ложится
> на активизацию продвижения суверенного Нацсертификата. Сейчас даже Тинькофф на своих страницах
> оплаты\подтверждения карточных операций стал настойчиво просить поставить сертификат.есть такая гипотеза, а как иначе всех со всяких "восьмерок" и "единичек" перевести на "замещенное". Но есть одно НО, "замещенные" с включенными валидаторами днссек так же не работали :)
>> На уровне слуховых слухов вся ситуация с заменой ключей DNSSEC отлично ложится
>> на активизацию продвижения суверенного Нацсертификата. Сейчас даже Тинькофф на своих страницах
>> оплаты\подтверждения карточных операций стал настойчиво просить поставить сертификат.
> есть такая гипотеза, а как иначе всех со всяких "восьмерок" и "единичек"
> перевести на "замещенное". Но есть одно НО, "замещенные" с включенными валидаторами
> днссек так же не работали :)Ну сорянчик, "боли роста", бывает.
роскомпозор пилит суверенный днс с подменой ключей, больше всех попали мобильные у которых сорм по умолчанию.