Когда обновления DNSSEC пошли не так: уроки из блэкаута .de
Когда обновление DNSSEC пошло не так: уроки из сбоя .de
Представьте: вы запускаете обновление в продакшене глубокой ночью. Всё протестировано, симуляции прошли идеально. А потом — крах. Именно это произошло с реестром .de 5 мая 2026 года.
Целых три часа тысячи сайтов на .de были недоступны. Не потому, что домены пропали. А из-за механизма защиты, который сам их сломал.
Идеальный шторм: сбой в коде и процессах
Реестр .de месяцами готовил третье поколение системы подписи DNSSEC. Тестировали. Проводили аудиты. Казалось, железобетон.
Но новая система выдала три разных криптоключа вместо одного. Опубликовали только один публично. Несоответствие между подписью зоны и ожиданиями резолверов запустило цепную реакцию.
Техническая деталь: DNSSEC работает с key tags — это отпечаток публичного ключа. Все три ключа получили один и тот же тег (33834). Резолверы при проверке не могли подтвердить две трети подписей — приватный ключ не сходился с опубликованным.
Проблема распространилась. Система переподписывает SOA-рекорд при каждом изменении зоны. Некоторые обновления проходили, другие — нет. Получилась нестабильная каша, с которой резолверы раньше не сталкивались.
Почему системы обнаружения не сработали?
Не сработали? Сработали. У .de три независимых валидатора на такие сбои. Все трое заметили неверные подписи и подняли тревогу.
Но на алерты не отреагировали.
Уведомления ушли в логи и утонули в потоке мониторинга. Это не техника подвела — подвели процессы. Может случиться с кем угодно, кто держит критическую инфраструктуру.
Мониторинг хорош только с чёткими процедурами реакции. Без ответственности и эскалации — просто шум.
Как ошибка ударила по неподписанным доменам
Сбой вышел особенно жёстким. DNSSEC не только защищает подписанные зоны. Он через NSEC3 доказывает отсутствие подписей для неподписанных.
Неверные подписи на NSEC3 в зоне .de заставили резолверы отвергнуть всю делегацию второму уровню. Даже домены без DNSSEC, типа example.de, стали недоступны. Инфраструктура делегации на их nameserver'ы посчиталась "bogus".
Это тонкий момент безопасности. Большинство DNS-операторов о нём вспоминают, только когда грянет.
Человеческий фактор спас положение
Позитивный момент: крупные резолверы временно отключили валидацию DNSSEC для .de. Сайты ожили. Реестр их публично поблагодарил.
Интернет сработал как часы: при катастрофе профи знают, как ослабить правила и восстановить сервис. Но это подчёркивает нужду в опытных DNS-спецах, которые в стрессе принимают верные решения.
Главные выводы
Для разработчиков и DevOps инцидент даёт уроки:
Тесты не ловят всё. Аудитированный код с полным покрытием провалился в проде. Баг с несколькими ключами прошёл незамеченным.
Мониторинг без действий — пустышка. Три алерта сработали на ура. Но без моментальной реакции и цепочки эскалации — ноль пользы.
Знай зависимости. Удар по неподписанным доменам показал: DNSSEC в TLD бьёт по всем нижестоящим в неожиданных местах.
Параллельный запуск не панацея. Новую систему гоняли бок о бок с продом. Но разница в поведении выявила баги только в бою.
Фиксируй план на ЧП. Крупные резолверы среагировали мгновенно. У вас есть инструкции на DNS-аварии?
Что дальше?
Реестр .de обещает разбор полётов. Ждём жёстких требований к тестам DNSSEC, чёткой эскалации алертов и доработок в генерации ключей для TLD-зон.
Для тех, кто на NameOcean или своём DNS, это сигнал:
- Выбирай провайдеров с крутым мониторингом и реакцией.
- Разберись с DNSSEC до включения.
- Дружи с профи, знающими типичные сбои.
- Строи мониторинг с прямой связью к дежурным.
Хорошая новость: через три часа .de отошёл. Инфраструктура выдержала. А сообщество получило знания о сбоях и восстановлении базовых систем интернета.
Это дороже простого аптайма.
Сталкивались с DNS-сбоями? Что вынесли? Делитесь — такие истории делают наши системы крепче.