Site icon bintorosoft.com

18.7 DNS- und DHCP-Probleme systematisch analysieren

Red Snapper

Engineer looking to work in the electrical control room. Neural network AI generated art

DNS- und DHCP-Probleme gehören zu den häufigsten Ursachen für Störungen in IP-Netzwerken. Wenn Clients keine Adresse erhalten, Namen nicht aufgelöst werden oder nur einzelne Dienste ausfallen, liegt die Ursache oft nicht in einem einzigen Fehler, sondern in einer Kette aus Konfigurations-, Erreichbarkeits- oder Infrastrukturproblemen. Eine systematische Analyse ist deshalb entscheidend. Wer strukturiert vorgeht, trennt Symptome von Ursachen, prüft zuerst die grundlegende Konnektivität und grenzt dann Schritt für Schritt ein, ob das Problem auf Client-, Server-, VLAN-, Relay-, Routing- oder Sicherheitsniveau entsteht. Gerade in Unternehmensnetzen ist diese Methodik wichtig, weil DNS und DHCP eng mit Default Gateway, IP-Adressierung, VLAN-Zuordnung, Active Directory, Firewall-Regeln und zentralen Netzwerkdiensten verzahnt sind.

Warum DNS und DHCP gemeinsam betrachtet werden müssen

In der Praxis treten DNS- und DHCP-Fehler oft zusammen auf. Ein Client, der keine gültige IP-Konfiguration erhält, kann auch keine DNS-Anfragen korrekt senden. Umgekehrt kann ein Client mit funktionierender IP-Adresse durch fehlerhafte DNS-Einträge den Eindruck erwecken, das gesamte Netzwerk sei gestört. Deshalb beginnt professionelle Fehlersuche nie mit Vermutungen, sondern mit einer klaren Trennung zwischen Layer-3-Erreichbarkeit, Adressvergabe und Namensauflösung.

Systematische Fehlersuche: zuerst Symptom, dann Fehlerdomäne

Am Anfang steht immer die Frage: Was genau funktioniert nicht? „Kein Internet“ ist kein technischer Befund. Besser ist eine präzise Eingrenzung: Erhält der Client überhaupt eine IP-Adresse? Ist nur die Namensauflösung betroffen? Funktionieren Pings auf IP-Adressen, aber nicht auf Hostnamen? Betrifft das Problem einen einzelnen Client, ein VLAN, einen Standort oder das gesamte Netzwerk?

Typische Beobachtungen richtig interpretieren

Empfohlene Reihenfolge der Analyse

DHCP-Probleme systematisch analysieren

DHCP arbeitet in einem klaren Ablauf: Discover, Offer, Request, Acknowledge. Wenn ein Client keine Adresse erhält, muss ermittelt werden, an welcher Stelle dieser Prozess scheitert. In geswitchten Netzwerken mit mehreren VLANs ist besonders wichtig, ob sich Client und Server im selben Broadcast-Domain befinden oder ob ein DHCP-Relay-Agent eingesetzt wird.

Client-seitige Prüfung der DHCP-Funktion

Die erste Prüfung erfolgt direkt am Endgerät. Entscheidend sind IP-Adresse, Lease-Informationen, Default Gateway und zugewiesene DNS-Server.

Windows:
ipconfig /all
ipconfig /release
ipconfig /renew

Linux:
ip addr
nmcli dev show
dhclient -v

DHCP-Server und Scope-Konfiguration prüfen

Auf dem DHCP-Server muss geprüft werden, ob der passende Adresspool aktiv ist, genügend freie Leases verfügbar sind und die Netzparameter korrekt definiert wurden. Ein häufiger Fehler ist ein erschöpfter Scope oder eine falsche Netzmaske, die zu scheinbar zufälligen Kommunikationsstörungen führt.

In Cisco-Umgebungen kann die lokale DHCP-Konfiguration auf einem Router oder Layer-3-Switch so überprüft werden:

show ip dhcp pool
show ip dhcp binding
show ip dhcp server statistics
show running-config | section dhcp

DHCP-Relay und VLAN-Design kontrollieren

In vielen Netzen befindet sich der DHCP-Server nicht im selben VLAN wie der Client. Dann muss auf dem Layer-3-Interface ein Relay-Agent konfiguriert sein. Fehlt dieser, bleiben DHCP-Discover-Broadcasts lokal im VLAN und erreichen den Server nie.

interface vlan 20
 ip address 192.168.20.1 255.255.255.0
 ip helper-address 192.168.100.10

Gerade nach Änderungen an VLANs, Trunks oder SSIDs sind falsch zugeordnete Clients eine häufige Ursache. Dann funktioniert DHCP technisch korrekt, aber im falschen Broadcast-Bereich.

Typische DHCP-Ursachen in produktiven Netzen

Rogue DHCP Server erkennen

Ein besonders kritischer Fehler ist ein nicht autorisierter DHCP-Server. Dieser verteilt unter Umständen falsche Gateways oder DNS-Server und verursacht schwer nachvollziehbare Störungen. Typisch sind wechselnde Symptome bei unterschiedlichen Clients.

Auf Switches helfen Sicherheitsmechanismen wie DHCP Snooping:

show ip dhcp snooping
show ip dhcp snooping binding

DNS-Probleme systematisch analysieren

Wenn DHCP funktioniert, aber Anwendungen trotzdem keine Ziele erreichen, liegt das Problem oft in der Namensauflösung. DNS-Störungen äußern sich häufig subtil: Manche Webseiten laden nicht, interne Servernamen funktionieren nicht oder nur FQDNs schlagen fehl. Die wichtigste Unterscheidung lautet: Ist der DNS-Server nicht erreichbar oder liefert er falsche bzw. keine Antworten?

Grundlegende DNS-Prüfung am Client

Zunächst wird geprüft, welche DNS-Server der Client überhaupt verwendet und ob diese erreichbar sind.

Windows:
ipconfig /all
nslookup example.com
nslookup internal-server.corp.local 192.168.10.53

Linux:
cat /etc/resolv.conf
resolvectl status
dig example.com
dig @192.168.10.53 internal-server.corp.local

Ein sehr nützlicher Test ist der Vergleich zwischen Ping auf IP-Adresse und Ping auf Hostname:

ping 8.8.8.8
ping www.example.com

Wenn der erste Test funktioniert und der zweite nicht, ist die Layer-3-Konnektivität grundsätzlich vorhanden, die DNS-Auflösung aber gestört.

DNS-Serverantworten und Rekursion prüfen

Ein DNS-Server kann erreichbar sein und trotzdem keine korrekten Antworten liefern. Gründe sind fehlerhafte Zonen, defekte Forwarder, Timeouts bei rekursiven Anfragen oder eine nicht geladene Zone. Deshalb reicht Erreichbarkeit allein nicht aus; die Qualität der Antwort muss ebenfalls geprüft werden.

nslookup
server 192.168.10.53
set debug
internal-server.corp.local
example.com

Mit dig lässt sich die Antwort noch genauer analysieren:

dig @192.168.10.53 internal-server.corp.local
dig @192.168.10.53 example.com
dig +trace example.com

Cache, TTL und veraltete Einträge berücksichtigen

DNS-Probleme sind oft nicht dauerhaft, sondern entstehen durch zwischengespeicherte Informationen. Nach IP-Änderungen oder Migrationen zeigen Clients oder Resolver noch auf alte Adressen. Deshalb sollte der lokale und serverseitige Cache geprüft werden.

Windows:
ipconfig /displaydns
ipconfig /flushdns

Linux:
resolvectl flush-caches
systemd-resolve --statistics

Interne DNS-Probleme in Unternehmensnetzen

In Enterprise-Umgebungen hängen DNS-Fehler oft mit Active Directory, Split-DNS, Conditional Forwarding oder dynamischen Updates zusammen. Besonders problematisch sind falsche DNS-Server auf Domain-Clients, da dann Anmeldung, Gruppenrichtlinien und Service Discovery fehlschlagen können.

DNS und DHCP im Zusammenhang prüfen

Viele Fehler entstehen an der Schnittstelle zwischen beiden Diensten. DHCP liefert DNS-Serveradressen an Clients und kann je nach Design auch dynamische DNS-Updates anstoßen. Ist diese Kette gestört, erhält der Client zwar eine IP-Adresse, ist aber trotzdem nicht sauber im Netzwerk integriert.

Typische Kombinationsfehler

Ein klassisches Beispiel: Ein Client bekommt per DHCP die Adresse eines öffentlichen DNS-Servers statt des internen DNS. Internetnamen funktionieren, interne Servernamen jedoch nicht. Der Anwender meldet „teilweise kein Netzwerk“, obwohl das Problem rein in der Namensauflösung liegt.

Prüffragen für die kombinierte Analyse

Praxisnahe Troubleshooting-Methodik für Netzwerkingenieure

Professionelles Troubleshooting bedeutet, reproduzierbar und schichtweise zu arbeiten. Anstatt sofort Serverkonfigurationen zu ändern, wird die Fehlerdomäne eingegrenzt. Diese Methodik spart Zeit und verhindert Blindaktionen im Produktionsnetz.

Empfohlener Ablauf im Betrieb

Nützliche Cisco-CLI-Kommandos

show vlan brief
show interfaces trunk
show ip interface brief
show running-config interface vlan 20
show access-lists
show ip route
show arp
show mac address-table
show ip dhcp snooping
show logging

Diese Befehle helfen, Portzuordnung, VLAN-Mitgliedschaft, SVI-Status, Routing, Sicherheitsfilter und Log-Meldungen schnell zu prüfen. Gerade bei DHCP-Problemen sind show logging und die Kontrolle der Interface-Konfiguration oft entscheidender als komplexe Serveranalysen.

Paketanalyse bei hartnäckigen Fehlern

Wenn die Ursache unklar bleibt, liefert ein Paketmitschnitt eindeutige Hinweise. Bei DHCP sollte geprüft werden, ob Discover, Offer, Request und Acknowledge tatsächlich sichtbar sind. Bei DNS ist entscheidend, ob Queries den Server erreichen und welche Response-Codes zurückkommen, etwa NXDOMAIN, SERVFAIL oder Timeout.

Häufige Fehlerbilder und ihre wahrscheinlichsten Ursachen

Client erhält gar keine Adresse

Client erhält Adresse, aber kein Netzwerkzugriff

Internes Netzwerk funktioniert, Internetnamen nicht

Internet per IP funktioniert, aber Hostnamen nicht

Nur interne Namen funktionieren nicht

Dokumentation und Prävention als Teil der Problemanalyse

Systematische Analyse endet nicht bei der Fehlerbehebung. Wer DNS- und DHCP-Störungen dauerhaft reduzieren will, braucht saubere Dokumentation und präventive Kontrollen. Dazu gehören Scope-Übersichten, VLAN-Pläne, definierte DNS-Forwarder, Monitoring der Lease-Auslastung und Schutzmechanismen gegen Rogue DHCP. Ebenso wichtig ist eine klare Betriebsdokumentation, welche VLANs welchen DHCP-Pools zugeordnet sind und welche DNS-Server für Clients, Server und Domänenmitglieder vorgesehen sind.

Gerade in komplexen Netzwerken entscheidet nicht Einzelwissen über den Erfolg, sondern eine klare Troubleshooting-Methodik. Wer bei DNS- und DHCP-Problemen zuerst die IP-Konfiguration prüft, dann Erreichbarkeit, danach Serverantworten und schließlich die Kopplung beider Dienste analysiert, findet Fehler schneller, belastbarer und mit deutlich geringerem Risiko für Folgeprobleme im produktiven Netzwerk.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.

Exit mobile version