Probleme mit .de-Domains: Was bisher bekannt ist

Der Abend des 5. Mai war für viele Administratoren, die Dienste und Webseiten mit .de-Domain betreuen, nicht vergnüglich: Kurz vor 22 Uhr schlugen Monitoringsysteme Alarm, Kunden und Mitarbeiter lösten Supportfälle aus und die Fehlersuche begann – Websites waren nicht erreichbar, Apps funktionierten nicht und VPN-Verbindungen scheiterten. Die Ursache lag aber nicht bei Betreibern von Diensten, sondern an zentraler Stelle: Im Domain Name System (DNS) der Zone .de, genauer in deren DNSSEC-Konfiguration.

Verantwortlich für die Konfiguration ist die DENIC eG, die bisher über den Vorfall nur knapp Auskunft gibt. Am Mittwoch hat sich der Staub zwar gelegt, die Störung ist beseitigt und manche Details zu den Ereignissen werden klarer. Der Blick in die DNS-Daten zeigt aber auch: Die genaue Ursache kann nur die DENIC erklären, eine Stellungnahme steht noch aus. Zur Rekonstruktion der Ereignisse haben wir die historischen DNS-Einträge untersucht, die der Dienst dnsviz.net aufzeichnet.

Was ist passiert

DNSSEC hat die Aufgabe, DNS-Antworten mit digitalen Signaturen gegen Manipulationen zu schützen. Ohne DNSSEC könnten Angreifer Antworten fälschen, wenn sie den Verkehr zwischen Client und Resolver abfangen und verändern. DNSSEC arbeitet mit asymmetrischer Kryptografie, also mit Schlüsselpaaren aus öffentlichem und privatem Schlüssel. Die öffentlichen Schlüssel werden in einem Eintrag vom Typ DNSKEY im DNS hinterlegt. Zum Signieren von Antworten gibt es längere Zone-Signing-Keys (ZSK), die wiederum mit einem kürzeren Key-Signing-Key (KSK) signiert werden.

Geprüft wird die Integrität einer DNS-Antwort schrittweise und zwar von hinten, ausgehend von der Root-Zone, deren Schlüsseln der Anfragende vertrauen muss. Die Root-Zone verweist, digital signiert, auf die zuständigen Nameserver der Toplevel-Domain – konkreten Fall .de. Liefern die einen gültigen signierten Verweis auf den Nameserver, der für diese Domain zuständig ist, wird dieser befragt. Wenn eine Signatur auf dem Weg fehlerhaft ist, wird die ganze Kette als fehlerhaft betrachtet und die Namensauflösung scheitert. Das ist das gewünschte Verhalten, das vor Manipulationen schützt.

In regelmäßigen Abständen werden die Zone-Signing-Keys auf Ebene der Toplevel-Domains getauscht. Weil das ein zentraler Schritt mit weitreichenden Folgen ist, passiert das in mehreren Schritten: Am 2. Mai hat die DENIC als Verantwortliche für die Zone .de einen neuen öffentlichen Schlüssel mit der ID 33834 bekanntgegeben. Das passierte so rechtzeitig, dass sich der neue Eintrag im DNS herumsprechen konnte. Signiert wurde mit dem neuen Schlüssel vorerst nicht, das übernahm der alte Schlüssel 32911. Erstmals als signierender Schlüssel in Erscheinung trat 33834 am 5. Mai um 21:43 (19:43 UTC) in einer Signatur (RRSIG) für den SOA-Eintrag der Zone .de. SOA steht für „Start of Authority“, der Eintrag enthält Informationen zur Zone selbst. Diese Signatur war aus noch ungeklärter Ursache ungültig. Die Daten von dnsziv zeigen: Alle 6 zuständigen Nameserver lieferten zu diesem Zeitpunkt diese defekte Signatur mit dem Schlüssel 33834 aus.

Gegen 21:59 waren die ersten Gegenmaßnahmen zu erkennen: Einer der Nameserver, n.de.net, lieferte ab da einen neuen RRSIG-Eintrag für den SOA-Eintrag mit einer gültigen Signatur, signiert mit dem neuen Schlüssel 33834. Die anderen fünf Server verbreiteten weiter die falsche Signatur.

Um 22:27 zeigte sich ein neues Bild: n.de.net lieferte wieder eine ungültige Signatur, jetzt hatten a.nic.de und z.nic.de gültige Einträge mit dem alten Schlüssel 33834 zu bieten – jedoch unterschiedliche per IPv4 und IPv6. z.nic.de zeigte parallel auch noch eine defekte Signatur. Um 22:31 dann der nächste Zustand, jetzt waren fünf Server in der Lage, richtig mit dem neuen Schlüssel 33834 zu signieren und nur n.de.net, der dieses Kunststück zuvor schon vollbracht hatte, lag mit seinem Eintrag daneben. Nur drei Minuten später lieferten zur Abwechslung alle falsche Antworten, in kurzen Abständen kamen immer andere Kombinationen von den Servern, die alle ungültig waren.

Um 22:50 hatten sich zwischendurch die meisten Server auf eine gemeinsame gültige Signatur mit dem alten geeinigt, nur n.de.net lag weiter daneben. Das änderte sich erstmals um 1:15 am 6. Mai (23:15 UTC), als wieder alle Server korrekte Antworten parat hatten – wenn auch noch nicht perfekt: a.nic.de und z.nic.de lieferten parallel zwei Signaturen, immerhin waren beide gültig. Um 1:17 dann endlich der erwünschte Zustand: Sechs Nameserver konnten eine gültige Signatur erzeugen. Weil es nicht gelungen war, alle sechs Nameserver zu überzeugen, gleichzeitig mit 33834 zu signieren, waren zu diesem Zeitpunkt alle auf den Schlüssel 32911 ausgewichen, der Schlüsseltausch wurde also rückabgewickelt. Daran hat sich bis zum Nachmittag des 6. Mai nichts geändert, bisher gab es keinen erneuten Versuch, den Schlüssel 33834 wieder einzusetzen.

Was folgt daraus

Der Blick in die historischen DNS-Daten zeigt: Mit dem Schlüssel 33834 war etwas faul, zumindest im Zusammenspiel mit SOA-Einträgen. Andere DNS-Einträge konnten zu jeder Zeit erfolgreich signiert werden. 15 Minuten nach der ersten ungültigen Signatur begannen deren Gegenmaßnahmen. Trotz einigen Wirrungen gelang es aber nicht, den Schlüssel auf allen sechs Servern für SOA-Signaturen zu nutzen. Um den Ausfall in den Griff zu bekommen, entschied man sich dann, diese wieder mit dem Schlüssel 32911 zu signieren.

Für .de-Domains ist ein solcher Ausfall wegen eines DNSSEC-Fehlers bisher einmalig. Im Jahr 2022 gab es in Schweden mit der Domain .se Probleme, die auf DNSSEC zurückzuführen waren. Russland hatte 2024 mit .ru-Domains ein DNSSEC-Problem. Ursächlich damals war eine doppelt vergebene Keytag-ID.

DENIC ist jetzt in der Verantwortung, die Ursache des Problems zu benennen und zu erklären, welche Gegenmaßnahmen ergriffen wurden. Unbeantwortet ist auch die Frage, warum die Signaturprobleme nicht bereits in einer Testumgebung aufgefallen sind.

(jam)