Anmelden

DNS

Lektion 5 von 6

DNS-Fehleranalyse

Grenze typische Fehler der Namensauflösung systematisch ein.

Lernziele

Nach Abschluss dieser Lektion kannst du:

  • DNS- von allgemeinen Netzwerkfehlern unterscheiden
  • Resolverkonfiguration und DNS-Records gezielt prüfen
  • NXDOMAIN, SERVFAIL, Timeout und leere Antworten unterscheiden
  • falsche oder alte Daten anhand Cache und TTL untersuchen
  • rekursive von autoritativen Problemen trennen
  • Forward-/Reverse-Abweichungen erkennen
  • nslookup und optional dig sinnvoll einsetzen

Erst Belege sammeln, dann verändern

  1. 1. Ist grundlegende IP-Konnektivität vorhanden?
  2. 2. Welcher DNS-Resolver ist konfiguriert?
  3. 3. Ist dieser Resolver erreichbar?
  4. 4. Liefert die gezielte Abfrage eine Antwort?
  5. 5. Ist der zurückgegebene Record korrekt?
  6. 6. Antwortet ein anderer Resolver anders?
  7. 7. Können Cache und TTL alte Daten erklären?
  8. 8. Stimmen autoritative Zone und Record?
  9. 9. Ist die Delegation korrekt?
  10. 10. Sind Forward und Reverse dort konsistent, wo es benötigt wird?

Beginne nicht mit zufälligem Cache-Leeren. Jeder Schritt soll eine Hypothese prüfen.

IP funktioniert, Name nicht

Die Anwendung erreicht 192.168.10.20, aber nicht server.firma.test. Das ist starke Evidenz für eine Untersuchung der Namensauflösung, beweist aber nicht, dass DNS die einzig mögliche Ursache ist: Anwendungen können Namen und Dienste zusätzlich anders behandeln.

Antworttypen unterscheiden

NXDOMAIN

Eine gültige DNS-Antwort: Der abgefragte Name existiert im Antwortkontext nicht.

SERVFAIL

Resolver/Server konnte die Anfrage nicht erfolgreich abschließen, etwa wegen Upstream-, Autoritäts-, Delegations-, Server- oder in realen Netzen DNSSEC-Validierungsproblemen.

Timeout / keine Antwort

Mögliche Ursachen: unerreichbarer Server, Firewall/Pfad, Dienst lauscht nicht, Ausfall, Paketverlust. Das ist nicht NXDOMAIN.

Leere Antwort

Der Name kann existieren, aber keinen Record des abgefragten Typs besitzen. A, AAAA, MX, NS und PTR bewusst wählen.

DNS gezielt abfragen

nslookup server.firma.test

Fragt typischerweise den konfigurierten/default Resolver und zeigt dessen DNS-Antwort. Das bildet nicht zwingend den gesamten Resolverpfad jeder Anwendung ab.

dig server.firma.test A

Optional auf Linux/Unix-artigen Systemen; keine Installation erforderlich.

dig firma.test MX

Fragt bewusst Mail-Records.

dig firma.test NS

Prüft Nameserverinformation.

Konfigurierten Resolver prüfen

ipconfig /all

Zeigt unter Windows unter anderem konfigurierte DNS-Server.

ipconfig /displaydns

Kann den lokalen Windows-Resolvercache anzeigen.

cat /etc/resolv.conf

Hinweis unter Linux; die Datei kann von systemd-resolved, NetworkManager oder anderer Software erzeugt sein und ist nicht immer allein maßgeblich.

resolvectl status

Optional, falls die jeweilige Linux-Umgebung systemd-resolved nutzt.

Falsche oder alte Antwort

server.firma.test soll nun 192.168.10.30 liefern, der Client sieht aber 192.168.10.20. Vergleiche konfigurierten Resolver und – falls bekannt – autoritativen Server, prüfe TTL und kontrolliere den autoritativen Record. Ein Cache innerhalb der TTL ist möglich; eine fehlerhafte Zonendatei ebenso.

Cache-Schichten können in Anwendung/Browser, Betriebssystem/Stub, lokalem rekursivem Resolver oder Upstream liegen; nicht jedes System besitzt alle. Darum können zwei Clients zeitweise unterschiedliche Antworten erhalten.

Falscher Resolver durch DHCP

Erhält ein Client 192.168.10.5 statt des vorgesehenen Firmenresolvers 192.168.10.10, können interne Namen ausfallen oder anders beantwortet werden, obwohl externe Auflösung noch klappt. DHCP kann eine falsche DNS-Serveradresse verteilen, obwohl die Adressvergabe selbst erfolgreich ist. Gateway und DNS bleiben verschiedene Angaben.

Forward und Reverse getrennt prüfen

server.firma.test A 192.168.10.20, aber der PTR liefert oldserver.firma.test. A und PTR werden getrennt gepflegt. Die Abweichung kann Administration, Logs oder bestimmte Richtlinien/Dienste betreffen, ist aber nicht für jede Anwendung zwingend fatal.

Wissenscheck

Der nächste sinnvolle Prüfschritt

Gateway und 192.168.10.20 sind erreichbar, aber server.firma.test wird nicht aufgelöst. Was untersuchst du als Nächstes?

Zwei Clients, zwei Antworten

Client A erhält die alte, Client B die neue Adresse. Ein möglicher, naheliegender Prüfpunkt ist der jeweilige Resolverpfad mit Cache und TTL. Das ist eine Hypothese, keine garantierte Ursache.

Typische Fehlvorstellungen

Falsch: „Wenn ping per Name nicht klappt, ist DNS definitiv kaputt.“
Korrektur: Ping hängt auch von ICMP und Zielverhalten ab; nutze DNS-spezifische Werkzeuge.
Falsch: „NXDOMAIN bedeutet, der DNS-Server ist nicht erreichbar.“
Korrektur: NXDOMAIN ist eine negative DNS-Antwort; Unerreichbarkeit zeigt sich eher als Timeout.
Falsch: „DNS-Cache löschen ist immer der erste Schritt.“
Korrektur: Erst Zustand und Antworten dokumentieren.
Falsch: „Wenn eine IP erreichbar ist, funktioniert automatisch DNS.“
Korrektur: IP-Kommunikation und Namensauflösung sind getrennte Funktionen.
Falsch: „A und PTR sind automatisch gekoppelt.“
Korrektur: Forward und Reverse werden separat konfiguriert.
Falsch: „SERVFAIL bedeutet immer, der Name existiert nicht.“
Korrektur: SERVFAIL ist eine andere Fehlerklasse ohne eindeutige Einzelursache.

Praktische Checkliste

Client
IP/Gateway okay? · DNS-Server konfiguriert? · Resolver erreichbar?
Query
Name und RR-Typ korrekt? · Antwort, Timeout, NXDOMAIN oder SERVFAIL?
Resolver
Cache/TTL? · Upstream? · passende interne Umgebung/Ansicht, falls vorhanden?
Autoritativ
Record und Zone korrekt? · Delegation? · TTL?

Nächste Lektion

Praxis: DNS mit Filius

Im Abschlusslab konfigurierst, testest und störst du eine kleine DNS-Umgebung kontrolliert.

Dein Lernstand

Lektion in Bearbeitung

Das Öffnen startet die Lektion. Als erledigt zählt sie erst nach deiner ausdrücklichen Bestätigung.