Anmelden

Netzwerkfehler systematisch analysieren

Lektion 4 von 6

DHCP- und DNS-Fehler eingrenzen

Unterscheide automatische Adresskonfiguration von Namensauflösung und ihren Fehlersymptomen.

Lernziele

Nach Abschluss dieser Lektion kannst du:

  • DHCP- und statische Clientkonfiguration unterscheiden
  • Lease-Vorhandensein und Lease-Korrektheit trennen
  • IPv4 Link-Local/APIPA als Evidenz einordnen
  • falsche DHCP-Optionen für Gateway oder DNS erkennen
  • Pool-Erschöpfung und Relay-Pfade konzeptionell einordnen
  • IP-Erreichbarkeit von DNS-Auflösung trennen
  • NXDOMAIN, SERVFAIL, Timeout und leere Antworten vorsichtig interpretieren
  • Resolverergebnisse kontrolliert vergleichen
  • falsche oder zwischengespeicherte DNS-Daten erkennen
  • eine DNS-Antwort von einer korrekten DNS-Antwort unterscheiden
  • lesende DHCP-/DNS-Werkzeuge einsetzen
  • Flush- und Reset-first-Troubleshooting vermeiden

DHCP konfiguriert – DNS löst Namen auf

DHCP und DNS sind getrennte Dienste. DHCP kann einem Client unter anderem IPv4-Adresse, Präfix, Gateway und die Adresse eines DNS-Resolvers mitteilen. DNS beantwortet anschließend namensbezogene Anfragen. Ein DHCP-Fehler kann also die DNS-Konfiguration des Clients betreffen, ohne dass beide Dienste identisch wären.

DHCP und DNS: verbunden, aber getrennt

DHCP

Wie bekommt der Client seine Netzwerkkonfiguration?

  • IPv4-Adresse
  • Maske / Präfix
  • Gateway
  • DNS-Server-Adressen
  • weitere Optionen
nennt den zu verwendenden Resolver

DNS

Wie wird ein Name aufgelöst oder ein Dienst gefunden?

DNS liefert namensbezogene Records und Antworten.

Trennung: DHCP kann dem Client sagen, welchen DNS-Server er verwenden soll. Gewöhnliche DNS-Anfragen beantwortet DHCP nicht selbst.

DHCP systematisch untersuchen

  1. 1.Ist DHCP aktiviert oder ist die Konfiguration statisch?
  2. 2.Hat der Client eine IPv4-Adresse erhalten?
  3. 3.Passt sie zum erwarteten Netz?
  4. 4.Stimmen Maske oder Präfix?
  5. 5.Ist das Default Gateway plausibel?
  6. 6.Sind die DNS-Server plausibel?
  7. 7.Sind Lease-Zeitpunkte und DHCP-Server sichtbar?
  8. 8.Ist erwartete lokale Infrastruktur erreichbar?
  9. 9.Sind ein oder mehrere Clients betroffen?
  10. 10.Sind VLAN, Relay, Pfad oder Server als nächster Bereich plausibel?
Zwei Diagnosepfade

DHCP-Evidenz

  1. 1. DHCP oder statisch?
  2. 2. IP und Präfix plausibel?
  3. 3. Gateway und DNS plausibel?
  4. 4. Lease und Umfang?
  5. 5. Link, VLAN, Relay oder Serverpfad?

DNS-Evidenz

  1. 1. IP-Pfad plausibel?
  2. 2. Welcher Resolver?
  3. 3. Welcher exakte Name?
  4. 4. Antwort, NXDOMAIN, SERVFAIL oder Timeout?
  5. 5. Antwort korrekt, Cache/TTL oder Datenquelle?

Beide Pfade beginnen mit Beobachtung. Cache leeren, Lease erneuern oder Werte überschreiben sind keine ersten Diagnoseschritte.

Clientseitige DHCP-Evidenz

A · lesend

ipconfig /all

Windows zeigt je nach Kontext unter anderem „DHCP aktiviert“, IPv4-Adresse, Subnetzmaske, Default Gateway, DHCP-Server, DNS-Server sowie Lease erhalten/ablaufend. Diese Rollen nicht verwechseln.

A · lesend

ip addr · ip route

Linux zeigt Adressen/Präfixe und Routen. Optional können vorhandene Werkzeuge wie nmcli oder networkctl weitere Evidenz liefern; NetworkManager oder systemd-networkd sind nicht überall eingesetzt.

Ein Lease-Eintrag beweist nur, dass Konfiguration bezogen wurde. Er beweist nicht, dass jede Option fachlich richtig ist.

APIPA, falsche Optionen, Pool und Relay

Link-Local / APIPA

169.254.32.18/16 zeigt, dass aktuell nicht die erwartete Firmenkonfiguration vorliegt. Link, Client, VLAN, DHCP-Pfad, Relay, Server und Pool bleiben mögliche Untersuchungsbereiche; weder Serverausfall noch Pool-Erschöpfung sind damit allein bewiesen.

Lease vorhanden, Gateway falsch

Client 192.168.10.50/24, geliefert Gateway 192.168.10.254, erwartet 192.168.10.1, DNS 192.168.10.10. Untersuche Scope, Optionen und Quelle der Konfiguration – überschreibe das Gateway nicht einfach manuell.

Endlicher Adresspool

Bestehende Clients können gültige Leases behalten, während neue Clients zeit- oder geräteabhängig keine normale Adresse erhalten. Das ist mit Pool-Erschöpfung vereinbar, aber APIPA allein beweist sie nicht.

Relay über Subnetzgrenzen

Funktioniert DHCP in Subnetz A, nicht aber in Subnetz B, obwohl derselbe zentrale Server vorgesehen ist, sind VLAN, Relay/Helper und der Pfad für Subnetz B plausible Bereiche. Router leiten DHCP-Broadcasts nicht automatisch wie normalen gerichteten Verkehr weiter.

Wissenscheck

Link-Local eingrenzen

PC01 hat 169.254.32.18/16 und kein erwartetes Firmengateway; Nachbarn im selben VLAN erhalten 192.168.10.x/24 per DHCP. Was untersuchst du als Nächstes?

DNS systematisch untersuchen

  1. 1.Ist grundlegende IP-Erreichbarkeit plausibel?
  2. 2.Welcher Resolver ist konfiguriert?
  3. 3.Ist dieser Resolver erreichbar?
  4. 4.Welcher exakte Name und Record-Typ wird abgefragt?
  5. 5.Welche Antwort oder welcher Fehler tritt auf?
  6. 6.Löst ein Known-Good-Name auf?
  7. 7.Liefert ein gezielt abgefragter Resolver ein anderes Ergebnis?
  8. 8.Ist die Antwort korrekt oder nur vorhanden?
  9. 9.Sind Cache, TTL und Änderungszeit relevant?
  10. 10.Ist die autoritative Datenquelle ein plausibler nächster Bereich?

A · lesend

nslookup server.firma.test

Zeigt je nach Plattform den verwendeten Resolver, Antworten oder Fehler. Das Ausgabeformat ist nicht überall identisch.

A · lesend

nslookup server.firma.test 192.168.10.10

Fragt gezielt den dokumentierten Resolver ab und erlaubt einen kontrollierten Vergleich.

A · lesend, optional

dig server.firma.test

Fragt DNS direkt; das Werkzeug muss installiert sein.

A · lesend, optional

getent hosts server.firma.test

Nutzt unter Linux den konfigurierten Systempfad für Namensdienste, nicht zwingend ausschließlich einen direkten DNS-Query.

DNS-Ergebnisse richtig lesen

NXDOMAIN
DNS meldet, dass der abgefragte Name im relevanten Namespace nicht existiert.
SERVFAIL
Resolver oder Server konnte die Auflösung nicht erfolgreich abschließen.
Timeout
Innerhalb der Wartezeit kam keine erwartete DNS-Antwort.
Keine passende Antwort
Die Abfrage kann erfolgreich sein, ohne einen Record des angefragten Typs zurückzugeben.

Keines dieser Ergebnisse identifiziert allein eine einzige Grundursache.

Antwort vorhanden – Daten trotzdem falsch

Dokumentiert ist server.firma.test → 192.168.10.20, der verwendete Resolver liefert aber 192.168.10.30. DNS ist erreichbar und antwortet; Record, Cache, Resolverauswahl, Split-DNS/View oder Datenquelle können dennoch falsch beziehungsweise unerwartet sein.

DNS-Antworten können entsprechend ihrer TTL zwischengespeichert werden. Nach einer Änderung können Resolver zeitweise verschiedene Daten liefern. Beobachte zuerst Resolver, Antwort, TTL-/Cache-Kontext und Änderungszeit. Implementierungen wählen mehrere konfigurierte Resolver nicht nach einer universellen Regel „primär bis aus, dann sekundär“ aus.

Wissenscheck

IP funktioniert, Name nicht

192.168.10.20 ist vom Client erreichbar, aber nslookup server.firma.test liefert NXDOMAIN. Welche Schicht untersuchst du als Nächstes?

Wissenscheck

Unerwartete DNS-Antwort

nslookup liefert 192.168.10.30, dokumentiert ist 192.168.10.20. Was ist damit bewiesen?

Sichere Praxis: drei Befunde

A · plausibler Ausgangszustand

192.168.10.44/24 · GW 192.168.10.1 · DNS 192.168.10.10 · DHCP: ja. Bekannt: Die Felder entsprechen der Baseline. Offen: Dienstgesundheit. Nächster lesender Test richtet sich nach dem konkreten Symptom.

B · erwartete Firmenkonfiguration fehlt

169.254.15.42/16. Verdächtig: Link-Local statt Firmenlease. Offen: genaue Client-, Link-, VLAN-, Relay-, Pool- oder Serverursache. Nächster Test: Link und ipconfig /all beziehungsweise ip addr/ip route vergleichen.

C · unerwarteter Resolver

IP und Gateway sind gültig, DNS zeigt jedoch einen nicht dokumentierten Resolver. Bekannt: Konfiguration weicht ab. Offen: ob sie statisch oder per DHCP kam und welches Ergebnis dieser Resolver liefert. Nächster Test: Resolverquelle und gezielte Namensantwort lesend vergleichen.

Typische Fehlvorstellungen

Falsch: „DHCP-Lease vorhanden = Netzwerkkonfiguration garantiert korrekt.“
Korrektur: Optionen können trotz Lease falsch oder unpassend sein.
Falsch: „169.254.x.x beweist, dass der DHCP-Server ausgeschaltet ist.“
Korrektur: Link-Local lässt mehrere Client-, Link-, VLAN-, Relay-, Pool- und Serverursachen offen.
Falsch: „DHCP und DNS sind derselbe Dienst.“
Korrektur: DHCP verteilt Konfiguration; DNS beantwortet Namensfragen.
Falsch: „NXDOMAIN bedeutet Netzwerkweg zum DNS-Server kaputt.“
Korrektur: NXDOMAIN ist gerade eine DNS-Antwort über den Namen.
Falsch: „Wenn DNS antwortet, ist der Wert automatisch richtig.“
Korrektur: Eine erreichbare Quelle kann falsche oder veraltete Daten liefern.
Falsch: „DNS-Cache immer zuerst leeren.“
Korrektur: Erst Resolver, Antwort und Cache-/TTL-Kontext dokumentieren.
Falsch: „Der zweite DNS-Server wird nur benutzt, wenn der erste ausgeschaltet ist.“
Korrektur: Resolverauswahl variiert nach Betriebssystem und Clientimplementierung.

Befehlssicherheit

A · lesend / diagnostisch
Erforderlich sind nur bekannte Zieltests und Abfragen wie ipconfig /all, ip addr, ip route, nslookup, dig, getent, Test-NetConnection, netstat -ano, ss -ltn und curl.
B · zustandsändernd, nur konzeptionell
Lease Release/Renew, DNS-Flush, Adapterreset, Route oder Konfiguration ändern und Dienstneustart werden nicht ausgeführt.
C · privilegiert/administrativ, nur konzeptionell
DHCP-/DNS-Server, Relay, Firewall, Dienstbindung oder Serveranwendung ändern erfordert Befund, Freigabe und passende Zuständigkeit.

Nächste Lektion

Ports, Dienste und typische Fehlersymptome

Als Nächstes trennst du DNS, Transportendpunkt, Listener, Dienst und Anwendung anhand von Refused, Timeout und HTTP-Antworten.

Dein Lernstand

Lektion in Bearbeitung

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