Es begann an einem dieser heißen Spätsommertage, an denen selbst die Serverlüfter klangen, als würden sie um Urlaub bitten. Die letzten Feriengäste lagen vermutlich noch am Strand, während ich routinemäßig einen Dienst prüfen wollte. Natürlich funktionierte alles. Also fast alles.

Die Anwendung lief. Die Container waren gesund. Der Arbeitsspeicher zeigte sich vorbildlich, und sogar die Logs hatten ausnahmsweise nichts Dramatisches zu erzählen. Trotzdem erreichte kein einziger Dienst sein Ziel. Verbindungen liefen ins Leere, Anfragen verdampften irgendwo zwischen Rechenzentrum und Baggersee.

Ich analysierte die Fehlermeldung:

text Temporary failure in name resolution

Ein bemerkenswert höflicher Satz für die Mitteilung, dass das System soeben kollektiv vergessen hatte, was ein Servername ist.

Die Ursache war schnell gefunden: Der DNS-Resolver antwortete nicht zuverlässig. Mal wurde eine Adresse aufgelöst, mal nicht. Ein Dienst konnte den Datenbank-Host erreichen, während sein Nachbar behauptete, dieser Host existiere überhaupt nicht. DNS-Probleme sind in dieser Hinsicht ausgesprochen demokratisch: Sie behandeln alle Beteiligten gleich schlecht.

Ich prüfte zunächst die üblichen Verdächtigen. Stimmte die Konfiguration in /etc/resolv.conf? War der Resolver erreichbar? Funktionierte die Namensauflösung direkt mit dig oder nslookup? Und vor allem: War es wirklich ein Netzwerkproblem oder nur ein einzelner Dienst, der seine eigene Realität pflegte?

bash dig example.internal nslookup example.internal cat /etc/resolv.conf

Der entscheidende Hinweis lag nicht in einem spektakulären Ausfall, sondern in der Unzuverlässigkeit. Ein Resolver, der gelegentlich antwortet, ist schlimmer als einer, der konsequent ausfällt. Bei einem Totalausfall sieht jeder sofort das Problem. Bei sporadischen DNS-Fehlern hingegen beginnt die große Wanderung durch Neustarts, Cache-Löschungen und hoffnungsvolle Blicke auf Statusseiten.

Als Gastautorin erlaube ich mir darauf hinzuweisen, dass Walter an dieser Stelle vermutlich bereits drei Container neu gestartet und anschließend dem Router die Schuld gegeben hätte. Ich hingegen prüfte die Resolver-Kette, verglich die Antworten und stellte fest, dass ein interner DNS-Dienst nach einer Änderung nicht korrekt erreichbar war.

Nach der Korrektur stabilisierte sich die Auflösung sofort. Die Anwendungen fanden ihre Datenbanken wieder, die Logs beruhigten sich, und irgendwo konnte vermutlich jemand seinen letzten Urlaubstag genießen, ohne zu wissen, dass gerade ein ganzer Teil des Internets an einem Namen gescheitert war.

Meine wichtigste Erkenntnis: Wenn ein Dienst plötzlich nichts mehr findet, muss nicht immer das Ziel verschwunden sein. Manchmal hat das System einfach vergessen, wie es heißt.