Am 12.5.2010 fiel ja, wie nahezu alle deutschen Internetnutzer gemerkt haben, die zentrale DNS-Infrastruktur der DENIC in wesentlichen Teilen aus. Die Ursache – ein fehlerhafter Kopiervorgang – war so trivial wie die Auswirkungen massiv waren: Viele Seiten waren nicht erreichbar (nicht nur alle deutschen Internetseiten, sondern auch viele .com- und .net- etc. Domänen, da diese ja teilweise Nameserver nutzen, die auf .de-Domänen liegen), Mails konnten nicht zugestellt werden und wurden als unzustellbar abgelehnt usw.
Besonders kritisch war, dass durch den Ausfall bei den Domänen eine Nichtexistenz gemeldet wurde. Mails wurde also nicht als temporär nicht-zustellbar in eine Warteschleife gelegt und später abgearbeitet, sondern „korrekt“ im Sinne der Technik abgelehnt.
Weiterhin hat sich das DNS-Caching als Problem herausgestellt: Auch nach Fehlerbehebung dauerte es ggf. einige Stunden, bis die Korrektur für alle wirksam wurde.
Doch was sind nun die Lehren, die als Provider und Anbieter aus einer solchen Situation gezogen werden können. Aus einer Situation wohlgemerkt, in der providerseitig alles korrekt funktioniert hat: Schließlich ist die Nicht-Existenz einer Domäne ja durchaus möglich.
Ausfallwirkungen
Unterschieden werden muss primär zwischen Web-Seiten, E-Mail und sonstigem Datenverkehr. Web-Seiten werden primär von Menschen besucht und Menschen sehen, dass ein Fehler auftritt. Sie versuchen es entweder später noch einmal oder suchen nach dem Problem. Bei Web-Seiten ist ein solcher Ausfall zwar schlimm, aber es kann direkt darauf reagiert werden.
Auch der „sonstige Datenverkehr“ wird bei dieser Betrachtung außen vor gelassen. Er muss individuell betrachtet werden und individuell müssen Szenarien zur Erkennung und Reaktion bei einem solchen Ausfall entwickelt werden. Beispielsweise nutzen viele unserer Kunden unsere VPN-Systeme. Diese waren jedoch nicht betroffen, da die Kunden unsere Nameserver direkt und nicht über zwischengeschaltete Provider-Nameserver abfragen und somit die VPN-Adresse aufgelöst werden konnten. Ein Fazit kann also sein, gerade bei geschlossenen Systemen möglichst viel Infrastruktur durch eigene Systeme abzudecken.
Kritisch ist also vor allem der E-Mail-Verkehr. Hier muss es Standard sein, den Menschen – bei E-Mails also den Absender – über Probleme zu informieren. Dieses Verfahren ist bei SMTP vorgesehen, scheint jedoch nicht bei allen Providern korrekt umgesetzt worden zu sein, wie Berichten über vermisste E-Mails zu entnehmen ist. Fazit hier ist also, ein Mail-System nicht nur für den Normalfall aufzusetzen und zu betreiben, sondern auch die Ausnahmefälle zu betrachten und zu verifizieren.
Automatische Mailverarbeitung
Einen Sonderfall stellen automatische E-Mails dar. Wie reagiert Ihr System, wenn ein Benutzer über Ihre Webseite eine Kontaktanfrage erzeugt? Normalerweise bekommen Sie sicherlich eine E-Mail. Im aufgetretenen Ausfallszenario haben Sie die E-Mail nicht bekommen, der Webserver wurde wahrscheinlich darüber informiert, dass die Mail an Sie nicht zugestellt werden konnte und – konnte mit dieser Information als Maschine nichts anfangen und hat die Kundenanfrage ins Nichts laufen lassen. Nach diesem Prinzip sind viele wenn nicht sogar die meisten Systeme aufgebaut.
Ein Überwachungsszenario
Auch hier muss das Fazit sein, die eigenen Systeme auf Fehlertoleranz hin auszulegen und die Fehlerfälle durchzuspielen. Wie könnte ein solches System evtl. aussehen? Hier ein sehr simples Szenario:
- Ein Automat macht regelmäßig jede Minute eine Kontaktanfrage an die Webseite.
- Die Webseite speichert Kontaktanfragen zwischen, z. B. in einer Datenbank oder auch nur als „gesendete E-Mails“.
- Jede Kontakt-E-Mail durchläuft einen zweiten Automaten. Kommt nicht jede Minute mindestens eine Kontaktanfrage, wird sofort Alarm ausgelöst. Hierbei wird die Alarmauslösung ebenfalls überwacht: Was nützt eine „Alarm-E-Mail“ wenn diese nicht zugestellt wird. Gegebenenfalls werden weitere Alarmwege eingeschlagen: Wenn der Alarm nicht von einem Menschen bestätigt wird, wird z.B. eine SMS verschickt, danach evtl. ein automatischer Anruf getätigt etc.
Mit einem solchen Szenario geht zum einen keine Anfrage verloren und zum anderen wird schnell ein Mensch informiert, wenn etwas im vorgesehenen Datenfluss nicht in Ordnung ist. (Unser Angebot hierfür ist unsere Serverüberwachung.)
Fazit
Jeder Nutzer und Betreiber einer IT-Infrastruktur muss sich über die Auswirkungen eines Ausfalls im klaren sein. Er sollte die möglichen Ausfallstellen betrachten, diese hinsichtlich Ausfallwahrscheinlichkeit, Entdeckungsmöglichkeiten, Ausfallfolgen und eigenen Eingriffsmöglichkeiten bewerten und dann entscheiden, wie im Ausfall-Fall reagiert werden soll. Denn eines ist klar: Vorbeugung ist aufwändig und es muss zwischen diesem Aufwand und den Kosten des Ausfalls und der Ausfallwahrscheinlichkeit abgewogen werden.