DNS-Fehler erkennen und beheben: Ursachen, Prüfung, TTL

Was ist DNS, und warum führt ein Fehler zum Ausfall?

Das Domain Name System (DNS) übersetzt lesbare Namen wie example.com in IP-Adressen und beantwortet weitere Fragen, etwa welcher Server die E-Mails der Domain annimmt. Seine Grundlagen sind in RFC 1034 und RFC 1035 beschrieben. Bevor ein Browser eine Verbindung aufbauen kann, braucht er die IP-Adresse. Fehlt sie oder ist sie falsch, scheitert alles Weitere: Der Webserver bekommt die Anfrage nie zu sehen, Ihre Server-Logs bleiben leer, und trotzdem ist die Website für Besucher verschwunden.

Das macht DNS-Probleme tückisch. Der klassische Satz „bei mir geht es“ stimmt oft sogar: Ihr Rechner hat die Adresse zwischengespeichert, die Besucher nicht. Im Monitoring ist die Namensauflösung deshalb die erste Phase jeder Messung (siehe Was ist Website-Monitoring?), und sie kann zusätzlich mit einem eigenen DNS-Monitor überwacht werden.

Wie läuft eine Namensauflösung ab?

1. Der Client fragt seinen rekursiven Resolver (beim Provider, im Unternehmen oder öffentlich).
2. Kennt der Resolver die Antwort nicht aus dem Zwischenspeicher, fragt er einen Root-Server, dann den Server der Top-Level-Domain (z. B. .de), der auf die Nameserver der Domain verweist (Delegation).
3. Der autoritative Nameserver der Domain liefert den eigentlichen Eintrag.
4. Der Resolver gibt die Antwort zurück und speichert sie so lange, wie die TTL es erlaubt.

An jeder dieser Stationen kann etwas schiefgehen. Die Fehlersuche folgt deshalb derselben Reihenfolge: erst die Delegation (stimmen die NS-Einträge bei der Domain-Registrierung?), dann der autoritative Server (liefert er den richtigen Wert?), dann die Resolver (halten sie einen alten Wert?).

Welche Fehlerbilder gibt es?

Besonders folgenreich ist die abgelaufene Domain. Verlängert der Registrar nicht rechtzeitig, schaltet er die Delegation ab oder parkt die Domain; die Website, die Mail und häufig auch Zertifikatsverlängerungen fallen gleichzeitig aus. Wer mehrere Domains betreut, sollte Ablaufdaten zentral führen. Rechtliche und vertragliche Fragen rund um Domainkündigungen klären Sie mit dem Registrar oder einer fachkundigen Stelle.

Wie prüfen Sie DNS mit dig?

dig ist das Standardwerkzeug. Es ist auf Linux und macOS meist vorhanden, unter Windows nutzen Sie nslookup oder die WSL. Die wichtigsten Aufrufe:

# A-Eintrag über den Standard-Resolver
dig example.com A +short

# Über einen bestimmten Resolver (lokalen vom globalen Zustand trennen)
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short

# Zuständige Nameserver ermitteln
dig example.com NS +short

# Den autoritativen Server direkt fragen (umgeht Resolver-Caches)
dig @ns1.beispiel-hoster.de example.com A +noall +answer

# Den Weg von der Wurzel bis zur Antwort verfolgen
dig example.com A +trace

# Weitere Typen: Mail, Text-Einträge, Zertifikatsrichtlinie
dig example.com MX +short
dig example.com TXT +short
dig example.com CAA +short

# DNSSEC-Validierung testen
dig example.com A +dnssec

Die Regel dahinter lautet: Liefert der autoritative Server den richtigen Wert, die Resolver aber nicht, liegt es am Cache oder an der Delegation. Liefert schon der autoritative Server Unsinn, liegt der Fehler in Ihrer Zone. In der Antwort von dig zeigt die Zahl vor IN die verbleibende TTL des Eintrags an.

Was bedeuten TTL und „Propagation“ wirklich?

Jeder DNS-Eintrag hat eine TTL (Time To Live) in Sekunden. Sie legt fest, wie lange ein Resolver die Antwort speichern darf. „Propagation“ ist dabei kein aktiver Verbreitungsvorgang, sondern das Auslaufen alter Zwischenspeicher. Ändern Sie einen Eintrag, sehen Besucher den neuen Wert, sobald ihr Resolver die alte Antwort verworfen hat – spätestens nach Ablauf der alten TTL, die bei der letzten Abfrage galt.

Die Faustregel: Senken Sie die TTL mindestens so lange vor dem Umzug, wie die alte TTL beträgt. Wie Sie den Wechsel zusätzlich überwachen, beschreibt Relaunch und Umzug überwachen.

Welche Einträge lohnt es sich zu überwachen?

Ein häufiger Fehler besteht darin, nur den A-Eintrag zu betrachten. MX-Fehler fallen oft erst auf, wenn ein Kunde sich über unbeantwortete Mails wundert.

Wie erkennen Sie DNS-Fehler automatisch?

Ein DNS-Monitor löst in festen Abständen einen Eintrag auf und vergleicht optional mit einem erwarteten Wert. Schlägt die Auflösung fehl oder weicht der Wert ab, gilt das als Fehlschlag. Das hat zwei Vorteile gegenüber dem reinen HTTP-Monitor: Er zeigt die Ursache (DNS statt Server) und er findet Änderungen, die der HTTP-Check nicht bemerkt, etwa wenn die IP-Adresse unbemerkt zu einem anderen, aber ebenfalls antwortenden Server wechselt. Eine zusätzliche Übersicht aller Prüfarten bietet die Seite Monitortypen.

Wie beheben Sie die häufigsten DNS-Probleme?

• Wenn NXDOMAIN für die Hauptdomain: Domain-Status beim Registrar prüfen (Ablauf, Sperre). Ist sie aktiv, NS-Einträge prüfen.
• Wenn NXDOMAIN nur für www: Fehlenden Eintrag ergänzen (A oder CNAME) oder per Weiterleitung lösen.
• Wenn SERVFAIL: Autoritative Server direkt abfragen; antworten sie, DNSSEC prüfen (dig +dnssec), und bei Verdacht den DS-Eintrag beim Registrar mit der Zone abgleichen.
• Wenn Timeout: Alle Nameserver einzeln testen, Firewall-Regeln für Port 53 (UDP und TCP) prüfen, Nameserver-Anbieter kontaktieren.
• Wenn alter Wert bei einigen Nutzern: TTL abwarten; bei eigenen Geräten den lokalen Cache leeren (resolvectl flush-caches unter Linux, ipconfig /flushdns unter Windows).
• Wenn nur IPv6-Nutzer betroffen: AAAA-Eintrag prüfen. Zeigt er auf einen Server, auf dem der Webserver kein IPv6 bedient, entsteht ein Teilausfall.

Für Nameserver gilt zusätzlich die Empfehlung, mindestens zwei Server an unterschiedlichen Standorten einzusetzen. Das ist keine Garantie, verringert aber das Risiko, dass ein einzelner Ausfall die Domain unerreichbar macht.

Welche häufigen Fehler führen zu DNS-Ausfällen?

Checkliste: DNS im Blick behalten

1. Ablaufdatum der Domain notiert und Auto-Verlängerung geprüft?
2. Mindestens zwei Nameserver, bei Registrar und in der Zone identisch?
3. A-, AAAA-, MX- und NS-Einträge dokumentiert, mit erwarteten Werten?
4. DNS-Monitor für den A-Eintrag der Hauptdomain, bei Bedarf für MX und www.
5. Vor Umzügen: TTL gesenkt, Wartungsfenster geplant, Rückfallplan vorhanden.
6. Nach Änderungen: autoritativ und über zwei öffentliche Resolver verglichen.
7. SPF/DMARC und CAA nach Provider-Wechsel erneut geprüft.
8. DNSSEC nur aktiv, wenn der DS-Eintrag nachweislich zur Zone passt.

Grenzen und Einordnung

Ein DNS-Monitor fragt aus Sicht des Messstandorts und seines Resolvers. Andere Resolver können wegen unterschiedlich abgelaufener TTL noch einen anderen Wert liefern; auch regionale Unterschiede (Geo-DNS, CDN) lassen sich nicht vollständig abbilden. Ohne zusätzlich eingerichtete Messstandorte beobachtet nur der Hauptstandort. Ein erfolgreicher DNS-Check sagt zudem nichts darüber, ob der Webserver antwortet; kombinieren Sie ihn mit einem HTTP-Monitor. Und er prüft nicht die inhaltliche Richtigkeit Ihrer gesamten Zone: Ob SPF-Syntax oder DMARC-Richtlinie sinnvoll sind, bewertet er nicht.

Schließlich hilft DNS-Überwachung nicht bei Problemen auf der Registrar-Seite, die außerhalb des DNS liegen (Kontoverifizierung, Zahlungsprobleme). Dort zählen Fristen und Kontaktpflege. Eine allgemeine Einordnung bietet Grenzen automatischer Website-Prüfungen.

Wie setzen Sie das mit UPTIMESHIELD um?

Der DNS-Monitor löst den gewählten Eintrag (zum Beispiel A, AAAA, CNAME, MX, NS oder TXT) auf und vergleicht ihn bei Bedarf mit dem von Ihnen hinterlegten Wert. Abweichungen und Auflösungsfehler zählen als Fehlschlag und lösen nach der eingestellten Zahl aufeinanderfolgender Fehlschläge (Standard 2) Alarm über Ihre Benachrichtigungskanäle aus. Empfehlenswert ist die Kombination aus HTTP-Monitor, DNS-Monitor und SSL-Überwachung: So sehen Sie, ob Auflösung, Zertifikat oder Server die Ursache sind.

Für einen ersten Überblick ohne Konto prüft die Sofortprüfung im Uptime Checker unter anderem A, AAAA, MX, NS, SPF, DMARC, CAA und DNSSEC und fasst sie im Teilscore „DNS & E-Mail“ zusammen. Details zur Auswertung stehen in der Messmethodik.