Albaniens Domains fielen aus. Deutschlands im Mai.

Eine nationale Domain löste über eine Stunde lang nicht mehr auf

Albaniens Domain .al brach in diesem Monat zusammen. Über eine Stunde lang lösten Adressen im ganzen Land nicht mehr auf: Behördenportale, Medien und private Plattformen gleichermaßen. Bürgerinnen und Bürger erreichten öffentliche Dienste nicht, und Unternehmen, die unter albanischen Domains handeln, verschwanden schlicht aus dem Netz. AKEP, die Regulierungsbehörde des Landes für elektronische Kommunikation und Post, erklärte, das Problem liege bei Systemen im Ausland, die einen Teil der .al-Infrastruktur betreiben. Die Ursache war ein fehlgeschlagener DNSSEC-Schlüsselwechsel, jene kryptografische Routinepflege, die eigentlich unsichtbar bleiben soll.

Warum das zählt. DNSSEC existiert, um zu beweisen, dass eine DNS-Antwort echt ist. Wenn die Signaturen nicht validieren, muss ein korrekt konfigurierter Resolver die Antwort vollständig verweigern und einen Fehler zurückgeben. Das ist der Standard, der genau so arbeitet, wie er entworfen wurde. Der Fehlerfall einer Sicherheitskontrolle, die ihre Arbeit sauber macht, ist ein Land, das offline geht.

Die Abhilfe bestand darin, die Sicherheit abzuschalten

Niemand in der Registry konnte die Signaturen schnell genug reparieren, also umging das Netz das Problem auf die einzige Weise, die ihm bleibt. Cloudflare deaktivierte die DNSSEC-Prüfung für .AL auf seinem Resolver 1.1.1.1 vorübergehend, und andere Resolver-Betreiber taten dasselbe. Das Mittel heißt Negative Trust Anchor und weist einen Resolver an, eine signierte Zone so zu behandeln, als wäre sie unsigniert. Es existiert genau für solche Vorfälle. Die Auflösung kam zurück. Die Validierung nicht.

Cloudflare hatte die Logik bei einem identischen Vorfall im Mai klar benannt: Kein Nutzer, der gerade einen dieser Namen auflöst, würde einen Fehler einer nicht validierten Antwort vorziehen. Das trifft mit ziemlicher Sicherheit zu, und genau darin liegt das ganze Problem. Die Kontrolle fällt nicht sicher aus und sie fällt nicht laut aus. Sie fällt offen aus, nach Branchenkonvention, in genau dem Moment, in dem ein Angreifer sie am liebsten abgeschaltet hätte.

Zehn Wochen zuvor traf es .de auf dieselbe Weise

Am 5. Mai 2026 gegen 19:30 UTC veröffentlichte die DENIC fehlerhafte DNSSEC-Signaturen für die .de-Zone. Validierende Resolver mussten sie zurückweisen und Fehler ausliefern, und eine der größten Top-Level-Domains des Internets begann wegzukippen. Die Ausfälle stiegen über drei Stunden an, während zwischengespeicherte Einträge abliefen. Die DENIC benannte die Ursache selbst: ein planmäßiger, routinemäßiger Schlüsselwechsel, bei dem nicht validierbare Signaturen erzeugt und verteilt wurden. Resolver-Betreiber setzten binnen einer Stunde Negative Trust Anchors, und 1.1.1.1 hatte seine Gegenmaßnahme um 22:17 UTC stehen.

Zwei nationale Registries, zehn Wochen auseinander, beide nicht von einem Angreifer, sondern von planmäßiger Wartung ausgehebelt. Das ist keine Geschichte über Albanien, und es war keine Geschichte über Deutschland. Es ist derselbe Fehler, der zweimal eintrifft, und das macht ihn zu einem Muster und nicht zu einem Unglücksfall. Er wird ein drittes Mal eintreffen.

Jetzt sagt Ihnen der Resolver, wann er zu prüfen aufgehört hat

Das wirklich Neue kam aus diesem Vorfall. Neben der Umgehung führte Cloudflare den Extended DNS Error 33 ein, einen Code, der in der Antwort selbst signalisiert, dass die DNSSEC-Prüfung übergangen wurde. Bisher sah ein Resolver, der die Validierung für eine Zone still fallen gelassen hatte, genauso aus wie einer, der noch prüfte. Sie bekamen eine Antwort, die Antwort funktionierte, und nirgendwo stand, dass die kryptografische Garantie dahinter ausgesetzt war, womöglich stundenlang und womöglich für eine ganze Top-Level-Domain.

Was sich ändert. Dieses Schweigen war die eigentliche Blöße. Wer DNSSEC in einem Risikoregister, einem Sicherheitsfragebogen oder einem NIS2-Kontrollsatz führt, behauptete bisher etwas, das er gar nicht beobachten konnte. EDE 33 macht aus einem unsichtbaren Zustand einen protokollierten. Es ist eine kleine Ergänzung in einem Antwortpaket und das erste ehrliche Signal in diesem Fehlerfall.

Was tun mit einem Schlüssel, den Sie nicht halten

Das Unangenehme ist, wie wenig davon in Ihrer Hand liegt. Ihre Zone kann tadellos signiert sein und Ihre Domain verschwindet trotzdem, weil der Bruch eine Ebene höher passierte, bei der Registry, die die Endung Ihres Landes betreibt. NIS2 stuft DNS-Diensteanbieter und TLD-Registries bereits als Einrichtungen hoher Kritikalität ein, was ein Eingeständnis ist, dass diese Schicht systemisch wirkt. Einen Hebel gibt sie Ihnen nicht. Was Sie tun können: Hören Sie auf, diese Schicht für unbeweglich zu halten. Überwachen Sie, ob Ihre eigene Domain über mehrere öffentliche Resolver auflöst und nicht bloß aus Ihrem Büronetz, und halten Sie fest, was diese Resolver melden.

Das Fazit. Protokollieren Sie EDE 33 und alarmieren Sie darauf. Wenn Ihr Resolver meldet, dass er die Validierung für Ihre TLD übergangen hat, befinden Sie sich in einem Zeitfenster, in dem DNS-Antworten für Ihre Domain ungeprüft sind, und das sollten Sie wissen, während es passiert, statt es hinterher zu lesen. Zwei Länder sind durch dieses Fenster gegangen, ohne es sehen zu können. Das dritte wird immerhin ein Licht haben.

Weiterlesen: Ihre Cloud-Abhängigkeit ist jetzt ein reguliertes Risiko. Die meisten Unternehmen können die eigene nicht einmal sehen.  |  18 Jahre alter Cisco-Fehler: jetzt 3 Tage Frist