„Seite nicht erreichbar" trotz laufendem Server: wenn DNS das Problem ist

Der Anruf beginnt fast immer gleich: „Unsere Seite ist down!" Du prüfst den Server, und er läuft. CPU normal, Dienste aktiv, die Seite antwortet, wenn du sie direkt über die IP aufrufst. Trotzdem sehen deine Besucher nur eine Fehlermeldung. Wenn Server und Seite gesund sind, aber niemand hinkommt, liegt die Ursache oft an einer Stelle, die kaum jemand überwacht: im DNS, dem Adressbuch des Internets, das den Domainnamen in eine erreichbare Adresse übersetzt. Dieser Artikel erklärt, warum eine Seite „nicht erreichbar" sein kann, obwohl der Server einwandfrei läuft, und wie du solche Probleme erkennst, bevor deine Kunden es tun.

Warum „Server läuft" nicht „Seite erreichbar" heißt

Der intuitive Kurzschluss lautet: Wenn der Server läuft, ist die Seite erreichbar. Das stimmt nur, wenn eine unsichtbare Kette dazwischen intakt ist. Bevor ein Besucher überhaupt bei deinem Server ankommt, muss sein Gerät den Domainnamen, etwa deinkunde.de, in eine IP-Adresse übersetzen. Diese Übersetzung übernimmt das DNS, das Domain Name System, eine Art globales Adressbuch. Erst mit der aufgelösten IP kann der Browser eine Verbindung zum Server aufbauen.

Fällt diese Übersetzung aus oder liefert sie die falsche Adresse, bricht die Kette, und zwar vor dem Server. Der Server selbst bekommt von alldem nichts mit: Er läuft, wartet auf Anfragen, ist kerngesund. Aber es kommen keine Anfragen mehr an, weil die Besucher den Weg zu ihm nicht mehr finden. Für den Nutzer ist die Seite „down"; für dich, der du den Server direkt über die IP erreichst, läuft alles. Beide haben recht, und genau diese Diskrepanz ist das verräterische Zeichen eines DNS-Problems.

Das macht DNS-Fehler so tückisch: Sie erzeugen ein Ausfallerlebnis ohne einen ausgefallenen Server. Alles, worauf ein klassisches Server-Monitoring schaut, Erreichbarkeit der IP, Antwortzeit, Dienststatus, ist grün. Der Fehler sitzt in der Schicht davor, die die meisten gar nicht im Blick haben.

Die häufigsten DNS-Ursachen für eine „tote" Seite

DNS-Probleme haben ein paar wiederkehrende Muster. Sie zu kennen hilft, den richtigen Ort zu untersuchen, statt am gesunden Server zu verzweifeln.

Abgelaufene oder falsche Delegation (NXDOMAIN). Jede Domain wird über Nameserver delegiert, die für ihre Einträge zuständig sind. Stimmt diese Delegation nicht mehr, weil sie falsch gesetzt wurde, ein Nameserver-Wechsel schiefging oder die zuständige Zone gelöscht wurde, kann das DNS keinen gültigen Eintrag finden. Der Browser zeigt dann typischerweise DNS_PROBE_FINISHED_NXDOMAIN, also „diesen Namen gibt es nicht". Der Server existiert weiter, aber sein Name führt ins Leere.

Der abgelaufene Domain-Eintrag. Wird eine Domain nicht rechtzeitig verlängert, deaktiviert die Registry ihre DNS-Auflösung, oft schlagartig. Von einer Sekunde auf die andere ist die Seite für alle unerreichbar, obwohl sich am Server nichts geändert hat. Dieser Fall ist besonders ärgerlich, weil er hundertprozentig vermeidbar und trotzdem häufig ist.

Der versehentlich geänderte Record. Ein Fingerfehler im DNS-Panel, eine falsche IP im A-Record, ein gelöschter Eintrag, ein vertippter Wert, schickt Besucher an die falsche Adresse oder ins Nichts. Solche Änderungen passieren oft im Zuge anderer Arbeiten (ein Umzug, ein neuer Dienst) und bleiben unbemerkt, bis sich jemand beschwert.

DNS-Hijacking. Im bösartigen Fall ändert ein Angreifer die DNS-Einträge unbefugt und leitet die Domain auf einen fremden, oft schädlichen Server um. Der ursprüngliche Server läuft unverändert weiter, aber Besucher landen woanders. Weil der eigene Server gesund ist, bleibt klassisches Monitoring still, während im Namen deines Kunden womöglich fremde Inhalte ausgeliefert werden. Das ist die gefährlichste Variante, weil sie nicht nur die Erreichbarkeit, sondern die Sicherheit betrifft.

Allen Fällen ist eines gemeinsam: Der Server ist unschuldig. Das Problem sitzt im DNS, und es ist unsichtbar, solange man nur den Server beobachtet.

Warum klassisches Monitoring hier blind ist

Der Grund, warum DNS-Probleme so oft erst durch einen Kundenanruf auffallen, liegt in der Funktionsweise des üblichen Monitorings. Ein typischer Uptime-Check fragt: „Antwortet der Server unter dieser Adresse?" Er baut also selbst eine Verbindung auf und wertet die Antwort aus. Das ist stark für Server-Ausfälle, aber es setzt voraus, dass die Adresse, die geprüft wird, überhaupt noch die richtige ist.

Und genau hier liegt der blinde Fleck. Bei einem DNS-Hijacking zeigt der Record auf eine neue IP. Der Check würde, wenn er der Auflösung folgt, den fremden Server prüfen und ihn womöglich für „online" halten. Bei einem versehentlich falschen A-Record prüft das Monitoring vielleicht noch die alte, hinterlegte IP und meldet „alles ok", während die echten Besucher der neuen, falschen Auflösung folgen. Und bei einer NXDOMAIN-Situation kann ein Check, der direkt auf die bekannte IP zielt, weiterhin grün sein, obwohl kein Besucher den Namen mehr auflösen kann. Der Server antwortet, nur beantwortet das nicht die Frage, ob deine Kunden ihn erreichen.

Klassisches Monitoring beantwortet „ist der Server oben?". Die eigentliche Frage bei DNS-Problemen lautet aber „stimmt der Weg zum Server noch?". Das sind zwei verschiedene Fragen, und die zweite braucht eine andere Art der Überwachung.

Wie man DNS aktiv überwacht

Die Lösung ist, das DNS nicht als selbstverständlich vorauszusetzen, sondern es selbst zum Prüfgegenstand zu machen. Statt nur zu fragen, ob der Server antwortet, prüft man zusätzlich zwei Dinge: ob die DNS-Auflösung überhaupt funktioniert, und ob sie den richtigen Wert liefert. Genau darauf zielt eine DNS-Überwachung.

Das Prinzip hat zwei Auslöser, die zusammen die oben beschriebenen Fälle abdecken. Der erste ist der Auflösungsfehler (resolveError): Das Monitoring versucht, die Domain aufzulösen, und schlägt Alarm, wenn keine gültige Antwort kommt: der Fall NXDOMAIN, abgelaufene Domain, kaputte Delegation. Der zweite ist die Abweichung (mismatch): Du hinterlegst, welchen Wert ein Record haben soll, etwa die korrekte IP im A-Record, und das Monitoring vergleicht die reale Auflösung gegen diesen Soll-Wert. Weicht der tatsächliche Record ab, wird alarmiert. Damit fängst du den versehentlich geänderten Record ebenso wie das Hijacking, denn beide erzeugen eine Abweichung vom erwarteten Wert.

In der Praxis legst du für die kritischen Record-Arten einen erwarteten Wert fest. Der A- und AAAA-Record bestimmen, auf welche IP die Domain zeigt, der Kern der Erreichbarkeit. Der MX-Record steuert die Mailzustellung; eine unbemerkte Änderung hier legt den E-Mail-Empfang lahm. TXT-Records wie SPF und DKIM sichern die E-Mail-Authentifizierung; werden sie manipuliert oder gelöscht, leidet die Zustellbarkeit oder es öffnet sich ein Einfallstor für Spoofing. Für jeden dieser Records lässt sich der Soll-Wert exakt oder als „muss enthalten" definieren, sodass das Monitoring genau weiß, was richtig ist.

Bei Uptimeify wird jede erkannte Abweichung, wie bei allen Checks, von mehreren EU-Standorten bestätigt, bevor ein Alarm ausgelöst wird. Das ist gerade bei DNS wichtig, weil einzelne Resolver kurzzeitig veraltete Antworten liefern können; erst die Bestätigung über mehrere Standorte macht aus einem möglichen Cache-Effekt einen belastbaren Alarm.

Warum das für Agenturen besonders zählt

Für eine Agentur ist ein DNS-Ausfall eine besonders unangenehme Art von Störung, aus drei Gründen. Erstens ist er selten genug, um überrascht zu werden: Server-Ausfälle hat man auf dem Schirm, DNS-Probleme treten Monate ohne Vorwarnung nicht auf und schlagen dann plötzlich zu. Zweitens ist er schwer zu diagnostizieren, wenn man nicht daran denkt: Man verliert wertvolle Zeit mit dem gesunden Server, während die eigentliche Ursache eine Ebene höher liegt. Und drittens ist er peinlich, weil er oft vermeidbar war: eine abgelaufene Domain oder ein vergessener Record wirft kein gutes Licht auf den Betreuer.

Genau hier liegt der Wert einer aktiven DNS-Überwachung über das rein Technische hinaus. Sie verschiebt die Position der Agentur von „wir erfahren vom DNS-Problem durch den wütenden Kunden" zu „wir sehen die Abweichung sofort und beheben sie, oft bevor der Kunde etwas merkt". Ein manipulierter oder falscher Record, der innerhalb von Minuten erkannt wird, ist ein beherrschbarer Vorfall; derselbe Record, der tagelang unbemerkt bleibt, ist ein Reputationsschaden, für deinen Kunden und für dich.

Für Agenturen, die die Erreichbarkeit ihrer Kundenseiten verantworten, gehört die DNS-Schicht deshalb genauso ins Monitoring wie der Server selbst. Sie ist der Teil des Weges, den niemand sieht, bis er bricht.

Den unsichtbaren Teil des Weges sichtbar machen

Der Kern dieses Themas ist eine Erweiterung des Blickfelds. Die meisten Monitoring-Strategien enden am Server, sie stellen sicher, dass die Maschine läuft und antwortet. Aber die Erreichbarkeit einer Seite hängt an einer Kette, die schon viel früher beginnt: bei der Domain, bei der Delegation, bei den Records, die den Namen in eine Adresse übersetzen. Solange dieser Teil funktioniert, ist er unsichtbar. Sobald er bricht, ist er die alleinige Ursache, und der gesündeste Server der Welt hilft dann nichts.

Eine aktive DNS-Überwachung macht diesen unsichtbaren Teil sichtbar. Sie beantwortet die Frage, die ein Server-Check nicht beantworten kann: Führt der Weg zum Server noch dorthin, wohin er soll? Indem sie die Auflösung prüft und die Records gegen einen Soll-Wert abgleicht, fängt sie genau die Ausfälle ab, die sonst durch jedes Raster fallen, die stillen, die teuren, die peinlichen.

Am Ende geht es um dieselbe Haltung wie beim gesamten Monitoring: den Ausfall vor dem Kunden zu kennen. Der Unterschied ist nur, dass die DNS-Schicht der eine Ort ist, an dem ein „laufender Server" trügt. Wer auch sie überwacht, schließt die letzte große Lücke zwischen „technisch läuft alles" und „meine Besucher kommen tatsächlich an".