![\"DNS-Aufl\u00f6sung](\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/07\/how-dotcom-monitor-resolves-dns.webp\")
<\/p>\n<\/p>\n
Jede Monitoring-\u00dcberpr\u00fcfung beginnt auf die gleiche Weise. Bevor ein einziges Byte Ihrer Startseite, API-Antwort oder SMTP-Banner zur\u00fcckkommt, muss der Monitoring-Agent einen Hostnamen in eine IP-Adresse umwandeln. Dieser erste Schritt ist die DNS-Aufl\u00f6sung, und wie Sie diese konfigurieren, beeinflusst, was Ihre Verf\u00fcgbarkeitszahlen tats\u00e4chlich bedeuten.<\/p>\n
Die meisten Teams ver\u00e4ndern nie die DNS-Einstellung eines Monitors. Sie richten eine \u00dcberpr\u00fcfung auf Dotcom-Monitor bietet Ihnen genau aus diesem Grund vier DNS-Aufl\u00f6sungsmodi. Dieser Leitfaden erkl\u00e4rt jeden einzelnen, mit besonderem Fokus auf die Wahl, die die meisten falsch machen: Caching versus Non-Caching versus tempor\u00e4res (TTL-basiertes) Caching.<\/p>\n DNS ist der erste Schritt bei nahezu jedem Protokoll, das Sie \u00fcberwachen. Eine Website-\u00dcberpr\u00fcfung, ein API-Monitoring<\/a>-Aufruf, eine E-Mail-Server-\u00dcberwachung<\/a>, ein ICMP-Ping-Monitoring<\/a>-Test \u2013 jede Pr\u00fcfung ben\u00f6tigt eine IP-Adresse, bevor sie eine Verbindung herstellen kann. Also l\u00f6st der Agent zuerst den Hostnamen auf und f\u00fchrt danach TCP, TLS und die Anwendungsschicht-Anfrage aus.<\/p>\n Diese Reihenfolge ist aus zwei Gr\u00fcnden wichtig. Erstens ist die DNS-Lookup-Zeit Teil Ihrer gesamten Antwortzeit, sodass ein langsamer Resolver jede Zahl ung\u00fcnstig beeinflusst. Zweitens stoppt ein DNS-Fehler die Pr\u00fcfung, noch bevor sie beginnt. Wenn die Aufl\u00f6sung fehlschl\u00e4gt, 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\u00e4chlich \u00fcberwachen wollten.<\/p>\n Da DNS allen anderen Schritten vorgelagert ist, ist die Art und Weise, wie ein Agent diese Aufl\u00f6sung durchf\u00fchrt, eine echte Designentscheidung und kein Detail. L\u00f6sen Sie bei jeder Anfrage frisch auf, erkennen Sie Resolver-Probleme schnell, erh\u00f6hen 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\u00f6glichen es Ihnen, den Kompromiss auszuw\u00e4hlen, der f\u00fcr das, was Sie tats\u00e4chlich \u00fcberwachen, am besten passt. F\u00fcr eine tiefere Betrachtung zur Verk\u00fcrzung dieses ersten Schritts siehe unseren Leitfaden zur Verbesserung der DNS-Aufl\u00f6sungszeit<\/a>.<\/p>\n Dotcom-Monitor bietet vier DNS-Aufl\u00f6sungsmodi f\u00fcr eine Monitoring-Aufgabe. Jeder \u00e4ndert, woher die IP-Adresse kommt und wie lange sie gespeichert wird.<\/p>\n Ger\u00e4te-Cache ist der Standardmodus. Innerhalb einer einzelnen Ger\u00e4te\u00fcberpr\u00fcfung l\u00f6st der Agent jeden Hostnamen einmal auf und teilt diese Antwort mit allen Aufgaben dieses Ger\u00e4ts im weiteren Verlauf des Laufs. Wenn eine fr\u00fchere Aufgabe in derselben Pr\u00fcfung den Host bereits aufgel\u00f6st hat, nutzt die sp\u00e4tere Aufgabe die zwischengespeicherte IP. Falls nicht, f\u00fchrt der Agent eine vollst\u00e4ndige Suche durch und cachet das Ergebnis f\u00fcr die Dauer der Pr\u00fcfung.<\/p>\n Der Vorteil ist Effizienz. Die meisten Pr\u00fcfungen dauern unter einer Minute, daher gibt es keinen Grund, denselben Host alle paar Sekunden erneut aufzul\u00f6sen. Die Besonderheit taucht bei der Zeitmessung pro Aufgabe auf. Wenn ein Ger\u00e4t zwei URLs desselben Hosts \u00fcberwacht, tr\u00e4gt die erste URL die DNS-Lookup-Zeit, die zweite nutzt die zwischengespeicherte IP, sodass die zweite schneller erscheint, obwohl sich nichts ge\u00e4ndert hat. Das ist erwartetes Verhalten, kein Fehler, \u00fcberrascht aber Benutzer, die zum ersten Mal ein Wasserfalldiagramm lesen.<\/p>\n Nicht zwischengespeichert \u00fcberspringt den Ger\u00e4tespeicher komplett. Jede Aufgaben-Ausf\u00fchrung f\u00fchrt eine vollst\u00e4ndige DNS-Aufl\u00f6sung durch, somit leiht sich kein Lauf eine Antwort vom vorherigen. Das liefert einheitliche, vergleichbare Zeiten, da jede Pr\u00fcfung die volle Aufl\u00f6sungskosten tr\u00e4gt.<\/p>\n Der Nachteil sind h\u00f6here Last und Latenz. Eine frische Aufl\u00f6sung bei jedem Lauf erh\u00f6ht die Zeit jeder Aufgabe und belastet die DNS-Infrastruktur st\u00e4rker. Non-Cached ist auch f\u00fcr die browserbasierten BrowserView- oder UserView-Plattformen nicht verf\u00fcgbar. Eine echte Seite l\u00e4dt dutzende Elemente vom selben Host, Hunderte Aufl\u00f6sungen in wenigen Sekunden entsprechen nicht dem Browserverhalten. Daher ist einmaliges Aufl\u00f6sen pro Lauf hier das realistische Modell.<\/p>\n TTL-Cache verh\u00e4lt sich wie ein echter Resolver auf einem Benutzerger\u00e4t. Er ber\u00fccksichtigt die Zeitdauer des Records (Time to Live, TTL): Der Agent speichert die aufgel\u00f6ste Adresse und nutzt sie, bis der TTL abl\u00e4uft, danach wird erneut \u00fcber den lokalen DNS-Server aufgel\u00f6st. Dieser Modus ahmt am genauesten das Benutzererlebnis nach, denn Browser und Betriebssystem cachen ebenso.<\/p>\n Das Risiko liegt im gleichen Verhalten. F\u00e4llt der DNS-Server, der den Record liefert, aus, w\u00e4hrend noch eine g\u00fcltige Antwort gecached ist, bemerkt der Monitor dies m\u00f6glicherweise erst, wenn der TTL abgelaufen ist \u2013 das kann Stunden, Tage oder l\u00e4nger dauern. Daher ist TTL Cached richtig, wenn Sie realistisches Benutzer-Experience-Timing wollen, aber falsch, wenn schnelle Erkennung eines DNS-Ausfalls wichtig ist.<\/p>\n Externer DNS-Server weist die Aufl\u00f6sung einem von Ihnen bestimmten Resolver-IP zu. Wenn Sie wissen, dass die meisten Nutzer hinter einem \u00f6ffentlichen Resolver wie Google (8.8.8.8, 8.8.4.4) oder Cloudflare (1.1.1.1) sitzen, k\u00f6nnen Sie genau \u00fcber diesen Dienst testen. Auch ist es m\u00f6glich, einen Resolver anzugeben, der f\u00fcr die Zone autoritativ ist, um den rekursiven Weg zu \u00fcberspringen und schnellere, direktere Antworten zu bekommen.<\/p>\n Der Nachteil ist die Begrenzung auf die Abdeckung. Solange Ihr gew\u00e4hlter Resolver eine g\u00fcltige Antwort gibt, meldet der Monitor Erfolg, auch wenn der eigentlich zust\u00e4ndige DNS-Server f\u00fcr 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.<\/p>\n Diese Entscheidung verwirrt viele, daher ist es sinnvoll, die drei Modi nebeneinander zu stellen. Caching (Ger\u00e4te-Cache) optimiert Effizienz. Nicht-Caching (Non-Cached) steht f\u00fcr vergleichbare, wiederholbare Zeiten und schnelle Fehlererkennung. Tempor\u00e4res Caching (TTL Cached) optimiert Realismus, indem es Records altersbedingt entfernt, wie es Browser tun.<\/p>\napi.example.com<\/code> ein, w\u00e4hlen ein Intervall und machen weiter. Aber das Resolver-Verhalten unterhalb dieser Pr\u00fcfung entscheidet, ob Sie die tats\u00e4chliche Benutzererfahrung messen, DNS-Ausf\u00e4lle innerhalb von Sekunden erkennen oder saubere Antwortzeiten erzeugen, die Sie in verschiedenen L\u00e4ufen vergleichen k\u00f6nnen. Sie k\u00f6nnen nicht alle drei Aspekte gleichzeitig optimieren.<\/p>\nWarum DNS-Aufl\u00f6sung in jeder Pr\u00fcfung zuerst stattfindet<\/h2>\n
![\"Lebenszyklus](\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/07\/dns-check-lifecycle.webp\")
Die vier DNS-Modi in Dotcom-Monitor<\/h2>\n
Ger\u00e4te-Cache (Device Cached)<\/h3>\n
Nicht zwischengespeichert (Non-Cached)<\/h3>\n
TTL-Cache (TTL Cached)<\/h3>\n
Externer DNS-Server (External DNS Server)<\/h3>\n
Caching vs Non-Caching vs Tempor\u00e4res Caching<\/h2>\n
\n