DNS- vs. Routing-Probleme unterscheiden (mit klaren Beweisen)

DNS- vs. Routing-Probleme unterscheiden zu können, ist eine Kernkompetenz im IT-Betrieb: Beide Fehlerbilder fühlen sich für Nutzer oft gleich an („Internet geht nicht“, „Website lädt nicht“), erfordern aber völlig unterschiedliche Maßnahmen und Eskalationswege. Wer hier rät, verliert Zeit, produziert unnötige Changes und eskaliert an das falsche Team. Der entscheidende Unterschied: DNS-Probleme betreffen die Namensauflösung (Hostname → IP-Adresse) und sind überwiegend Layer 7, während Routing-Probleme die Erreichbarkeit auf IP-Ebene betreffen und primär Layer 3 sind. In der Praxis ist es dennoch nicht immer eindeutig, weil DNS über IP transportiert wird: Ein Routingfehler kann DNS wie ein DNS-Problem aussehen lassen (Timeout), und ein DNS-Fehler kann Routing wie „kaputt“ wirken lassen (weil Anwendungen ohne IP nicht starten). Dieser Leitfaden zeigt Ihnen, wie Sie DNS- vs. Routing-Probleme mit klaren Beweisen trennen: mit minimalen Tests, eindeutigen Indikatoren, typischen Mustern und sauberer Dokumentation. Ziel ist, dass Sie in wenigen Minuten sagen können, was genau defekt ist, wo es defekt ist – und warum.

Grundprinzip: Erst Name, dann IP – und diese Reihenfolge als Beweis nutzen

Fast jede Internet- oder App-Verbindung beginnt mit DNS: Der Client fragt einen Resolver nach einer IP-Adresse zu einem Hostnamen. Erst danach kann IP-Routing überhaupt stattfinden, weil Routing nur mit IP-Paketen arbeitet. Daraus ergibt sich ein sehr praktischer Ansatz: Trennen Sie DNS und Routing, indem Sie einmal mit Hostnamen und einmal mit IP testen. Wenn IP-basierte Tests funktionieren, aber Hostnamen scheitern, ist DNS der Hauptverdacht. Wenn Hostnamen korrekt auflösen, aber IP-Verbindungen nicht funktionieren, ist Routing (oder Layer 4) der Hauptverdacht.

• DNS-Test: „Kann ich den Hostnamen in eine IP auflösen?“
• Routing-Test: „Kann ich eine IP erreichen und Pakete zustellen?“
• Beweislogik: IP ok + Name kaputt = DNS; Name ok + IP kaputt = Routing/Transport

OSI-Einordnung: Welche Schicht ist betroffen – und was ist nur Folge?

DNS ist ein Anwendungsprotokoll (OSI Layer 7). Routing findet auf OSI Layer 3 statt. In Störungen ist es jedoch wichtig, zwischen Symptom und Ursache zu unterscheiden:

• DNS-Symptom: NXDOMAIN, SERVFAIL, falsche IP, inkonsistente Antworten, ungewöhnliche TTL/Caches.
• Routing-Symptom: Kein Weg zum Zielnetz, asymmetrische Pfade, Blackholing, falsche Default Route, fehlerhafte VRF/Segmentierung.
• Folgeeffekt: Routingfehler kann DNS-Anfragen zum Resolver verhindern (DNS-Timeout), das ist dann kein „DNS-Problem“, sondern ein Netzwerkpfadproblem.

Der schnellste Entscheidungsbaum in der Praxis

Wenn Sie nur wenig Zeit haben, arbeiten Sie diese Reihenfolge ab. Jeder Schritt liefert ein klares „Ja/Nein“ und zwingt eine Entscheidung.

• 1) Kann der Client überhaupt eine DNS-Antwort bekommen? (Antwortcode wie NOERROR/NXDOMAIN/SERVFAIL vs. Timeout)
• 2) Liefert DNS eine IP für den Hostnamen? (A/AAAA/CNAME)
• 3) Ist die IP erreichbar? (Ping/Traceroute/TCP-Connect)
• 4) Ist das Problem nur bei einem Resolver oder in allen? (Resolver vergleichen)
• 5) Ist das Problem nur in einem Netzsegment/Standort? (Scope festlegen)

Beweise für DNS-Probleme: So sieht „DNS kaputt“ eindeutig aus

DNS-Probleme erkennt man daran, dass die Namensauflösung fehlschlägt oder falsche Ergebnisse liefert, während IP-Konnektivität grundsätzlich vorhanden sein kann. Die folgenden Indikatoren gelten als harte Beweise, weil sie direkt am DNS-Protokoll ansetzen.

Beweis 1: DNS liefert NXDOMAIN oder SERVFAIL statt einer IP

• NXDOMAIN: Der Name existiert aus Sicht des befragten DNS nicht. Häufig Tippfehler, fehlender Record, Split-DNS-Konflikt.
• SERVFAIL: Der Resolver konnte nicht sauber auflösen (DNSSEC, Delegation/NS, Upstream-Probleme).
• NOERROR ohne A/AAAA: Name existiert, aber kein passender Recordtyp (z. B. nur A, aber kein AAAA).

Beweis 2: Unterschiedliche Antworten je nach Resolver (Inkonsistenz)

Wenn Resolver A eine IP liefert, Resolver B aber NXDOMAIN/SERVFAIL oder eine andere IP, ist das ein sehr starkes DNS-Indiz. Typische Ursachen sind Forwarder-Fehler, Filter/Rewrite, Split DNS oder veraltete Caches.

• Interner Resolver liefert interne IP, öffentlicher Resolver liefert externe IP (oder umgekehrt).
• Ein Resolver liefert alte IP (Cache), ein anderer bereits die neue (Propagation/TTL).
• Sicherheits-DNS blockt oder „sinkholed“ bestimmte Domains.

Beweis 3: IP-Verbindung zu einer bekannten externen IP funktioniert, Hostname aber nicht

Wenn Sie z. B. eine externe IP erreichen, aber Hostnamen nicht auflösen, ist Routing zum Internet sehr wahrscheinlich in Ordnung. Dann liegt das Problem in DNS-Konfiguration, Resolver-Erreichbarkeit oder DNS-Policy.

• Ping zu externer IP funktioniert, DNS-Lookup timed out oder liefert NXDOMAIN.
• Traceroute zu externer IP läuft durch, aber Browser meldet „DNS_PROBE_FINISHED“ oder ähnliche DNS-Fehler.

Für eine solide technische Grundlage zu DNS-Konzepten ist der Anchor-Text RFC 1034 (DNS Konzepte) eine belastbare Referenz.

Beweise für Routing-Probleme: So sieht „Layer 3 kaputt“ eindeutig aus

Routing-Probleme zeigen sich dadurch, dass IP-Pakete ihr Ziel nicht erreichen oder Antworten nicht zurückfinden. Im Unterschied zu DNS ist hier der Hostname meist zweitrangig: Selbst wenn DNS perfekt funktioniert, bleibt die Verbindung tot.

Beweis 1: DNS löst korrekt auf, aber IP ist nicht erreichbar

• DNS liefert eine plausible IP (A/AAAA), aber Ping/Traceroute/TCP-Connect zur IP schlägt fehl.
• Problem tritt unabhängig vom Resolver auf (gleiche IP, gleiche Nichterreichbarkeit).

Beweis 2: Traceroute bricht an einer bestimmten Stelle reproduzierbar ab

Traceroute ist kein „Beweis für Schuld“, aber ein starkes Indiz, wo der Pfad endet. Wenn Traceroute bei einem bestimmten Hop im eigenen Netz oder am Provider-Edge stoppt, ist Routing/Weiterleitung im Pfad höchstwahrscheinlich der Engpass.

• Abbruch vor dem Internet-Gateway: internes Routing, Firewall-Zonen, VRF-Fehler, Default Route.
• Abbruch am Provider-Übergang: Provider-Routing, Peering, Filter, Incident.
• Abbruch nahe Ziel: Zielnetz/Upstream des Zielanbieters, DDoS-Maßnahmen, Filter.

Beweis 3: Nur bestimmte Netze/Subnetze/Standorte betroffen

Routing-Probleme sind oft segmentiert: Ein Standort kommt raus, ein anderer nicht; ein VLAN erreicht ein Zielnetz, ein anderes nicht. Das deutet auf fehlende Routen, falsche Policy-Based Routing-Regeln oder VRF-Zuordnungen hin.

• Nur VPN-Nutzer betroffen: Tunnel-Routing, Split-Tunnel-Policies, MTU/MSS.
• Nur ein VRF betroffen: VRF-Leak fehlt, falscher Default in VRF, falsche Next-Hop-Zuordnung.
• Nur ein Subnetz betroffen: fehlende Rückroute, ACLs auf Transit, NAT-Policy greift nicht.

Für verbindliche Grundlagen zu IP, Routing und Internet-Standards eignet sich der Anchor-Text RFC-Editor (Netzwerkstandards).

Der häufigste Stolperstein: DNS-Timeout ist oft Routing oder Firewall

Viele Tickets werden fälschlich als „DNS kaputt“ klassifiziert, weil DNS-Anfragen time-outen. Ein Timeout bedeutet aber zunächst nur: Keine Antwort kam zurück. Das kann DNS selbst sein – häufig ist es jedoch ein Pfadproblem zum Resolver (Routing) oder ein Filter (Firewall/Policy) auf UDP/TCP 53.

So erkennen Sie, ob DNS-Timeout wirklich DNS ist

• Resolver-IP erreichbar? Wenn nicht: Routing/Segmentierung zuerst lösen.
• Nur UDP oder auch TCP betroffen? Blockiertes TCP/53 kann bei großen Antworten zu scheinbar „zufälligen“ DNS-Problemen führen.
• Vergleich mit anderem Resolver: Wenn ein alternativer Resolver sofort antwortet, ist der erste Resolver oder der Pfad dahin verdächtig.
• Gleiche Symptome bei mehreren Clients im selben Segment: spricht eher für Netzwerk/Policy als für einen einzelnen Client.

DNS oder Routing: Typische Muster aus dem Alltag und die passende Einordnung

„Websites gehen nicht, aber Ping zu 1.1.1.1 geht“

• Wahrscheinlich DNS oder Proxy: IP-Konnektivität vorhanden, Namen oder HTTP-Transport scheitern.
• Beweis: DNS-Lookup liefert NXDOMAIN/SERVFAIL/Timeout, während IP-basierte Tests ok sind.

„DNS löst auf, aber alles lädt ewig oder gar nicht“

• Wahrscheinlich Routing/Layer 4: Pfad, MTU/MSS, Firewall-State, Asymmetrie.
• Beweis: Traceroute-Abbruch oder TCP-Connect-Timeout zu 443, trotz korrekter DNS-Antwort.

„Nur eine bestimmte Domain geht nicht“

• Wahrscheinlich DNS/Policy: falscher Record, DNSSEC/Delegation, Webfilter-Kategorie, Split DNS.
• Beweis: Andere Domains ok, aber diese Domain liefert NXDOMAIN/SERVFAIL oder eine abweichende IP je Resolver.

„Nur ein Standort kann nicht ins Internet“

• Wahrscheinlich Routing: Default Route, WAN, VRF, Provider-Anbindung.
• Beweis: Gateway erreichbar, aber Traceroute endet am Edge; DNS kann sogar noch funktionieren, aber Web nicht.

Ein belastbares Minimal-Set an Tests (mit eindeutigen Aussagen)

Mit diesen Prüfungen erzeugen Sie schnell verwertbare Beweise. Die Idee ist: Jede Prüfung beantwortet eine präzise Frage, die klar DNS oder Routing wahrscheinlicher macht.

• DNS-Auflösung eines Hostnamens (A/AAAA): Liefert DNS eine IP oder einen Fehlercode?
• IP-Erreichbarkeit einer bekannten IP: Funktioniert der IP-Pfad grundsätzlich?
• Erreichbarkeit des DNS-Resolvers als IP: Ist der Resolver per Netzwerk erreichbar?
• Traceroute zur Ziel-IP: Wo endet der Pfad?
• TCP-Connect zu 443 der Ziel-IP: Ist es Routing oder eher Port/Firewall?

Wenn es komplex wird: IPv6 als typische Quelle für „DNS vs. Routing“-Verwechslungen

Moderne Clients bevorzugen häufig IPv6, wenn ein AAAA-Record vorhanden ist. Damit kann ein sehr typisches Szenario entstehen: DNS liefert korrekt eine IPv6-Adresse, aber der IPv6-Routingpfad ist gestört. Nutzer sehen dann „Website lädt nicht“, obwohl IPv4 noch funktionieren würde. Dieses Muster wird oft fälschlich als DNS-Problem interpretiert („DNS hat ja eine IP geliefert, also muss es stimmen“), obwohl es ein Routingproblem ist – nur eben auf IPv6.

• Indiz: AAAA vorhanden, A vorhanden, aber nur der IPv6-Zugriff hängt.
• Beweis: DNS ok, aber Traceroute/Ping/TCP-Connect zur IPv6-Adresse scheitert, während IPv4 klappt.
• Konsequenz: Routing-/Provider-/Firewall-Policy für IPv6 prüfen, nicht DNS.

Dokumentation: So beweisen Sie DNS vs. Routing im Ticket, ohne Diskussion

Im Betrieb zählt nicht nur die Diagnose, sondern die Nachvollziehbarkeit. Wenn Sie klar dokumentieren, was getestet wurde, welches Ergebnis kam und welche Schlussfolgerung daraus folgt, reduzieren Sie Rückfragen und beschleunigen die Zuständigkeit.

• Scope: Wer ist betroffen (Client/Standort/VLAN), seit wann, sporadisch oder konstant?
• DNS-Beweise: Resolver-IP, Antwortcode (NOERROR/NXDOMAIN/SERVFAIL/Timeout), A/AAAA-Ergebnis, Unterschiede je Resolver.
• Routing-Beweise: Ziel-IP, Ping/Traceroute-Ergebnis, Abbruchstelle, Default-Gateway-Erreichbarkeit.
• IPv4/IPv6 getrennt: Welche Adressfamilie ist betroffen, welche funktioniert?
• Konkrete Aussage: „DNS liefert NXDOMAIN bei Resolver X, bei Resolver Y funktioniert es“ oder „DNS liefert IP, aber Traceroute bricht am Edge ab“.

Quantifizierung: Fehlerquote als zusätzlicher Beweis (optional, aber hilfreich)

Wenn das Problem sporadisch ist, helfen Quoten: Wie oft scheitert DNS, wie oft scheitert die IP-Erreichbarkeit? Damit können Sie zwischen „einmaliger Ausreißer“ und „systemisches Problem“ unterscheiden und Provider-/Teamgespräche objektiver führen.

$\mathrm{Fehlerquote}=\frac{\mathrm{fehlgeschlageneTests}}{\mathrm{gesamtTests}}\times 100\%$

Praxisnahe Referenzen für saubere Analyse

Wenn Sie tiefer in Protokolldetails, DNS-Abläufe oder Paketanalysen einsteigen müssen, helfen zuverlässige Quellen. Für DNS-Grundlagen und Normen sind RFCs besonders belastbar, und für Mitschnitte ist Wireshark eine etablierte Referenz.

• RFC 1034 (DNS Konzepte)
• RFC-Editor (Netzwerkstandards)
• Wireshark-Dokumentation
• RIPE Atlas Messplattform

Wenn Sie diese Beweisführung konsequent anwenden, sind DNS- und Routing-Probleme nicht mehr „gefühlt ähnlich“, sondern klar trennbar: DNS ist dann belegt durch Antwortcodes, Resolver-Vergleiche und Namensauflösung; Routing ist belegt durch IP-Erreichbarkeit, Pfadindikatoren und reproduzierbare Abbruchstellen. Genau diese Trennung ist der schnellste Weg zu stabilen Lösungen – und zur richtigen Eskalation.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.