Один баг — и 16 миллионов доменов в офлайне: чему нас научил сбой .de

Давайте будем откровенны: DNS работает незаметно ровно до того момента, пока не ляжет. А когда ложится — всё ложится вместе с ним.

5 мая 2026 года немецкий реестр DENIC получил болезненный урок во время плановой ротации DNSSEC-ключей. Три часа .de-домены были недоступны или работали через раз. Резолверы по всему миру выдавали ошибку «bogus» — как будто кто-то на вечеринке случайно сломал диджейский пульт.

Корень проблемы крылся в одной ошибке в самописном софте. Но самое интересное — не техническая деталь, а почему это случилось. И вот здесь есть над чем задуматься.

Что произошло

Инфраструктура подписания .de использует стандартный Knot resolver и кастомные компоненты, работающие через HSM — модули безопасности, которые генерируют и хранят приватные ключи для DNS-зоны. Представьте себе HSM как сверхзащищённый сейф для криптографии.

Во время плановой ротации ключей в мае 2026 года специальный агент — софт, который создаёт ключи и распределяет их по HSM — сработал тонко, но катастрофически неправильно.

Проблема: вместо одной пары ключей на все HSM код сгенерировал три отдельные пары — по одной для каждого модуля. И хуже того — у всех трёх оказался одинаковый идентификатор ключа (key tag 33834).

Результат: при публикации зоны только один из трёх HSM содержал приватный ключ, соответствующий публичной DNSKEY-записи. Только треть DNSSEC-подписей валидировалась. Остальные? Недействительны. В DNSSEC недействительная подпись — это не «ну, ладно». Это «bogus».

Почему тесты не поймали баг

Вот где история становится по-настоящему полезной для всех, кто пишет инфраструктурный код.

Баг проявляется только когда подключены несколько HSM. А тестовое окружение состояло из одного HSM в одном дата-центре.

С одним HSM сгенерировать «по одному ключу на HSM» и «один ключ на все HSM» — это одно и то же. Код проходил все тесты, потому что тестовое окружение не соответствовало продакшену.

классический провал parity между окружениями — то, что все знают в теории, но регулярно получают по лбу на практие. Тестовое окружение было «достаточно хорошим» ровно до того момента, пока не стало катастрофически недостаточным.

Парадокс мониторинга

Самая обидная часть истории: системы мониторинга DENIC обнаружили проблему.

Три инструмента валидации работали непрерывно, проверяя подписи на отсутствие и невалидность. Они сделали своё дело — аномалии были зафиксированы.

Но алерты не дошли до людей вовремя. Уведомления ушли, никто на них не отреагировал, битая зона публиковалась ещё три критических часа.

Паттерн, который мы видим снова и снова: мониторинг, который детектирует проблемы, ценен ровно настолько, насколько ценен процесс реагирования на инциденты. Можно поставить лучший стек observability в мире — но если алерты тихо дохнут или playbooks размыты, вы всё равно летите вслепую.

Некоторые крупные операторы резолверов поняли, что происходит, и временно отключили DNSSEC-валидацию для .de. По сути — переключили свои резолверы в режим «доверяй, но не проверяй» для немецких доменов. Это смягчило ущерб, но наглядно показало, как хрупки наши допущения о валидации.

Эффект домино: почему ломались даже не-DNSSEC домены

Деталь, которая делает этот инцидент особенно поучительным: затронутые домены не обязательно использовали DNSSEC.

DNSSEC-валидация работает рекурсивно. Когда резолвер запрашивает .de-домен, ответ содержит NSEC3-записи, доказывающие, что определённые записи в зоне отсутствуют. Эти NSEC3-записи должны быть подписаны — и если подписи невалидны, весь ответ помечается как подозрительный.

Получается: даже если у вашей немецкой компании нет DNSSEC вообще, цепочка делегирования, подтверждающая существование вашего домена, всё равно требует валидных подписей. Когда валидация посыпалась, домены с нулевой DNSSEC-конфигурацией стали неразрешимыми.

DNSSEC крепок настолько, насколько крепка его слабейшая зона. Подписи зоны .de завалились — и весь TLD выглядел скомпрометированным для валидирующих резолверов.

Что взять на заметку

1. Тестируйте в условиях, максимально приближённых к продакшену

Звучит очевидно. Очевидно и важно. Если код ведёт себя иначе с одним HSM и с тремя — тестовое окружение должно содержать три HSM. Дороже? Да. Сложнее? Да. Всё равно необходимо.

2. Проверяйте не только happy path

Процесс code review пропустил баг, потому что тесты покрывали штатные сценарии. Что происходит при сетевом разделении? При добавлении или удалении HSM? Когда ключи рассинхронизируются? Адверсарное тестирование своих собственных допущений — не опция.

3. Мониторинг без runbook — это просто шум

Алерты, на которые никто не знает как реагировать, или которые срабатывают в 3 ночи без понятного escalation, не предотвращают сбои. Они их документируют. Каждому алерту — runbook. Каждый runbook — проверять раз в квартал.

4. Избыточность — это не только про железо

У DENIC HSMы были распределены по двум географически разнесённым дата-центрам. Но софт полагал, что все HSMы будут работать идентично. Настоящая избыточность — это проектирование под отказ допущений, а не только компонентов.

5. Думайте о радиусе поражения

Проектируя критическую инфраструктуру, спрашивайте себя: что будет, если это сломается, и как далеко распространится ущерб? Инцидент с .de затронул домены, которые не имели никакого отношения к DNSSEC напрямую. Напоминание: в распределённых системах зависимости текут в неожиданных направлениях.

Хорошая новость

DENIC сработали прозрачно. Финальный отчёт подробно описал, что пошло не так, почему существующие защиты не сработали, и какие меры принимаются — включая улучшенные процессы code review и протоколы реагирования.

Экосистема DNSSEC учится на таких инцидентах. Каждый серьёзный сбой — .de, Dyn, Cloudflare — чему-то учит. Главное — применять эти уроки.

Суть: DNS — незаметный герой интернета ровно до того момента, пока не становится головной болью. Сбой .de в мае 2026-го напоминает: даже зрелые, хорошо финансируемые операторы с несколькими уровнями защиты могут быть повержены одним багом в правильном месте в неправильное время.

Для разработчиков и инфраструктурных команд посыл простой: не страх, а бдительность. Тестируйте то, что деплоите. Мониторьте то, что тестируете. И никогда не считайте, что тестовое окружение идеально повторяет продакшен.

Потому что когда DNS ложится — всё ложится. И урок всегда обходится тем дороже, чем позже его получаешь.