18.7 DNS- und DHCP-Probleme systematisch analysieren

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.

• DHCP liefert IP-Adresse, Subnetzmaske, Default Gateway und oft auch DNS-Server.
• DNS übersetzt Hostnamen in IP-Adressen und ist für nahezu alle modernen Anwendungen kritisch.
• Ein Fehler in DHCP kann einen DNS-Fehler vortäuschen.
• Ein DNS-Fehler kann wie ein Routing- oder Internetproblem wirken.

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

• APIPA-Adresse wie 169.254.x.x deutet meist auf ein DHCP-Problem hin.
• Gültige IP, aber kein Ping zum Default Gateway spricht eher für VLAN-, Switching- oder Routing-Probleme.
• Ping auf 8.8.8.8 funktioniert, aber nicht auf einen Hostnamen: DNS ist verdächtig.
• Nur neu gestartete Clients sind betroffen: Lease-, Pool- oder DHCP-Server-Problem wahrscheinlich.
• Nur bestimmte Namen werden nicht aufgelöst: DNS-Zone, Forwarder oder Cache prüfen.

Empfohlene Reihenfolge der Analyse

• Physische Verbindung und Link-Status prüfen.
• IP-Konfiguration des Clients kontrollieren.
• Erreichbarkeit des Default Gateways testen.
• DHCP-Parameter verifizieren.
• DNS-Server-Erreichbarkeit und Namensauflösung prüfen.
• Relay, VLAN, ACLs, Firewalls und Serverdienste analysieren.

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

• Fehlt eine IP-Adresse oder erscheint 169.254.x.x, erreicht der Client keinen DHCP-Server.
• Ist die Adresse gültig, aber Gateway oder DNS fehlen, ist oft der DHCP-Scope falsch konfiguriert.
• Erhält der Client eine Adresse aus dem falschen Netz, liegt häufig eine VLAN- oder Pool-Fehlzuordnung vor.

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.

• Ist der Scope aktiviert?
• Gibt es noch freie Adressen im Pool?
• Stimmen Netz, Maske, Gateway und DNS-Optionen?
• Sind Ausschlussbereiche oder Reservierungen korrekt gesetzt?
• Läuft der DHCP-Dienst fehlerfrei?

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

• Ist auf dem richtigen SVI oder Routed Interface ein ip helper-address gesetzt?
• Zeigt die Helper-Adresse auf den korrekten DHCP-Server?
• Ist das betroffene VLAN dem Access-Port oder SSID-Mapping richtig zugeordnet?
• Erlauben ACLs und Firewalls UDP 67/68?

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

• DHCP-Scope vollständig ausgelastet
• Fehlende oder falsche Relay-Konfiguration
• Falsches VLAN am Switchport oder Access Point
• ACL oder Firewall blockiert UDP 67/68
• DHCP-Serverdienst gestoppt oder überlastet
• Rogue DHCP Server im Netzwerk verteilt falsche Parameter

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.

• Clients erhalten unterschiedliche Gateway- oder DNS-Werte im selben VLAN.
• Nur manche Geräte haben Konnektivitätsprobleme.
• Die Lease-Daten zeigen unerwartete Serveradressen.

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

• Stimmen die eingetragenen DNS-Server mit dem Soll-Zustand überein?
• Kann der Client den DNS-Server per Ping oder besser per Routing-Pfad erreichen?
• Funktioniert die Auflösung externer und interner Namen getrennt betrachtet?

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.

• Liefert der DNS-Server eine autoritative Antwort für interne Zonen?
• Funktioniert die rekursive Auflösung externer Domains?
• Sind Forwarder korrekt eingetragen und erreichbar?
• Gibt es fehlerhafte A-, AAAA-, PTR- oder CNAME-Records?

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

• Zeigt der Client auf eine veraltete IP-Adresse?
• Ist die TTL eines Records zu hoch für häufige Änderungen?
• Wurde ein alter A-Record nicht bereinigt?

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.

• Domain-Clients sollten meist nur interne DNS-Server verwenden.
• Externe Resolver direkt auf Clients führen oft zu AD-bezogenen Fehlern.
• Dynamische DNS-Updates müssen korrekt funktionieren, damit neue Hosts registriert werden.
• Reverse Lookup ist für manche Verwaltungs- und Sicherheitsprozesse relevant.

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

• DHCP verteilt falsche DNS-Server.
• DHCP-Scope enthält ein falsches Default Gateway und DNS scheint „langsam“ oder „instabil“.
• Der Host erhält eine Lease, wird aber nicht korrekt im DNS registriert.
• Alte DNS-Records zeigen auf frühere DHCP-Leases.

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

• Welche DNS-Server wurden per DHCP übermittelt?
• Ist der vergebene DNS-Server aus dem Client-VLAN erreichbar?
• Passt der DNS-Suffix zur internen Namensstruktur?
• Wird der Hostname nach Lease-Vergabe korrekt im DNS eingetragen?

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

• Problem lokalisieren: einzelner Host, mehrere Hosts, ganzes VLAN, ganzer Standort
• Symptom klassifizieren: keine IP, falsche IP, keine Namensauflösung, nur interne/externe Namen betroffen
• Ist-Zustand erfassen: IP, Gateway, DNS, Lease, VLAN, Switchport
• Datenpfad prüfen: Client → Access Switch → Gateway/SVI → Relay → Server
• Dienstpfad prüfen: DHCP-Prozess oder DNS-Query vollständig nachvollziehen
• Nur nach belegter Ursache ändern, nicht auf Verdacht

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.

• Kein DHCP Offer: Server oder Relay nicht erreichbar
• DHCP Offer vorhanden, aber kein ACK: Request-Prozess oder Konfliktproblem
• DNS Query ohne Response: Erreichbarkeit, Firewall oder Serverdienst prüfen
• DNS Response mit falscher IP: Zoneninhalt oder Cache fehlerhaft

Häufige Fehlerbilder und ihre wahrscheinlichsten Ursachen

Client erhält gar keine Adresse

• DHCP-Server nicht erreichbar
• Scope erschöpft
• Fehlender ip helper-address
• Falsches VLAN
• UDP 67/68 blockiert

Client erhält Adresse, aber kein Netzwerkzugriff

• Falsches Default Gateway im DHCP-Scope
• Falsche Subnetzmaske
• ACL oder Routing-Problem
• Duplicate IP oder ARP-Konflikt

Internes Netzwerk funktioniert, Internetnamen nicht

• DNS-Forwarder fehlerhaft
• Externe Rekursion gestört
• Firewall blockiert DNS-Verkehr zum Upstream-Resolver

Internet per IP funktioniert, aber Hostnamen nicht

• Falscher oder nicht erreichbarer DNS-Server
• DNS-Dienst ausgefallen
• Resolver-Cache fehlerhaft

Nur interne Namen funktionieren nicht

• Client nutzt externe statt interne DNS-Server
• Interne Zone fehlerhaft oder nicht geladen
• Dynamische DNS-Registrierung gestört
• Split-DNS oder Conditional Forwarding falsch konfiguriert

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.

• DHCP-Pools und Reservierungen dokumentieren
• DNS-Zonen, Forwarder und Conditional Forwarder versionieren
• Adressauslastung überwachen
• DHCP Snooping und Port Security einsetzen
• Änderungen an VLANs, Gateways und Scopes kontrolliert durchführen
• Nach Änderungen DNS- und DHCP-Funktion aktiv testen

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:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

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