Комментарии 38
yota/25011 - не заметил и всё работало тк использовал: rethinkdns + controld (dot/doq) = adblock84% ... а вот ветер сейчас пытается сдувать 4g
На tele2 всё тоже работало. Мне буквально продавец раздал инет, чтобы я оплатил покупку)))
Подтверждаю. Сейчас использую Tele2 «4G Turbo» как основной интернет дома – и вообще не заметил никакого падения, о сбое узнал только из новостей.
Если у вас DNSSEC не включён, то что б вам было?
В сегодняшней ситуации важно не то, включен ли DNSSEC у пользователя, а то, включен ли он на ресолвере. Даже если к DNS-серверу провайдера / публичному DNS-серверу мы обращаемся без всякого DNSSEC, но он использует DNSSEC при запросах к корневым / авторитативным серверам, и эта DNSSEC поломана - мы от него получим SERVFAIL в любом случае.
Так что в случае Tele2 есть два варианта, один - повод похвалить их админов, второй - повод их поругать :) Либо они оперативно отмониторили ситуацию и отключили DNSSEC для зоны RU до устранения проблем, либо у них вообще DNSSEC не был включен...
Вы вообще всё в одну кучу смешали. DNSSEC между клиентом и ресловером, между ресолвером и корневым сервером зоны, между ресолвером и авторитативным сервером конкретного домена. А это разные вещи.
В Вашем примере (если я правильно понял), пусть мы к 8.8.8.8 обращаемся без DNSSEC и просим IP для домена dzen.ru, на котором тоже нет DNSSEC (не проверял и не хочу, правда ли там его нет, но допустим). 8.8.8.8 после истечения TTL старых записей что делает? Сначала обращается к корневым серверам, где, мол, сервер для зоны .ru. А потом обращается к серверу зоны .ru - где сервер для dzen.ru. И если сервер зоны .ru ему возвращает неправильно подписанный ответ - на этом процесс заканчивается, и есть там у dzen.ru DNSSEC, нет ли - уже не важно. И клиент тоже получает в ответ SERVFAIL, независимо от того, запрашивал он с DNSSEC или без оной. Системе достаточно сломаться на одном этапе из цепочки.
Собственно, всё так и было:
При этом не-RU имена резолвились на отлично. Я нахожусь не в РФ, поэтому у себя временно прописал яндексовый DNS, который на момент инцидента резолвил зону правильно, так и пережил инцидент.
Нет, не было. Вот https://habr.com/ru/articles/590107/
А можно чуть больше технических подробностей? Что не так подписали, и почему? И я не понял ничего из картинки, я не специалист по DNSSEC можно чуть описания для неспециалистов?
2048 vs 1024*2
Боюсь, подробности - это внутренняя кухня и что там было мы не узнаем. Кто-то обновил не тем сертификатом (умышленно или по незнанию), что-то недоконфигурировал, сертификат протух по времени именно в этот день и час, а все забыли. Вот, собственно, и все варианты (которые смог придумать). Последний простой, у первых есть подварианты с разными действующими лицами и организациями (и их тоже не особо много как вариантов).
Правильно ли я понимаю, что в качестве временного фикса достаточно было просто отключить DNSSEC на своем резолвере? :trollface:
А вдруг ради этого всё и затевалось? Создаётся помеха с известным решением, но снижающим безопасность, а дальше проводится целевая атака на кого-то.
На кого-то в TLD .ru, которого при этом не достать никак иначе? У Вас есть варианты, кто бы это мог быть? Я бы не стал объяснять злым умыслом то, что куда проще объяснить раздолбайством за которое никто не ответит и автор которого останется неизвестен.
В данном случае не буду спорить, да и я не знаю кто там виноват, но я помню как минимум одну атаку с подделкой доменного имени и https соединения с выпуском сертификатов клонов, для чего как раз необходима вторая фаза с подделкой DNS
К примеру это, хотя тут непонятно был ли злой умысел, другие примеры что-то сразу найти не могу, но помню что какие-то уц даже вылетели из корневых за такое. https://habr.com/ru/companies/infopulse/articles/255251/
А при чем тут dnssec? Вы на Хабре. Тут стоит начинать с пары статей как оно вообще работает и для чего нужно. А потом уже теории строить.
@svkremlдело говорит, чтобы осуществить идеальную подмену, чтобы перенаправить атакуемый хост на ip с фишингом сайта (или какой-то другой информационной системы, например, vpn, чат, блокчейн-сервер... что угодно), при этом чтобы клон сертификата был валиден. Однако, технически дешевле и проще осуществить это у оператора, но может быть это не всегда возможно или не эффективно. Но обычно причина банальная. Например, по мануалу для безопасности рекомендуется обновлять ключи с периодичностью: ZSK каждые 2-3 месяца; KSK раз в 6 месяцев. Поэтому могли просто накосячить при обновлении ключей.
помогло так, в случае с unbound
server:
domain-insecure: "ru."
Не совсем, они же ребутали сервера\сервисы для восстановления и надо было на своём кеширующем сервере для зоны RU статик адресА прописать и параллельную отправку запросов без dnssec валидации. А для всего остального интернета использовать список из днс кешеров провайдера и пачки резервных. Тогда dnssec отключался бы только для зоны RU, что с учётом доступа товарища майора к ключам не несёт для пользователя большей угрозы. Я отказался от идеи подписи dnssec в зоне RU, по причине авторитарности государства.
Хабр - технический сайт. В этой статье сильно не хватает деталей. Открыл, чтобы узнать подробности, а тут видимо просто перепечатка.
а тут видимо просто перепечатка.
вы не заметили, что таких статей стало очень много? и зачастую заканчиваются словами "ранее стало известно, что...(и далее идёт короткая выдержка из другой подобной статьи)" и "больше вы прочитаете в телеграм-канале...".
Хабр - технический сайт.
когда-то был.
Новостной раздел же, спецом для отделения новостей от котлет статей.
Открыл, чтобы узнать подробности
все хотят подробностей, но эти ребята не умеют писать постмортемы, им даже не хватает ума загуглить как это делают коллеги по цеху (например постмортемы cloudflare весьма информативны).
А всё потому что они не смотрели вот это видео...
https://www.youtube.com/live/EOb0Zu3hy2U?si=TPuqcVhRSD2U3kfU
А можно где то посмотреть чьим ключем подписали, что всё сломалось?
СломалСЯ - красивое слово. Но чушь. У каждого косяка есть фамилия и несоответствие занимаемой должности
Инцидент с резолвом доменных имен в зоне RU (DNSSEC) перешёл в стадию возвращения к работе (подписан второй ключ)