Trzy godziny ciszy w niemieckim internecie. Anatomia awarii DNSSEC w domenie .de

5 maja 2026 wieczorem znaczna część niemieckich domen przestała się otwierać. Nie był to atak, awaria zasilania ani problem z kablem podmorskim. Wystarczył jeden błędny podpis kryptograficzny w strefie .de, by miliony stron — od amazon.de, przez Deutsche Bahn, po web.de — zwracały SERVFAIL przez ponad trzy godziny. Rozkładamy ten incydent na czynniki pierwsze i wyjaśniamy, dlaczego dotyczy on także administratorów po polskiej stronie granicy.

Co się wydarzyło — chronologia

DENIC, operator rejestru drugiej co do wielkości narodowej domeny w internecie, zaczął publikować nieprawidłowe podpisy DNSSEC dla strefy .de około 19:30 UTC 5 maja 2026 roku. Sam rejestr potwierdził później, że problem został wykryty wewnętrznie o 21:57 CEST — czyli niedługo po tym, jak Cloudflare zaobserwował pierwsze odrzucone podpisy.

Od tego momentu zaczął się efekt domina. Każdy resolwer DNS walidujący DNSSEC, który otrzymał te podpisy, był zobowiązany przez specyfikację DNSSEC do ich odrzucenia i zwrócenia kodu SERVFAIL. To dotyczyło zarówno publicznych resolwerów typu 1.1.1.1, 8.8.8.8 czy 9.9.9.9, jak i firmowych Unboundów, BIND-ów i Knot Resolverów z włączoną walidacją.

Skala robi wrażenie nawet na sucho. Domena .de jest drugą najpopularniejszą krajową domeną najwyższego poziomu — 17,9 mln rejestracji według stanu na koniec pierwszego kwartału 2026, ustępuje tylko chińskiej .cn. ICANN szacuje, że tylko około 3,6% domen .de jest podpisanych DNSSEC, co i tak oznacza setki tysięcy domen — ale jak za chwilę zobaczymy, w praktyce zasięg awarii był znacznie większy.

Naprawa nie była natychmiastowa. DENIC ponownie podpisał problematyczny zakres NSEC3 około 20:15 UTC, używając nowego klucza o keytagu 32911. Pełna dystrybucja prawidłowej strefy DNS rozpoczęła się o 00:08, a stan operacyjny sprzed awarii został w pełni przywrócony o 01:15 6 maja. Z uwagi na sposób działania pamięci podręcznej DNS część użytkowników widziała błędy jeszcze do rana.

Dlaczego pojedynczy błąd położył całą TLD

Żeby zrozumieć dlaczego incydent miał tak gigantyczne konsekwencje, trzeba przypomnieć sobie po co w ogóle istnieje DNSSEC.

DNSSEC dodaje warstwę kryptograficzną do tradycyjnego DNS. Każda strefa podpisana DNSSEC ma swoje klucze: KSK (Key Signing Key) i ZSK (Zone Signing Key). KSK podpisuje zestaw kluczy DNSKEY, ZSK podpisuje wszystkie pozostałe rekordy w strefie. Resolwer, który ufa kluczowi nadrzędnemu (poprzez DS w strefie rodzicielskiej), może matematycznie zweryfikować, że odpowiedź DNS nie została zmodyfikowana po drodze.

To genialne rozwiązanie — pod warunkiem, że łańcuch zaufania jest spójny. Kiedy choć jedno ogniwo łańcucha pęknie, walidujący resolwer musi odmówić zwrotu odpowiedzi. Nie wolno mu zgadywać czy degradować się do trybu niewalidującego. Zwraca SERVFAIL i kończy.

W normalnych okolicznościach to dokładnie tego oczekujemy — DNSSEC chroni przed atakami typu DNS spoofing czy cache poisoning, i ma być nieugięty. Problem polega na tym, że ten sam mechanizm, który chroni przed atakującym, działa identycznie kiedy operator zaufanej strefy sam wyprodukuje uszkodzony podpis.

I właśnie to wydarzyło się 5 maja.

Co dokładnie zepsuł DENIC

DENIC opublikował już pierwszą analizę powdrożeniową — i jest w niej kilka konkretów, które warto rozłożyć na czynniki pierwsze.

Bezpośrednią przyczyną była rutynowa rotacja kluczy DNSSEC. Podczas tej operacji wygenerowano i rozdystrybuowano część niewalidowalnych podpisów. Proces podpisywania DNSSEC dla .de wykorzystuje standardowe oprogramowanie (Knot) wraz z własnymi rozwiązaniami i sprzętowymi modułami bezpieczeństwa (HSM). W kwietniu 2026 wdrożono trzecią generację tego systemu (od momentu wprowadzenia DNSSEC w 2011 roku). Systemy zostały przetestowane i niezależnie zaudytowane.

I tu jest najbardziej niewygodna część komunikatu. Podczas implementacji ulepszeń do własnego oprogramowania trafił błędny fragment kodu, który nie został w pełni pokryty scenariuszami testowymi i z tego powodu nie został wykryty ani podczas testów, ani w „zimnym” trybie pracy równoległej przed wdrożeniem produkcyjnym.

A teraz konkret techniczny, który robi największe wrażenie. W rezultacie tego błędu dla tego samego identyfikatora keytag (33834) wygenerowano nie jedną, lecz trzy różne pary kluczy. Tylko klucz publiczny jednej z tych par został umieszczony w rekordzie DNSKEY, w związku z czym tylko około jedna trzecia rekordów RRSIG była walidowalna. Ponieważ rekord SOA musi być przy każdej zmianie strefy generowany od nowa (z powodu numeru seryjnego) i na nowo podpisywany, jego walidowalność wahała się w czasie.

To było dokładnie to, co zaobserwowali zewnętrzni badacze. Serwery DNS DENIC dostarczały podpis RRSIG z keytagiem 33834 dla rekordu NSEC3 obejmującego konkretny zakres haszy, który niezależne resolwery odrzucały jako nieprawidłowy. Rekord pojawiał się pod hashem a0d5d1p51kijsevll74k523htmq406bk.de — jeden konkretny, niesprawny podpis stał się trąbą Jerycha dla całego ccTLD.

Dlaczego ucierpieli też właściciele domen .de bez DNSSEC

To pułapka, która wielu zaskoczyła. Przecież tylko 3,6% domen .de korzysta z DNSSEC — więc dlaczego problem dotknął praktycznie wszystkich?

Odpowiedź leży w mechanizmie NSEC3, który DENIC stosuje do tzw. „authenticated denial of existence” — kryptograficznego dowodu, że dana subdomena nie istnieje.

Niewalidowalne podpisy nad rekordami NSEC3 powodują, że informacja o delegacji jest klasyfikowana przez resolwery jako „bogus” — co oznacza, że nawet domeny drugiego poziomu, dla których DNSSEC w ogóle nie jest używany, nie były możliwe do rozwiązania.

Innymi słowy: jeśli twoja domena firma.de w ogóle nie ma włączonego DNSSEC, ale rekord NSEC3 dotyczący zakresu haszy obejmującego twoją domenę był uszkodzony, walidujący resolwer nie był w stanie udowodnić, że na poziomie rejestru nic z twoją domeną nie jest podejrzane — i zwracał SERVFAIL. Szlaban dotyczył wszystkich.

Do tego dochodzi sposób, w jaki resolwery działają z czasem. Po początkowym skoku SERVFAIL-i o 19:30 UTC, ich liczba rosła stopniowo przez kolejne trzy godziny, w miarę jak rekordy w pamięci podręcznej traciły ważność i resolwery wracały do DENIC po świeże kopie, otrzymując zepsute podpisy. To dlatego doświadczenia użytkowników były tak nierówne — niektórzy widzieli problemy od razu, inni dopiero po godzinie czy dwóch, kiedy ich resolwer próbował odświeżyć cache.

Skutki w praktyce

Lista poszkodowanych usług czyta się jak A4 dużych marek niemieckiej gospodarki cyfrowej. Downdetector odnotował tysiące zgłoszeń dotyczących Amazon, DHL, Steam i web.de, a anegdotyczne raporty wskazywały na niedostępność eBay i głównych portali informacyjnych.

Szczególnie pouczające są dwa przypadki. Po pierwsze — pasażerowie Deutsche Bahn nie byli w stanie wyświetlić cyfrowych biletów na telefonach, a konduktorzy nie mogli ich zweryfikować. W nocnych pociągach kłócono się nad papierowymi wydrukami. Po drugie, czysta poezja: pracownicy DENIC sami zostali dotknięci awarią — ich wewnętrzny e-mail przestał działać, ponieważ ich serwery pocztowe nie mogły zwalidować podpisów DNSSEC własnej organizacji. Rejestr, który zepsuł niemiecki internet, nie mógł wysyłać o tym e-maili.

Pojawił się też drugorzędny, bardziej cyniczny skutek dla biznesu. Reklamodawcy uruchamiający kampanie na Meta i Google byli obciążani za tysiące kliknięć w landing page’e .de, które nigdy się nie załadowały. Kliknięcia rejestrowały się; strony nie.

Reakcja: NTA, serve stale i RFC, o których zwykle się nie mówi

W tle awarii rozegrała się fascynująca operacja na poziomie infrastruktury internetu — i to jest część, która powinna interesować każdego administratora hostingowego.

Cloudflare miał dwa narzędzia. Pierwsze działało automatycznie i samoczynnie zamortyzowało skalę problemu.

Wiele rekordów .de wciąż znajdowało się w pamięci podręcznej z czasu sprzed incydentu. Zamiast natychmiast je odrzucić i zwrócić SERVFAIL użytkownikom, 1.1.1.1 kontynuował ich serwowanie po wygaśnięciu TTL. To nazywa się „serving stale”. RFC 8767 formalizuje to zachowanie: gdy rozwiązywanie nazwy w warstwie wyższej zawodzi, resolwer może kontynuować serwowanie wygasłych rekordów z pamięci podręcznej zamiast zwracać błąd. To kupuje operatorom czas na reakcję.

Drugi mechanizm wymagał świadomej decyzji. RFC 7646 definiuje pojęcie Negative Trust Anchor (NTA) — w normalnej pracy DNSSEC walidujący resolwer utrzymuje zestaw zakotwiczeń zaufania. NTA to jawny wyjątek mówiący resolwerowi, by traktował określoną strefę jako niepodpisaną, omijając walidację dla nazw pod tą strefą. Cloudflare dodał taki wyjątek o 22:01 UTC, by umożliwić rozwiązywanie nazw .de — dokładnie zgodnie z RFC.

Dla porządku — to nie było „obejście zabezpieczeń”. To celowy mechanizm wbudowany w DNSSEC właśnie na taką okoliczność. Niektórzy operatorzy dużych resolwerów tymczasowo wyłączyli walidację dla domen .de, łagodząc skutki dla swoich użytkowników. DENIC podziękował im za pomoc — i to jest dość znamienne, że organizacja, której DNSSEC popsuł zaufanie, formalnie dziękuje stronom trzecim za jego ominięcie.

Co to jest właściwie ten ZSK rollover i dlaczego się psuje

Zone Signing Key z założenia powinien rotować często. Im krótszy czas życia klucza, tym mniejsze konsekwencje jego ewentualnego skompromitowania. Według FAQ DENIC, ZSK dla .de rotuje się standardowo co 5 tygodni, w trybie pre-publish. Tryb pre-publish polega na tym, że nowy klucz publikuje się w DNSKEY zanim zacznie podpisywać — tak, by walidujące resolwery zdążyły go pobrać i zacache’ować.

Procedura jest standardem od ponad dekady i działała setki razy bez problemu. Ale jak każdy zautomatyzowany proces krytyczny — wymaga nieustannego monitoringu i absolutnej spójności między tym, co opublikowane (DNSKEY), a tym, czym faktycznie podpisano (RRSIG). W tym konkretnym przypadku DENIC opublikował jeden klucz publiczny, ale podpisał część rekordów innym, którego klucza publicznego w strefie nie było. Z punktu widzenia walidatora — sytuacja matematycznie nieodróżnialna od próby manipulacji odpowiedziami DNS.

To nie jest pierwszy przypadek tego typu. Strefa .se w Szwecji miała podobny incydent w 2009 roku. Domena .nz w Nowej Zelandii — w 2017. Wniosek jest niewygodny, ale szczery: nawet zaudytowane, profesjonalnie prowadzone rejestry zdarza się przewracać na rotacjach kluczy. To jest złożona operacja kryptograficzna, w której margines błędu jest brzytwą.

Konsekwencje dla polskich administratorów i właścicieli domen .de

W Polsce — bo ta sytuacja ma kilka praktycznych implikacji, których nie warto przegapiać.

Po pierwsze, polscy odbiorcy ruchu z Niemiec. Jeżeli prowadzisz e-commerce z dostawą do DE, agencję obsługującą niemieckich klientów albo SaaS rozpoznawany rynkowo na zachód od Odry — w przedziale ok. 19:30–01:15 (5 na 6 maja) zalogowanie czy zakup z niemieckiej sieci mogły po prostu nie zadziałać. Warto sprawdzić logi serwera z tej nocy. Spadek konwersji, błędy w kolejkach mailowych do adresów @*.de, niedoręczone potwierdzenia płatności — wszystko to mogło mieć tę samą przyczynę.

Po drugie, polscy właściciele domen .de. Jeśli posiadasz domeny .de jako właściciel firmy w Polsce, działającej na rynku niemieckim — nie miałeś żadnego wpływu na incydent. Awaria była po stronie rejestru, powyżej poziomu pojedynczej domeny. Żadna konfiguracja po twojej stronie nie mogła temu zaradzić. To brutalna, ale ważna lekcja na temat tego, gdzie kończą się twoje kompetencje administracyjne.

Po trzecie, kontekst polskiej domeny .pl. NASK, operator .pl, podpisuje strefę .pl DNSSEC od 2012 roku i również stosuje rotację kluczy. Polscy administratorzy mają więc pełne prawo zadać pytanie: a co jeśli to wydarzy się u nas? Odpowiedź jest twarda — zachowanie dokładnie takie samo. SERVFAIL na każdej domenie .pl walidowanej przez 1.1.1.1, 8.8.8.8 i resolwery większości polskich ISP. Plus konsekwencje dla tych domen .pl, które same z siebie DNSSEC nie używają, ale leżą w zakresie haszy NSEC3 obejmującym uszkodzony rekord.

Praktyczne wnioski dla osób utrzymujących infrastrukturę

Z incydentu wynika kilka rzeczy, które warto wpisać sobie do checklisty operacyjnej — niezależnie od tego, czy zarządzasz pojedynczym serwerem dedykowanym, czy infrastrukturą hostingową dla setek klientów.

Monitoring rozproszony. Nie wystarczy sprawdzać czy twoja strona odpowiada z jednego miejsca. Awaria DNSSEC objawia się różnie w zależności od tego, gdzie i jakim resolwerem testujesz. Rozproszone monitoringi typu RIPE Atlas, Updown.io z wieloma lokalizacjami albo własne sondy w różnych ASN-ach pozwalają złapać tego typu incydent dużo szybciej niż jeden monit z jednego data center.

Diversyfikacja resolwerów po stronie klienta. Jeśli prowadzisz infrastrukturę krytyczną biznesowo, warto skonfigurować nie tylko jeden publiczny resolwer (np. tylko 1.1.1.1), tylko fallback. Klasyczny układ to: ISP local + 1.1.1.1 + 9.9.9.9. W praktyce jednak wszystkie te resolwery walidują DNSSEC, więc przy awarii TLD wszystkie zwrócą SERVFAIL. Realna ochrona to mieć w zapasie chociaż jeden niewalidujący resolwer, do którego można awaryjnie skierować ruch operacyjny.

Krótszy TTL rekordów DS — z umiarem. W teorii krótkie TTL na rekordach DS pozwalają szybciej propagować zmiany podczas rotacji kluczy. W praktyce ułatwiają też szybkie rozprzestrzenianie się problemów, jeśli rotacja pójdzie źle. Branżowy standard 86400 sekund (24 godziny) dla DS to kompromis, który ma sens — agresywne skracanie nie jest tanim zwycięstwem.

Backup TLD dla usług krytycznych. Dla absolutnie najważniejszych usług biznesowych — paneli klienta, API rozliczeniowych, systemów wsparcia — warto pomyśleć o domenie zapasowej w innym TLD. Nie z powodu paranoi, tylko realiów: incydent .de udowodnił, że awaria może wyłączyć całą TLD na kilka godzin, niezależnie od kompetencji właściciela domeny. Jeden mailing z linkami do firma.eu zamiast firma.de w razie potrzeby kosztuje minuty pracy, a może uratować obsługę klienta.

Sprawdzanie łańcucha DNSSEC na bieżąco. Narzędzia typu DNSViz (dnsviz.net) pozwalają zobaczyć stan łańcucha zaufania dowolnej domeny. Wpisanie tam swojej domeny od czasu do czasu — i każdorazowo po większych zmianach DNS — to dwie minuty roboty.

Świadome podejście do DNSSEC. Niska adopcja DNSSEC na świecie ma dobrze ugruntowany powód — ten incydent jest jego manifestacją w pełnej krasie. Mniej niż 10% większości TLD korzysta z DNSSEC. Wyjątkami są m.in. Holandia, Szwecja, Czechy i Chiny, gdzie adopcja jest wyższa, ale dla większości administratorów domen DNSSEC pozostaje pomijany. To nie znaczy, że DNSSEC jest zły — jest niezbędną warstwą bezpieczeństwa, która zapobiegła wielu realnym atakom. Ale wdrożenie wymaga świadomej decyzji o tym, że bierzesz na siebie operacyjną złożoność rotacji kluczy.

Co dalej

DENIC obiecał pełne post-mortem po zakończeniu wewnętrznych analiz. Pierwsza, opublikowana po tygodniu od incydentu, wskazuje konkretnie kilka rzeczy, które rejestr już wie:

• system działał na nowej, trzeciej generacji infrastruktury wdrożonej miesiąc wcześniej,
• problem leżał w wewnętrznym kodzie, nie w open-source’owym Knot,
• testy nie pokryły scenariusza, który spowodował awarię,
• audyt zewnętrzny nie wykrył błędu.

To są poważne stwierdzenia. Mówią one, że nawet wewnętrznie audytowany system, przetestowany w trybie zimnej pracy równoległej, w trzeciej iteracji historii — może wpaść w błąd, który zauważy się dopiero w produkcji, kiedy zaczyna podpisywać miliony rekordów.

Dla branży to jest dyskomfort, ale i lekcja w stronę pokory. DNSSEC zadziałał dokładnie tak, jak miał zadziałać. To mechanizm wokół DNSSEC — generowanie kluczy, koordynacja publikacji, monitoring spójności łańcucha — zawiódł. I to ten obszar wymaga w branży hostingowej najwięcej dyscypliny.

Najmocniejszy wniosek z całej historii: w internecie 2026 roku jeden źle podpisany rekord NSEC3 może na trzy godziny wyciszyć trzeci najpopularniejszy ccTLD na świecie. Twoja strona, niezależnie od tego, gdzie ją hostujesz i ile zapłaciłeś za uptime SLA, jest tak silna jak najsłabsze ogniwo łańcucha DNS nad nią. To nie jest powód do paniki. To powód do regularnego sprawdzania, czy faktycznie wiesz gdzie te ogniwa są.

Źródła: blog DENIC (analiza techniczna 5–6 maja 2026), Cloudflare blog (incydent z perspektywy 1.1.1.1), Cloudflare Status, The Register, Domain Name Wire, Cybernews, Hacker News (techniczne dyskusje administratorów podczas trwania awarii), Blackfort Technology (analiza techniczna NSEC3 keytag 33834).