Analyse: Ausfall von .ru war wohl kein Kriegsopfer oder Zensurfall

Die Ausfälle zahlreicher Dienste mit der TLD .ru waren wohl ein technischer Fehler oder menschliches Versagen. Eine Post-mortem-Analyse dazu legt das nahe.

In Pocket speichern vorlesen Druckansicht 9 Kommentare lesen
Server,Racks,In,Server,Room,Data,Center.,3d,Render

Irgendjemand hat in Russland das Internet durcheinandergebracht.

(Bild: Sashkin/Shutterstock.com)

Lesezeit: 4 Min.
Von
  • Monika Ermert
Inhaltsverzeichnis

Ausfälle von Webseiten und Diensten in der .ru-Zone am vergangenen Dienstag waren nicht Ergebnis eines Angriffs und laut einer ersten Analyse von DNS Experten auch kein Hinweis auf russische Zensurmaßnahmen. In einer heute bei der Open-Source-Entwicklerkonferenz FOSDEM vorgestellten Post-mortem-Analyse erläuterte Stephane Bortzmeyer von Frankreichs Afnic Registry, wie Fehler bei der DNSSEC-Signierung sich auswirkten. Bortzmeyer und andere hatten schnell DNSSEC als Ursache für den Ausfall ausgemacht.

Das DNSSEC Protokoll erlaubt es den Betreibern von Seiten und Adresszonen, ihre Domains mit Signaturen zu versehen, die erlauben DNS-Antworten auf ihre Authentizität zu prüfen. Wer DNSSEC auf Empfängerseite einsetzt, kann also sicher sein, dass heise.de auch vom Verlag Heinz Heise kommt. Die Technik wurde vor allem als Mittel gegen Phishing eingeführt.

Ein Blick mit dem Open Source-Tool DNSViz illustriert, dass im Fall des .ru-Ausfalls mit dem Wechsel zu einem neuen DNS Zonen-Schlüssel am Dienstagmittag das Problem begann. .ru-Seiten wurden unerreichbar, nachdem ein neuer Zone Signing Key (ZSK), der Schlüssel für die Authentizität der .ru-Zone, eingeführt worden war. Laut Bortzmeyers Analyse waren offenbar die mit dem neuen Schlüssel erzeugten Signaturen kaputt.

Validierende DNS-Resolver verwarfen daher die Antworten zu .ru-Seiten. Wer hinter einem nicht-DNSSEC-validierenden Server saß, hatte dagegen gar kein Problem, so Bortzmeyer. Das erklärt, dass es keinen Komplettausfall gab. Zugleich waren die TLD ".su" und auch die kyrillische Variante von ".ru" nicht betroffen, wie Tests zeigten.

Nach zwei Stunden hatten die Administratoren von Ru-Center, der offiziellen Registry, den alten Schlüssel und die zuletzt damit signierte Zone wieder installiert. Das Bemerkenswerte, und darauf konnten auch Bortzmeyer und weitere Experten keine Antwort geben: für einen weiteren Tag wurde die alten Zonendaten beibehalten. Normalerweise werden die Zonen laufend aktualisiert, um Änderungen aufzunehmen.

Bortzmeyer bestätigte auf Anfrage von heise online: "Es sieht so aus als wäre mit der Einführung des neuen Schlüssels das Signierungssystem kaputtgegangen, wie das sein kann, ist nach wie vor unklar." Am Ende könnten nur die Administratoren von RU-Center aufklären, was genau passiert ist, sagt Allison Mankin, Kopf des DNS Teams bei Packet Clearing House.

Bislang hatte das zuständige Ministerium für digitale Entwicklung, Kommunikation und Massenkommunikation per Telegram lediglich mitgeteilt, dass es sich um einen Fehler bei DNSSEC gehandelt habe. Eine damit verbundene Aussage, dass das Problem für Teilnehmer des normalen nationalen russischen DNS-Systems schneller behoben gewesen sei, verwies Bortzmeyer ins Reich der Fantasie. Die Administratoren bei RU-Center haben auf Nachfragen von heise online nicht reagiert.

Für Mankin und Bortzmeyer ist einigermaßen klar, dass die Kryptografie .ru aus der Bahn geworfen hat. Entweder, so Mankin gegenüber heise online, "gab es einen Fehler bei der Generierung des neuen ZSK oder dieser erzeugte unbrauchbare Signaturen durch einen Fehler im Signierungssystem oder beides. Kryptografie ist kompliziert.“

Unschuldig ist aber, da sind sich beide sicher, Russlands eigener Kryptoalgorithmus "Gost". Zwar gibt es laut russischen Berichten Probleme durch den Wechsel vom ursprünglichen auf einen neuen Gost-Algorithmus. Doch zeigen die DNSViz-Tests rund um den Ausfall, dass durchgängig RSA/SHA256, Algorithm 8, verwendet wurde.

Die DNS-Experten des RU-Centers könnten eine neue Version der Krypto-Software in ihrem DNSSEC-Signing System implementiert haben, sagt Mankin. Diese Version könnte die fehlerhaften Signaturen erzeugt haben. Auf jeden Fall habe man auf Vorabtests verzichtet. Bei den von anderen großen Registries üblicherweise genutzten Open Source-DNSSEC-Sytemen zur Signierung sind diese mittlerweile Standard. Neue signierte Zonen werden damit erst ausgerollt, wenn sie im Test sauber validiert werden können, so Mankin.

Neben solcher Automatisierung, die insbesondere auch für die selteneren Schlüsselwechsel bei den Zone Signing Keys zum Einsatz kommen, gibt es mittlerweile auch Standards, die ein paralleles Signieren von Zonen an zwei Stellen mit verschiedenen Schlüsseln empfehlen.

(bme)