Das .de-Internet steht still, auch wenn DENIC das nicht will
Am gestrigen Tage war ein guter Teil des deutschsprachigen Internets nicht erreichbar, weil die Nameserver der DENIC fehlerhaft arbeiteten. Aber was genau war passiert?
Grundlagen des DNS
Zunächst eine - verkürzte und oberflächliche - Einführung in die Grundlagen des Domain Name Systems (DNS).
Allen mit dem Internet verbundenen Rechnern - seien es Web- oder Mailserver oder der heimische Rechner zuhause, mit dem man "online geht" - ist eine numerische IP-Adresse zugewiesen, die auf technischer Ebene genutzt wird, um mit einem dieser Rechner zu kommunizieren. Weil es aber u.a. ausgesprochen unpraktisch ist, sich mehrere Milliarden Nummern zu merken, benutzt man in der Regel nicht die IP-Adresse eines Rechners, sondern einen Namen; dieser Name muß aber von der verwendeten Software wieder in die zugehörige IP-Adresse umgesetzt werden. Zu diesem Zweck kann die zu einem Namen gehörende Adresse bei einem DNS-Server abgefragt werden.
Um die Last der ungezählten Abfragen zu verteilen und die Vielzahl der bestehenden Domains und Rechnernamen handhabbar zu machen, aber auch, um die Verantwortung für Domains delegieren zu können, ist das DNS hierarchisch organisiert. Jeder DNS-Server muß (nur) die festen IP-Adressen der sog. Root-Nameserver kennen; alle weiteren notwendigen Auskünfte erhält er durch rekursive Anfragen bei den jeweils zuständigen Nameservern. Nehmen wir an, es wird die IP-Adresse für den Rechner www.th-h.de gesucht. Ein DNS-Server würde zunächst bei einem der Root-Nameserver nachfragen, wer denn für die Top-Level-Domain ".de" zuständig ist; der Root-Nameserver würde ihn dann an einen der Nameserver der DENIC verweisen. Unser DNS-Server fragt jetzt einen dieser Nameserver, wer denn für "th-h.de" zuständig sein mag, und erhält dann als Antwort die Nameserver meines Providers. Diese wiederum fragt er dann nach "www.th-h.de" und erhält schließlich die korrekte IP-Adresse.
Soweit der grundsätzliche Ablauf. Hinzu kommt, daß Rechner von Endbenutzern üblicherweise diese rekursiven Abfragen nicht selbst vornehmen; ihnen sind vielmehr ein oder mehrere DNS-Server des jeweiligen Providers zugewiesen, denen sie ihre Fragen stellen. Diese DNS-Server übernehmen dann einerseits den Aufwand der rekursiven Abfragen und speichern andererseits die Antworten für eine gewisse Zeit zwischen, um bei neuen Anfragen nach genau diesem Hostnamen ohne erneute Abfrage sofort antworten zu können.
Das gestrige Problem
Üblicherweise ist das DNS ein recht robuster Dienst; auch die DENIC unterhält nicht nur einen, sondern eine Vielzahl von Nameservern, hinter denen zudem teilweise geographisch weit verteilte Serverfarmen stehen. Fällt eine Maschine oder ein ganzer Cluster aus oder ist überlastet, gibt es immer noch genügend Redundanzen. Schlimmstenfalls werden Anfragen nicht oder mit der Fehlermeldung, daß der Nameserver vorübergehend nicht erreichbar ist, beantwortet.
All das schützt aber nicht gegen die Art technischer Pannen, die dem gestrigen Problem zugrunde lag. Aus wohl immer noch nicht geklärter Ursache haben nämlich die meisten der Nameserver der DENIC beim alle zwei Stunden stattfinden Update der Zone für ".de" nur eine unvollständige Kopie geladen, die - alphabetisch sortiert - nur Domains mit den Anfangsbuchstaben A-F (oder Zahlen am Anfang) enthielt. Alle anderen Domains waren daher für diese Nameserver nicht existent. Anfragen wurden daher nicht mit Fehlermeldungen beantwortet, sondern mit der verbindlichen Antwort, die betreffende .de-Domain existiere nicht bzw. sei nicht registriert. Benutzer, die zufällig einen der wenigen intakten Nameserver kontaktierten oder deren Provider die korrekten Angaben noch zwischengespeichert hatten, waren von diesem Problem hingegen nicht betroffen.
Für die betroffenen Benutzer stellte sich als unmittelbare Folge zunächst einmal die Nichterreichbarkeit aller Rechner in den betreffenden Domains dar; Webseiten konnten nicht aufgerufen werden, und auch alle anderen Dienste - E-Mail, Usenet-News, FTP, IRC, SSH etc. pp. - auf Rechnern mit Namen innerhalb dieser Domains waren nicht erreichbar. Dieses Problem bestand nicht nur bis zum korrekten Reload der .de-Zone auf den entsprechenden Nameservern der DENIC, sondern teilweise auch darüber hinaus, weil auch die falschen Antworten "diese Domain gibt es nicht" natürlich zwischengespeichert wurden.
Eine weitere, noch gravierendere und erst auf den zweiten Blick erkennbare Folge betraf den E-Mail-Verkehr. Auch E-Mails an nicht-existente Domains sind nicht zustellbar; sie werden nicht nur - wie beim Ausfall von Nameservern - verzögert und über Stunden oder Tage erneut zuzustellen versucht, sondern gehen sofort als unzustellbar zurück. "Zurück" kann aber auch bedeuten, daß sie an eine E-Mail-Adresse in einer ebenfalls angeblich nicht existenten Domain gesendet werden müßten, mit der Folge, daß auch die Unzustellbarkeitsnachricht nicht versandt werden kann und so weder Empfänger noch Absender dieser E-Mail etwas davon erfahren, daß sie nicht zugestellt werden konnte. Dazu kommt weiter, daß E-Mails mit Absendern in (angeblich) nicht existenten Domains regelmäßig gar nicht erst angenommen werden. Der DNS-Ausfall dürfte also zu nicht unerheblichen Zustellproblemen und ggf. zunächst kaum erkennbaren Mailverlusten geführt haben. Weitere Folgen können sich anschließen, so zum Beispiel die automatische Austragung aus Mailinglisten und Newslettern, weil die Empfängeradresse ja nicht mehr existent ist.
Schließlich kam es zu einem enormen Run auf die Registrierungssysteme der DENIC - schließlich war der größte Teil der .de-Domains ja scheinbar "nicht registriert" (weil nicht im DNS eingetragen).
Update: Die DENIC hat mittlerweile eine ausführliche Erklärung der Hintergründe und Folgen des Ausfalls veröffentlicht.
Update: Inzwischen hat auch Isotopp etwas zum Thema geschrieben.
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Rhzfjrf am :
Das mit dem "zurück" stimmt so nicht. Der Absender einer Mail würde in den meisten Fällen sofort eine Fehlermeldung bekommen, weil er garkeine Verbindung zum Empfängerserver aufbauen kann.
Thomas Hochstein am :
Ja, das ist in den meisten Fällen so sicher richtig - je nachdem, wie die Mailinfrastruktur aber gebaut ist, kann es auch passieren, dass der Smarthost (sagen wir mail.smtp.net) die Mail erst einmal annimmt, dann aber nicht an mx.smtp.de zustellen kann, sie aber auch nicht bouncen kann, weil der MX für den Envelope-From auch nicht erreichbar ist.
Hoffen wir, dass der nächste Ausfall dieser Art noch ein paar Jahre mehr auf sich warten lässt.