Jede Monitoring-Überprüfung beginnt auf die gleiche Weise. Bevor ein einziges Byte Ihrer Startseite, API-Antwort oder SMTP-Banner zurückkommt, muss der Monitoring-Agent einen Hostnamen in eine IP-Adresse umwandeln. Dieser erste Schritt ist die DNS-Auflösung, und wie Sie diese konfigurieren, beeinflusst, was Ihre Verfügbarkeitszahlen tatsächlich bedeuten.
Die meisten Teams verändern nie die DNS-Einstellung eines Monitors. Sie richten eine Überprüfung auf api.example.com ein, wählen ein Intervall und machen weiter. Aber das Resolver-Verhalten unterhalb dieser Prüfung entscheidet, ob Sie die tatsächliche Benutzererfahrung messen, DNS-Ausfälle innerhalb von Sekunden erkennen oder saubere Antwortzeiten erzeugen, die Sie in verschiedenen Läufen vergleichen können. Sie können nicht alle drei Aspekte gleichzeitig optimieren.
Dotcom-Monitor bietet Ihnen genau aus diesem Grund vier DNS-Auflösungsmodi. Dieser Leitfaden erklärt jeden einzelnen, mit besonderem Fokus auf die Wahl, die die meisten falsch machen: Caching versus Non-Caching versus temporäres (TTL-basiertes) Caching.
Warum DNS-Auflösung in jeder Prüfung zuerst stattfindet
DNS ist der erste Schritt bei nahezu jedem Protokoll, das Sie überwachen. Eine Website-Überprüfung, ein API-Monitoring-Aufruf, eine E-Mail-Server-Überwachung, ein ICMP-Ping-Monitoring-Test – jede Prüfung benötigt eine IP-Adresse, bevor sie eine Verbindung herstellen kann. Also löst der Agent zuerst den Hostnamen auf und führt danach TCP, TLS und die Anwendungsschicht-Anfrage aus.
Diese Reihenfolge ist aus zwei Gründen wichtig. Erstens ist die DNS-Lookup-Zeit Teil Ihrer gesamten Antwortzeit, sodass ein langsamer Resolver jede Zahl ungünstig beeinflusst. Zweitens stoppt ein DNS-Fehler die Prüfung, noch bevor sie beginnt. Wenn die Auflösung fehlschlägt, gibt es keine Verbindung zum Testen, kein Zertifikat zur Validierung und keinen Statuscode zum Lesen. Der Monitor meldet einen harten Fehler, wobei die Ursache eine Schicht unterhalb dessen liegt, was Sie tatsächlich überwachen wollten.
Da DNS allen anderen Schritten vorgelagert ist, ist die Art und Weise, wie ein Agent diese Auflösung durchführt, eine echte Designentscheidung und kein Detail. Lösen Sie bei jeder Anfrage frisch auf, erkennen Sie Resolver-Probleme schnell, erhöhen aber die Last und Lookup-Zeit pro Lauf. Cachen Sie, werden die Werte schneller und stabiler, aber ein fehlerhafter DNS-Eintrag kann stundenlang hinter dem Cache verborgen bleiben. Die Modi von Dotcom-Monitor ermöglichen es Ihnen, den Kompromiss auszuwählen, der für das, was Sie tatsächlich überwachen, am besten passt. Für eine tiefere Betrachtung zur Verkürzung dieses ersten Schritts siehe unseren Leitfaden zur Verbesserung der DNS-Auflösungszeit.
Die vier DNS-Modi in Dotcom-Monitor
Dotcom-Monitor bietet vier DNS-Auflösungsmodi für eine Monitoring-Aufgabe. Jeder ändert, woher die IP-Adresse kommt und wie lange sie gespeichert wird.
Geräte-Cache (Device Cached)
Geräte-Cache ist der Standardmodus. Innerhalb einer einzelnen Geräteüberprüfung löst der Agent jeden Hostnamen einmal auf und teilt diese Antwort mit allen Aufgaben dieses Geräts im weiteren Verlauf des Laufs. Wenn eine frühere Aufgabe in derselben Prüfung den Host bereits aufgelöst hat, nutzt die spätere Aufgabe die zwischengespeicherte IP. Falls nicht, führt der Agent eine vollständige Suche durch und cachet das Ergebnis für die Dauer der Prüfung.
Der Vorteil ist Effizienz. Die meisten Prüfungen dauern unter einer Minute, daher gibt es keinen Grund, denselben Host alle paar Sekunden erneut aufzulösen. Die Besonderheit taucht bei der Zeitmessung pro Aufgabe auf. Wenn ein Gerät zwei URLs desselben Hosts überwacht, trägt die erste URL die DNS-Lookup-Zeit, die zweite nutzt die zwischengespeicherte IP, sodass die zweite schneller erscheint, obwohl sich nichts geändert hat. Das ist erwartetes Verhalten, kein Fehler, überrascht aber Benutzer, die zum ersten Mal ein Wasserfalldiagramm lesen.
Nicht zwischengespeichert (Non-Cached)
Nicht zwischengespeichert überspringt den Gerätespeicher komplett. Jede Aufgaben-Ausführung führt eine vollständige DNS-Auflösung durch, somit leiht sich kein Lauf eine Antwort vom vorherigen. Das liefert einheitliche, vergleichbare Zeiten, da jede Prüfung die volle Auflösungskosten trägt.
Der Nachteil sind höhere Last und Latenz. Eine frische Auflösung bei jedem Lauf erhöht die Zeit jeder Aufgabe und belastet die DNS-Infrastruktur stärker. Non-Cached ist auch für die browserbasierten BrowserView- oder UserView-Plattformen nicht verfügbar. Eine echte Seite lädt dutzende Elemente vom selben Host, Hunderte Auflösungen in wenigen Sekunden entsprechen nicht dem Browserverhalten. Daher ist einmaliges Auflösen pro Lauf hier das realistische Modell.
TTL-Cache (TTL Cached)
TTL-Cache verhält sich wie ein echter Resolver auf einem Benutzergerät. Er berücksichtigt die Zeitdauer des Records (Time to Live, TTL): Der Agent speichert die aufgelöste Adresse und nutzt sie, bis der TTL abläuft, danach wird erneut über den lokalen DNS-Server aufgelöst. Dieser Modus ahmt am genauesten das Benutzererlebnis nach, denn Browser und Betriebssystem cachen ebenso.
Das Risiko liegt im gleichen Verhalten. Fällt der DNS-Server, der den Record liefert, aus, während noch eine gültige Antwort gecached ist, bemerkt der Monitor dies möglicherweise erst, wenn der TTL abgelaufen ist – das kann Stunden, Tage oder länger dauern. Daher ist TTL Cached richtig, wenn Sie realistisches Benutzer-Experience-Timing wollen, aber falsch, wenn schnelle Erkennung eines DNS-Ausfalls wichtig ist.
Externer DNS-Server (External DNS Server)
Externer DNS-Server weist die Auflösung einem von Ihnen bestimmten Resolver-IP zu. Wenn Sie wissen, dass die meisten Nutzer hinter einem öffentlichen Resolver wie Google (8.8.8.8, 8.8.4.4) oder Cloudflare (1.1.1.1) sitzen, können Sie genau über diesen Dienst testen. Auch ist es möglich, einen Resolver anzugeben, der für die Zone autoritativ ist, um den rekursiven Weg zu überspringen und schnellere, direktere Antworten zu bekommen.
Der Nachteil ist die Begrenzung auf die Abdeckung. Solange Ihr gewählter Resolver eine gültige Antwort gibt, meldet der Monitor Erfolg, auch wenn der eigentlich zuständige DNS-Server für die Domain Fehlverhalten zeigt. Dieser Modus testet also nur die Sicht eines resolvers, nicht die gesamte Kette. Ein weiterer wichtiger Punkt: Jede einzelne Resolver-IP besitzt ihren eigenen Cache, sodass zwei Aufgaben, die auf unterschiedliche externe Server zeigen, getrennte Caches nutzen.
Caching vs Non-Caching vs Temporäres Caching
Diese Entscheidung verwirrt viele, daher ist es sinnvoll, die drei Modi nebeneinander zu stellen. Caching (Geräte-Cache) optimiert Effizienz. Nicht-Caching (Non-Cached) steht für vergleichbare, wiederholbare Zeiten und schnelle Fehlererkennung. Temporäres Caching (TTL Cached) optimiert Realismus, indem es Records altersbedingt entfernt, wie es Browser tun.
| Modus | Wie es auflöst | Am besten für | Hauptkompromiss |
|---|---|---|---|
| Geräte-Cache (Caching) | Einmal pro Geräteprüfung, gemeinsam genutzt für alle Aufgaben | Effiziente Prüfungen; mehrere Aufgaben an einem Host | Erste Aufgabe trägt Lookup-Zeit; spätere Aufgaben erscheinen schneller |
| Nicht zwischengespeichert (Non-Caching) | Frische vollständige Auflösung bei jeder Ausführung | Einheitliche Zeitmessung; schnelle Erkennung von DNS-Problemen | Höhere DNS-Last und Latenz; nicht für BrowserView/UserView geeignet |
| TTL-Cache (temporäres Caching) | Berücksichtigt TTL des Records, dann erneute Auflösung | Realistisches Benutzererlebnis | Ein ausgefallener DNS-Server kann bis zum Ablauf des TTL verborgen bleiben |
| Externer DNS-Server | Fragt eine von Ihnen angegebene Resolver-IP ab | Test eines spezifischen öffentlichen oder autoritativen Resolvers | Sieht nur die Antwort dieses Resolvers, nicht die gesamte Kette |
Kurz gesagt: Cache für Geschwindigkeit, überspringe den Cache, um Ausfälle schnell zu erkennen, respektiere TTL, um das zu sehen, was Benutzer sehen. Wählen Sie den Modus, der dem Zweck der Prüfung entspricht.
Warum die meisten Monitoring-Tools DNS-Probleme übersehen
Der Grund, warum sich die Einstellung lohnt: Die meisten Monitoring-Tools bieten diese Wahl nicht. Sie lösen einen Hostnamen einmal auf, cachen ihn und verwenden die Antwort so lange, wie sie gültig ist. Das funktioniert, bis ein DNS-Problem in der Produktion auftritt – ein fehlerhafter Record, ein autoritativer Server fällt aus, ein Resolver gibt falsche IP zurück – denn ein gecachter Monitor meldet weiterhin Erfolg gegen eine veraltete Antwort, während reale Nutzer einen Ausfall erleben.
Granulare Kontrolle über den Auflösungsmodus ist im Monitoring selten. Fresh-Lookup bei jeder Prüfung, Ablaufen von Records nach TTL oder Zielsetzung auf einen bestimmten Resolver ist beinahe ein Markenzeichen von Dotcom-Monitor und unterscheidet zwischen einem Monitor, der DNS als gegeben annimmt, und einem, der es tatsächlich testet. Wenn das Ziel der Überprüfung ist, Produktions-DNS-Probleme zu erkennen, versteckt das Standard-Verhalten, alles zu cachen, genau diese Probleme.
Wie man den richtigen DNS-Modus wählt
Der benötigte Modus hängt von der Frage ab, die der Monitor beantwortet. Hier sind typische Muster für DevOps- und SRE-Teams.
Sie wollen DNS-Ausfälle so schnell wie möglich erfassen. Verwenden Sie Non-Cached. Wenn eine Prüfung existiert, um Sie sofort zu alarmieren, wenn die Auflösung fehlschlägt – etwa eine fehlgeschlagene Registrar-Änderung, eine abgelaufene Zone, ein gehackter Record – möchten Sie keine veraltete Antwort im Cache. Frische Auflösung bei jedem Lauf bedeutet, dass der Fehler beim nächsten Check auftaucht, nicht erst nach einer mehrstündigen TTL. Kombinieren Sie dies mit strenger Alarmierung, damit die Meldung jemanden im Bereitschaftsdienst erreicht.
Sie wollen Zeiten, die einem echten Besucher entsprechen. Verwenden Sie TTL Cached. Wenn die Prüfung ein Verfügbarkeits-SLA sichert oder ein Dashboard zur Benutzererfahrung speist, sorgt die browserähnliche Auflösung für korrekte Zahlen. Akzeptieren Sie dabei, dass die DNS-Fehlererkennung um bis zu eine TTL verzögert ist und überlegen Sie, ob ein separater Non-Cached-Check zusätzlich nötig ist.
Sie führen mehrere Aufgaben gegen denselben Host aus. Device Cached ist normalerweise richtig. Es hält die DNS-Last im Rahmen und löst den Host einmal pro Lauf auf. Lesen Sie Wasserfalldiagramme pro Aufgabe mit Caching im Hinterkopf: Die erste Aufgabe trägt die Lookup-Zeit.
Sie interessieren sich für einen bestimmten Resolver. Verwenden Sie External DNS Server. Dies passt für Teams, die prüfen, ob Googles oder Cloudflares öffentliche Resolver den korrekten Record zurückliefern, oder die einen autoritativen Server direkt testen wollen. Es ist ein gezielter Test, daher sollten Sie begleitend eine breitere Prüfung laufen lassen. Für die gesamte Strategie sollten Sie auch unseren Überblick zu DNS-Monitoring-Tools lesen.
Welche DNS-Fehler jeder Modus erkennt
DNS ist ein häufiger Fehlerpunkt und versagt auf verschiedene Weise. Records werden bei Migrationen geändert. Eine Zone läuft ab. Ein autoritativer Server fällt aus. Im schlimmsten Fall vergiftet ein Angreifer den Cache, um Ihre Domain auf einen Server umzuleiten, den er kontrolliert. Ihr Auflösungsmodus entscheidet, wie schnell diese Probleme auffallen.
Non-Cached ist am schnellsten bei der Aufdeckung von Auflösungsproblemen, weil keine vorherige Antwort vertraut wird. TTL Cached ist am langsamsten, da eine gültige gecachte Antwort länger bestehen kann als der dazugehörige Fehler. External DNS Server erkennt Probleme mit dem gewählten Resolver, aber kann Fehler an anderen Stellen verpassen. Für eine Gesamtübersicht, wie eine Prüfung über Schichten hinweg ausfällt, bietet unser Leitfaden zu DNS-, TCP-, TLS- und HTTP-Fehlern eine gute Karte. Und bei Ausfallangst passt das Playbook, wie man DNS-Ausfälle vermeidet, ideal zu Non-Cached-Checks.
Welchen Modus Sie auch wählen: Der Sinn des DNS-Monitorings ist, der Erste zu sein, der bemerkt, wenn ein Record sich unautorisiert ändert. Dotcom-Monitor generiert einen Fehler und löst einen Alarm aus, wenn ein Hostname auf eine unerwartete IP aufgelöst wird, sodass Sie reagieren können, bevor Nutzer auf dem falschen Server landen.
Wie man den DNS-Modus in Dotcom-Monitor einstellt
Das Ändern des Auflösungsmodus erfordert nur wenige Klicks bei der Konfiguration des Monitoring-Auftrags. Die genauen Bezeichnungen variieren leicht je nach Gerätetyp, der Ablauf ist aber derselbe.
- Schritt 1: Öffnen Sie das Gerät oder die Aufgabe, die Sie in der Dotcom-Monitor-Plattform konfigurieren möchten.
- Schritt 2: Bearbeiten Sie die Aufgabe und suchen Sie den Abschnitt DNS Resolve Mode (oder DNS Optionen).
- Schritt 3: Wählen Sie einen der vier Modi: Geräte-Cache, Nicht zwischengespeichert, TTL-Cache oder Externer DNS-Server.
- Schritt 4: Wenn Sie Externer DNS-Server gewählt haben, geben Sie die Resolver-IP-Adresse ein, beispielsweise 8.8.8.8 oder 1.1.1.1.
- Schritt 5: Speichern Sie die Aufgabe und lassen Sie sie einige Intervalle laufen. Prüfen Sie anschließend die Antwortzeitaufteilung, um sicherzustellen, dass die DNS-Zeiten Ihren Erwartungen entsprechen.
Da jedes Gerät aus Dotcom-Monitors globalem Monitoring-Netzwerk arbeitet, können Sie nach dem Setzen des Modus vergleichen, wie sich die Auflösung an verschiedenen Standorten verhält.
Das Fazit
Die DNS-Auflösung ist der erste Schritt jeder Prüfung, daher sollte der Auflösungsmodus nicht auf Autopilot bleiben. Cachen Sie für effiziente Prüfungen gegen einen gemeinsamen Host. Überspringen Sie den Cache, wenn schnelle Erkennung eines DNS-Fehlers Pflicht ist. Berücksichtigen Sie die TTL, wenn Sie Timing wollen, das einem echten Nutzer entspricht. Und verwenden Sie einen externen Resolver, wenn Sie die Sicht eines bestimmten Dienstes prüfen müssen.
Meistens verwenden Teams mehrere Modi in ihren Prüfungen, da ein einzelner Monitor selten alle Fragen beantwortet. Wählen Sie den Modus passend zum Zweck der Prüfung, und Ihre Zahlen zeigen Ihnen die Wahrheit über DNS.
Beobachten Sie DNS, bevor es Ihre Verfügbarkeit beeinträchtigt
Setzen Sie für jede Prüfung den passenden Auflösungsmodus und erhalten Sie sofort eine Benachrichtigung, wenn sich ein Record ändert. Dotcom-Monitor führt DNS-Monitoring über ein globales Netzwerk mit der hier erklärten Cache-Kontrolle durch.
