DNS-Monitoring: Warum ein grüner Uptime-Check nichts beweist

Brandon Lee hat auf virtualizationhowto.com einen Artikel mit dem Titel "I Thought My DNS Was Fine Until I Started Monitoring This" veröffentlicht. Seine Beobachtung: Ein DNS-Server kann online sein, auf Port 53 lauschen und trotzdem rekursive Abfragen scheitern lassen. Wir haben das zum Anlass genommen, unsere eigenen Resolver nachzurechnen. Das Ergebnis war unangenehm genug, um es aufzuschreiben. Danke für den Anstoß, Brandon.

Der blinde Fleck

Unser Monitoring prüfte, was die meisten prüfen: Ist Port 53 erreichbar, antwortet die Weboberfläche des Resolvers — bei uns Technitium. Beides stand seit Monaten auf Grün.

Beide Prüfungen beantworten aber nicht die Frage, auf die es ankommt. Ein Resolver, der jede Anfrage mit SERVFAIL zurückweist, ist erreichbar. Er antwortet sogar schnell. Er löst nur nichts mehr auf. Wer nur die Erreichbarkeit misst, misst am Problem vorbei — dazu haben wir an anderer Stelle schon geschrieben, als es um Uptime Kuma ging: Erreichbarkeit ist nicht Gesundheit.

Was die Auswertung ergab

Zwei unserer internen Resolver hatten in dreißig Tagen keinen einzigen fehlerfreien Tag. Rund 20.000 SERVFAIL-Antworten je Server und Monat, zwischen 0,1 und 1,1 Prozent des Tagesvolumens. Nie null.

Interessanter als die Summe war die Verteilung. Ein typischer Tag: stundenlang null, dann 142 Fehler in einer Stunde, danach 152, dann wieder stundenlang null, mittags ein Ausschlag auf 121, abends noch einmal 38. Transiente Ausschläge, die sich von selbst erholen — exakt das Muster, das ein Intervall-Check mit fünf Minuten Abstand mit hoher Wahrscheinlichkeit verpasst.

Der dritte Resolver war im Alltag unauffällig: acht Fehler in 24 Stunden bei knapp 58.000 Anfragen. Im Monatsrückblick stand dort allerdings ein Tag mit 56.341 SERVFAIL-Antworten auf 102.375 Anfragen — 55 Prozent. Angebahnt hatte er sich über zwei Tage, von 0,9 auf 2,9 auf 55 Prozent. Das Anfragevolumen lag an diesem Tag beim Zweieinhalbfachen des Normalwerts, weil Clients gescheiterte Abfragen wiederholen. Danach war der Server wieder sauber.

Es hat niemand bemerkt. Es hat auch nichts gemeldet. Gefunden haben wir es vier Wochen später beim Nachrechnen.

Die Ursache lag außerhalb

Der spannende Teil kam bei der Zuordnung. Über den Query-Log liest man nicht nur, wie viele Anfragen scheitern, sondern welche. Rund 95 Prozent aller SERVFAIL-Antworten entfielen auf drei Hostnamen einer einzigen fremden Domain — ein Telemetrie-Endpunkt einer Drittanbieter-Software, dessen autoritative Nameserver schlicht nicht mehr antworten.

Wir haben gegengeprüft, bevor wir am eigenen Server gesucht haben:

Derselbe Name scheitert identisch über drei unabhängige öffentliche Resolver.
Er scheitert auch mit abgeschalteter DNSSEC-Validierung.
Die Nameserver der zuständigen Top-Level-Domain laufen bei der Delegationsabfrage in einen Timeout.
Eine Kontrollabfrage auf einen gesunden Namen lieferte über denselben Pfad NoError in 3,62 Millisekunden.

Damit war klar: Am Resolver ist nichts kaputt. Er meldet korrekt, dass er für diesen Namen keine gültige Antwort beschaffen kann.

SERVFAIL ist meist nicht der Fehler des eigenen Servers

Das ist der Punkt, an dem viele Fehlersuchen in die falsche Richtung laufen. SERVFAIL heißt nicht "mein Server ist defekt", sondern "ich konnte keine gültige Antwort beschaffen". Die üblichen Ursachen liegen woanders: tote autoritative Nameserver, fehlgeschlagene DNSSEC-Validierung, Zeitüberschreitungen beim Upstream.

Trotzdem ist die Rate eine Kennzahl, die man führen sollte — nicht weil jeder Fehler behebbar ist, sondern weil die Form der Kurve etwas aussagt. Ein flacher Bodensatz aus kaputten Fremddomains ist Rauschen. Ein Sprung von einem auf fünfzig Prozent ist ein Vorfall. Den Unterschied sieht man nur, wenn man den Bodensatz kennt.

Ein Nebeneffekt, der uns in der Auswertung geholfen hat: Wenn zwei Resolver mit deutlich unterschiedlichem Anfragevolumen an denselben Tagen praktisch identische Fehlerzahlen liefern, ist die Ursache nicht Last und nicht der einzelne Server. Dann scheitern schlicht auf beiden dieselben Namen.

Was wir daraus gemacht haben

Drei Prüfungen, im Kern die Ebenen aus Brandons Artikel:

Erreichbarkeit — Port 53 per TCP, wie gehabt.
Anwendung — antwortet die Verwaltungsoberfläche des Resolvers.
Funktion — eine echte rekursive Auflösung gegen externe Namen, ausgewertet auf RCODE, nicht nur auf "hat geantwortet".

Dazu die SERVFAIL-Rate als eigene Kennzahl mit Schwellwert auf die Abweichung vom Normalpegel, statt auf einen absoluten Wert. Und ein Query-Log mit ausreichender Aufbewahrung: Ohne ihn lässt sich im Nachhinein nicht mehr klären, welche Namen gescheitert sind. Auf dem Server mit dem 55-Prozent-Tag fehlte genau das — dieser Vorfall bleibt deshalb unaufgeklärt.

Eine praktische Warnung zum Schluss: Prüfen Sie mit einzelnen Abfragen in ruhigem Takt. Wer zur Diagnose eine Schleife über Dutzende Namen laufen lässt, löst je nach Firewall den Flood-Schutz aus und misst danach dessen Auswirkungen statt der eigenen DNS-Gesundheit. Das kostet zuverlässig einen Abend.

Fazit

Unsere Resolver waren die ganze Zeit erreichbar. Das war nie die Frage. Die Frage war, ob sie noch auflösen — und die hat monatelang niemand gestellt, weil das Dashboard grün war.

Der Aufwand für die dritte Prüfebene liegt bei einer Handvoll Zeilen. Der Unterschied ist, dass ein Ausfall dann auffällt, während er passiert, und nicht vier Wochen später in einer Monatsstatistik.

Weiterführende Quellen

FAQ

Warum reicht ein Port-53-Check nicht aus, um einen DNS-Server zu überwachen?+

Weil er nur beweist, dass jemand auf dem Port antwortet — nicht, dass die Antwort brauchbar ist. Ein Resolver kann jede Anfrage in Millisekunden mit SERVFAIL quittieren und dabei durchgehend als erreichbar gelten. Erst eine echte rekursive Auflösung gegen einen externen Namen zeigt, ob der Dienst seine eigentliche Aufgabe noch erfüllt.

Ist eine SERVFAIL-Rate von unter einem Prozent ein Problem?+

Nicht zwangsläufig. Ein kleiner Bodensatz ist normal: kaputte Fremddomains, abgelaufene DNSSEC-Signaturen, Tippfehler in Clients. Entscheidend ist nicht der Absolutwert, sondern die Form der Kurve. Ein konstanter Bodensatz ist Rauschen — ein Ausschlag von einem Prozent auf fünfzig ist ein Vorfall, und genau den sehen Sie ohne Auswertung nicht.

Was bedeutet SERVFAIL überhaupt?+

Der Resolver teilt mit, dass er keine gültige Antwort beschaffen konnte. Die Ursache liegt meist außerhalb: tote autoritative Nameserver der Zieldomain, eine fehlgeschlagene DNSSEC-Validierung oder Zeitüberschreitungen nach oben. SERVFAIL ist damit selten ein Defekt des eigenen Servers — aber immer ein Signal, dem man nachgehen sollte.