Технические подробности касательно вчерашнего сбоя от ресурса opennet.ru.
30 января в 18:20 (MSK) пользователи столкнулись с массовым сбоем определения хостов в доменной зоне RU, вызванный ошибкой при смене ключей, используемых для заверения достоверности зоны RU через DNSSEC. В результате инцидента на DNS-серверах, применяющих DNSSEC для проверки достоверности данных, перестали определяться все домены в зоне ".ru". Проблема затронула только пользователей, использующих DNS-резолверы провайдеров или публичные DNS-сервисы, такие как 8.8.8.8, верифицирующие достоверность запросов при помощи DNSSEC [Примечание RarogCmex: ещё и тех, у кого подключена DNS-верификация]. Пользователей DNS-резолверов, на которых DNSSEC отключён, не пострадали [Примечание RarogCmex: Я не пострадал, кстати].
Произошедшее напоминает прошлогодний инцидент с регистратором InternetNZ, отвечающим за доменную зону ".NZ", который привел к сбою в разрешении доменных имён в зоне ".nz" из-за ошибки при ротации KSK-ключей (Key Signing Key), применяемых для цифровой подписи записей DNSKEY, содержащих ключи для подписи доменной зоны (ZSK, Zone Signing Key). В случае с InternetNZ ошибка была связана с изменением формата ключей при переходе на новую информационную систему регистратора. Причины инцидента в зоне RU пока не детализированы - Координационный центр доменов RU лишь в общих чертах подтвердил, что проблема связана с перенастройкой DNSSEC.
Судя по внешним проявлениям, сбой произошёл в результате попытки замены ключа, используемого для верификации зоны RU. Данный ключ является корнем доверия для остальных ключей, применяемых в доменах второго уровня, и, в свою очередь, использует ключ домена "." в качестве вышестоящего для подтверждения своего доверия. 26 января в настройках DNSEC зоны RU в дополнение к основному ключу с идентификатором 44301 появился дополнительный ключ 52263.
Вчера примерно в 18:20 новый ключ был задействован для верификации записей в зоне RU, но после перехода на новый ключ из-за ошибки перестала проходить проверка подлинности.
Подпись старым ключом была возвращена около 21 часа (MSK), а первый корректный ответ был зафиксирован сервисом dnsviz.net в 22:07 (MSK). Сбойные настройки присутствовали примерно два с половиной часа, но из-за оседания ошибочных записей в кешах DNS-серверов для полного восстановления требуется дополнительное время, если принудительно не очистить кэш на рекурсивных DNS-серверах. Некоторые провайдеры решили проблему более оперативно и радикально, временно отключив в настройках своих резолверов верификацию через DNSEC.
Комментарии
Сообщают с местных предприятий, по краю. Сбой был. Слабовыраженный. Мало кто заметил.
быстро восстановили. продолжала жить почта на гугле. Остальное отвалилось. Пока перегружал маршрутизатор, пока почистил кешь на ноуте, все восстановилось.
ничего не заметила.
Перспективный чат детектед! Сим повелеваю - внести запись в реестр самых обсуждаемых за последние 4 часа.
список залетов подобного типа - тут мы не первые и не основные https://ianix.com/pub/dnssec-outages.html
самые долгоиграющие залеты были у .gov .mil это сами знаете кто
Вон оно как...? А я не мог врубится-думал политика и я из=за не пострадал. Просто подметил, как красавец мужчина, всегда побрит, костюм как влитой вдруг влетает в число кандидатов?! Думаю-дай Платошкина послушаю -он что-то говорил по этому поводу. Влезаю на его канал -"Опаньки"...Ну кое как в обход послушал его, посмеялся.
А дальше абзац на 3 часа. Пришлось и стереть на компе все лишнее, и проверки запустить-ноль. Я даже пыль внутри почистил опять ноль. Приуныл, вечер, а в шахматы не сыграешь. Крайний раз запустил -заработал.
Кстати проверка подключений как раз и показывала про..., как их бишь? А, домены!
Ну хорошо, а я думал меня за любопытство отстранили....
Может на это и был рассчёт?
Это лишь один из слоёв защиты от подмены. Да, важный, но не критический.
Страницы