Kiedy aktualizacja DNSSEC w .de poszła nie tak: Lekcje z awarii

Wyobraź sobie, że budzisz się w środku nocy i widzisz, że twoja infrastruktura pada na nos. Testy przeszły, symulacje też, a mimo to coś nie gra. Dokładnie to przytrafiło się rejestrowi .de 5 maja 2026 roku.

Przez trzy godziny tysiące stron z domenami .de przestało działać. Nie zniknęły domeny – zepsuł je mechanizm, który miał je chronić.

Burza idealna: Technologia plus błąd w procesie

Rejestr .de przez miesiące budował trzecią generację systemu podpisywania DNSSEC. Przetestowali go. Skontrolowali. Wydawał się nie do złamania.

Nagle nowa wersja wygenerowała trzy różne pary kluczy kryptograficznych zamiast jednej. Opublikowali tylko jeden publicznie. To spowodowało totalny chaos – to, co podpisywało strefę, nie pasowało do tego, czego oczekiwały resolvery.

Technicznie rzecz biorąc, DNSSEC korzysta z key tags – to takie odciski palców kluczy publicznych. System nadał wszystkim trzem kluczom ten sam tag (33834). Większość resolverów odrzucała podpisy, bo prywatny klucz nie zgadzał się z publicznym.

Efekt? System signingowy odświeża i podpisuje rekord SOA przy każdej zmianie strefy. Niektóre aktualizacje przechodziły, inne nie. Powstał bałagan, jakiego nikt wcześniej nie widział.

Dlaczego systemy alarmowe nie zadziałały?

Prawda boli: zadziałały. Rejestr .de ma trzy niezależne narzędzia do wykrywania takich błędów. Wszystkie złapały nieważne podpisy i wysłały alerty.

Nikt na nie nie zareagował.

Powiadomienia trafiły do logów i utonęły w morzu innych sygnałów z monitoringu produkcyjnego. To nie awaria techniki – to błąd procesu. Może trafić każdego, kto zarządza kluczową infrastrukturą.

Pamiętaj: monitoring wart tyle, co procedury reakcji. Automatyczne alarmy bez odpowiedzialności człowieka i ścieżek eskalacji to tylko hałas.

Jak jeden błąd zablokował nawet nieszyfrowane domeny

To, co pogorszyło sprawę, to sposób działania DNSSEC. Nie tylko chroni podpisane domeny. Pokazuje kryptograficznie, że podpisu nie ma – przez rekordy NSEC3.

Gdy strefa .de opublikowała błędne podpisy na NSEC3, resolvery odrzuciły całą delegację dla domen drugiego poziomu. Dotyczyło to nawet tych bez DNSSEC. Miałeś example.de bez zabezpieczeń? I tak nie działała, bo infrastruktura delegacji była "fałszywa".

To subtelny aspekt bezpieczeństwa, o którym mało kto myśli, póki nie wybuchnie.

Ludzka interwencja uratowała sytuację

Pozytywem jest reakcja dużych operatorów resolverów. Tymczasowo wyłączyli walidację DNSSEC dla .de, co pozwoliło użytkownikom dotrzeć do stron. Rejestr im podziękował publicznie.

To pokazuje, jak działa internetowa infrastruktura. Gdy coś się sypie, doświadczeni operatorzy wiedzą, jak poluzować śrubę i przywrócić usługę. Podkreśla też potrzebę ekspertów, którzy w stresie podejmują słuszne decyzje.

Co z tego wynieść?

Dla devów i zespołów DevOps ta historia to kopalnia lekcji:

1. Testy nie łapią wszystkiego. Kod z audytem i pełnymi testami może paść w produkcji. Błąd z wieloma kluczami ominął wszystkie kontrole przed wdrożeniem.

2. Alarmy bez akcji to fikcja. Trzy systemy działały idealnie, ale bez szybkiej reakcji człowieka – na nic.

3. Zależności są podstępne. Awaria dotknęła nieszyfrowane domeny, bo DNSSEC łączy się z resztą ekosystemu w nieoczywisty sposób.

4. Równoległe testy to za mało. Nowy system działał obok produkcyjnego, ale różnice ujawniły błędy dopiero w akcji.

5. Miej plan na kryzys. Duzi operatorzy mieli gotowe procedury. A ty?

Co dalej?

Rejestr .de zapowiada dokładną analizę. Prawdopodobnie wprowadzą lepsze testy DNSSEC, klarowne ścieżki eskalacji alertów i zmiany w obsłudze kluczowych rekordów w strefach TLD.

Dla nas, którzy używamy infrastruktury NameOcean czy własnego DNS, to przypomnienie:

• Wybieraj dostawców z solidnym monitoringiem i reakcją na incydenty
• Zrozum DNSSEC, zanim go włączysz
• Buduj kontakty z ekspertami DNS, którzy znają awarie
• Łącz monitoring prosto z zespołem on-call

Dobra wiadomość? Po trzech godzinach .de wróciło do normy. Infrastruktura wytrzymała. A my zyskaliśmy wiedzę o słabościach i odbudowie podstaw internetu.

To rekompensuje stratę.

Przeżyłeś awarię DNS u siebie? Co z tego wyciągnąłeś? Podziel się historią – wspólne doświadczenia budują odporniejsze systemy.