Einen geplanten DNS-Health-Check einrichten

Ein einmaliger DNS-Lookup zeigt den aktuellen Zustand. Ein geplanter, wiederkehrender Lookup zeigt, ob sich dieser Zustand verändert – und eine Änderung bei einer Domain, die Sie nicht aktiv ändern wollen, ist meist genau das, was man schnell erfahren möchte, statt es erst Wochen später zu entdecken.

Entscheiden, was einbezogen wird

Beginnen Sie mit allem, bei dem eine unbemerkte Änderung wirklich zählen würde: Produktionsdomains und ihre wichtigen Subdomains, Domains mit Bezug zur E-Mail-Zustellbarkeit und alles auf einer Sicherheits-Watchlist. Eine Prüfung für eine Domain einzuplanen, bei deren Änderung niemand reagieren würde, bringt wenig – das Ziel ist ein Signal, auf das Sie tatsächlich reagieren, kein umfassendes Protokoll, das niemand liest.

Das richtige Intervall wählen

Was mit den Ergebnissen geschieht

Der Job selbst ist nur die halbe Wertschöpfung – die andere Hälfte ist, was passiert, wenn sich die Ergebnisse eines Laufs von denen des vorherigen unterscheiden. Bewahren Sie mindestens so viel Verlauf auf, dass sich aufeinanderfolgende Läufe vergleichen lassen (dieses Tool speichert den Verlauf der Job-Läufe genau deshalb für ein konfigurierbares Aufbewahrungsfenster). Das Exportieren der Ergebnisse jedes Laufs als CSV oder JSON macht den programmatischen Vergleich unkompliziert, statt darauf zu setzen, dass jemand eine Änderung per Augenschein in einem Dashboard bemerkt, das er an diesem Tag vielleicht gar nicht öffnet.

Sobald ein Zeitplan zuverlässig läuft, wird DNS-Monitoring von einer gelegentlichen manuellen Aufgabe zu einem Hintergrundprozess, der nur dann Aufmerksamkeit verlangt, wenn es tatsächlich etwas anzusehen gibt – und genau das ist der Sinn.

Den Alarm gestalten, nicht nur die Prüfung

Eine geplante Prüfung, die bei jedem einzelnen Lauf benachrichtigt – auch bei Läufen ohne neue Erkenntnisse –, bringt Menschen binnen weniger Wochen dazu, sie zu ignorieren, und verfehlt damit ihren gesamten Zweck. Das nützliche Signal ist die Änderung selbst: Die aufgelösten Adressen dieses Laufs weichen vom letzten ab, eine Domain wechselte vom Auflösen zum Fehlschlagen (oder umgekehrt), oder eine neue Adresse liegt in einem Bereich, der überhaupt nicht erreichbar sein sollte. Wird die Benachrichtigung um „Was hat sich seit dem letzten Mal geändert“ statt um „Hier ist das heutige Ergebnis“ herum gebaut, lohnt es sich auch Monate später noch, den Alarm zu öffnen, statt dass er zu einer weiteren ungelesenen Markierung im Posteingang wird.

Was passiert, wenn die Prüfung selbst fehlschlägt

Ein geplanter Job braucht einen Plan für sein eigenes Scheitern, nicht nur für das, was er findet. Kann der Job gar nicht laufen – eine Warteschlange staut sich, ein Worker-Prozess stürzt ab, die zugrunde liegende Infrastruktur fällt aus –, ist das ein eigenständiges, höher priorisiertes Signal als das Ergebnis einer einzelnen Domain, weil das Sicherheitsnetz selbst verstummt ist, ohne dass es zwingend jemand merkt. Eine einfache, getrennte Prüfung „Lief der Job im erwarteten Zeitfenster überhaupt?“, die alarmiert, sobald ein Lauf überfällig ist, schließt diese Lücke; andernfalls ist ein Monitoring-System, das stillschweigend aufhört zu überwachen, wohl schlimmer als gar kein Monitoring, weil es die trügerische Sicherheit erzeugt, es werde weiterhin alles beobachtet.