Когато една грешка свали 16 милиона домейна: Урокът от прекъсването на .de DNS

Повечето от нас не се сещат за DNS, докато нещо не се развали. А когато се развали? Всичко се разваля.

На 5 май 2026 г. германският регистър DENIC разбра това по трудния начин по време на рутинна подмяна на DNSSEC ключове. За около три часа достъпът до .de домейни беше като хвърляне на монета — някои работеха, повечето не, а валидиращите резолвъри по света връщаха грешка "bogus" като конфети на развалена фиеста.

Техническата причина? Единствена грешка в персонализиран софтуер за подмяна на ключове. Но истинският урок тук е как и защо това се случи — и това е нещо, върху което всеки разработчик и инженер по инфраструктура трябва да се замисли.

Какво точно се случи

Системата за подписване на DNSSEC за .de домейни комбинира стандартен софтуер (Knot resolver) с вътрешно разработен код, като всичко минава през Hardware Security Modules (HSM). Представи си HSM като свръхсигурни криптографски трезори, които генерират и съхраняват частните ключове, пазещи DNS зоната.

По време на обичайна подмяна на ключове през май 2026 г., персонализираният агент за подмяна — софтуерът, отговорен за генериране на ключови материали и тяхното разпространение — се повреди по начин, който беше едновременно незначителен и катастрофален.

Ето проблемът: вместо да генерира една двойка ключове и да я разпространи до всички HSM устройства, кодът с грешка генерира три отделни двойки ключове — по една за всеки HSM. По-лошото — и трите двойки получиха идентични метаданни, включително един и същ key tag (33834).

Резултатът? Когато зоната беше публикувана, само един от трите HSM устройства имаше частния ключ, съответстващ на публичния DNSKEY запис. Това означаваше, че само около една трета от DNSSEC подписите можеха да бъдат валидирани. Останалите? Невалидни. И при DNSSEC невалиден подпис не означава "вероятно е наред" — означава "фалшив".

Защо тестването не хвана това

Тук историята става наистина ценна за всеки, който пише инфраструктурен код.

Грешката в агента за подмяна се проявява само когато са свързани няколко HSM устройства. Уловката е: тестовата среда се състоеше от едно HSM на едно място.

Когато имаш само едно HSM в тестовата си среда, генерирането на "една двойка ключове за HSM" и "една двойка ключове за всички HSM" дава идентични резултати. Дефектният код мина всички тестове, защото тестовата среда не отразяваше реалността в производство.

Това е класически случай на провал в еднаквостта на средите — феномен, който всеки разработчик познава теоретично, но въпреки това среща в практиката. Тестовата среда беше "достатъчно добра" чак до момента, в който не беше.

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

Ето наистина обезкуражаващата част: системите за мониторинг на DENIC всъщност засякоха проблема.

Три отделни инструмента за валидиране работеха непрекъснато, проверявайки за липсващи или невалидируеми подписи. Тези системи направиха точно това, което се очакваше — идентифицираха аномалиите.

Но генерираните сигнали за тревога не бяха обработени правилно. Известията бяха изпратени, хората не ги получиха навреме (или не реагираха), а счупената зона продължи да се публикува три критични часа.

Това е модел, който виждаме отново и отново: мониторинг, който открива проблеми, е ценен колкото процеса за реакция при инциденти, който ги обработва. Можеш да имаш най-добрата система за наблюдение на света, но ако сигналите за тревога тихо се провалят или playbooks-ите за реакция са неясни, пак си с вързани очи.

Някои големи оператори на резолвъри разбраха какво става и временно изключиха DNSSEC валидиране за .de домейни — по същество карайки резолвърите си да "се доверяват, но да не проверяват" за германските домейни. Това смекчи щетите за техните потребители, но подчерта колко крехки могат да бъдат нашите допускания за валидиране.

Ефектът на доминото: Защо домейните без валидиране също се счупиха

Ето детайл, който прави този инцидент особено поучителен: домейните, които се счупиха, не непременно използваха DNSSEC сами по себе си.

DNSSEC валидирането работи рекурсивно. Когато резолверът запита за .de домейн, отговорът включва NSEC3 записи, които доказват, че определени записи не съществуват в зоната. Тези NSEC3 записи трябва да бъдат подписани — и ако тези подписи са невалидни, целият отговор се маркира като подозрителен.

Така че дори ако твоят германски стартъп няма никаква DNSSEC конфигурация, веригата на делегиране, доказваща съществуването на домейна ти, все още изисква валидни подписи. Когато тези грешки във валидирането се разпространиха, домейни с нулева собствена DNSSEC конфигурация станаха неразрешими.

DNSSEC е толкова силен, колкото най-слабата му зона. Когато подписите на .de зоната се провалиха, целият TLD изглеждаше компрометиран на валидиращите резолвъри.

Какво трябва да отнесат екипите по инфраструктура

1. Тествай в среди, близки до производството

Това изглежда очевидно. Наистина е очевидно. И въпреки това се случва. Ако кодът ти се държи различно с един HSM спрямо три, тестовата ти среда се нуждае от три HSM устройства. Да, е по-скъпо. Да, е по-сложно. Пак е необходимо.

2. Тествай режимите на провал, не само щастливите пътища

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

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

Сигнали за тревога, които никой не знае как да обработи — или които се активират в 3 през нощта без ясни пътища за ескалация — не предотвратяват прекъсвания. Те ги документират. Всеки сигнал за тревога трябва да има свързан runbook. Всеки runbook трябва да се тества тримесечно.

4. Резервирането не е само за хардуер

Инфраструктурата на DENIC имаше HSM устройства, разпределени в две географски отделни дата центъра. Но софтуерната архитектура допускаше, че всички HSM ще се държат идентично. Истинското резервиране означава да проектираш за провал на допусканията си, не само на компонентите си.

5. Помисли за радиуса на експлозията

Когато проектираш критична инфраструктура, попитай се: какво се случва, когато това се счупи, и колко далеч стига щетите? Инцидентът с .de засегна домейни, които нямаха нищо общо с DNSSEC директно. Това е напомняне, че в разпределените системи зависимостите протичат в неочаквани посоки.

Добрата новина

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

Екосистемата на DNSSEC се учи от тези инциденти. Всеки голям престой — всеки .de, всеки Dyn, всяко препъване на Cloudflare — ни учи нещо за изграждане на по-устойчива инфраструктура. Ключът е действително да прилагаме тези уроци.

Накрая: DNS е невидимият герой на интернета, докато не спре да бъде. Прекъсването на .de през май 2026 г. е напомняне, че дори зрели, добре финансирани операции с множество нива на защита могат да бъдат свалени от единствена грешка на правилното място в неподходящия момент.

За разработчиците и екипите по инфраструктура посланието не е страх — а бдителност. Тествай това, което пускаш. Мониторира това, което тестваш. И никога не предполагай, че тестовата ти среда перфектно отразява производствената.

Защото когато DNS се счупи, всичко се счупи. И урокът винаги струва повече, колкото по-ниско в стека го научиш.