# DNS Troubleshooting: Dem Fehler auf der Spur

TL;DR / Management Summary DNS-Probleme sind die häufigste Ursache für “Netzwerkstörungen”. In modernen Linux-Systemen reicht es nicht mehr, in /etc/resolv.conf zu schauen. Wir müssen verstehen, wie der Stub-Resolver (systemd-resolved) arbeitet und wie wir mit Tools wie dig, resolvectl und drill die Kette von der Applikation bis zum autoritativen Nameserver verifizieren.

# 1. Einführung & Architektur

Die DNS-Kette.

Wenn eine Applikation google.com auflösen will, geht die Anfrage durch mehrere Schichten. Jeder Punkt in dieser Kette kann eine Fehlerquelle sein (Cache, Firewall, falscher Server).

graph TD
    A[Applikation] --> B[glibc /etc/nsswitch.conf]
    B --> C[systemd-resolved 127.0.0.53]
    C --> D[Upstream Local Cache]
    D --> E[Recursive Resolver ISP/Cloud]
    E --> F[Authoritative Root Nameservers]

# 2. Das Werkzeug des Meisters: resolvectl

Das chirurgische Besteck für systemd-resolved.

Da systemd-resolved den DNS verwaltet, ist resolvectl das wichtigste Tool.

# Abfragen simulieren

# Was sieht das System?
resolvectl query intern.company.com

# Statistiken & Cache

# Wie effizient ist der Cache?
resolvectl statistics

# Cache leeren (Erste Amtshandlung bei Fehlern!)
sudo resolvectl flush-caches

# 3. dig: Der Goldstandard

Rohe DNS-Pakete analysieren.

dig (Domain Information Groper) fragt direkt DNS-Server ab und umgeht lokale Caches.

# Die wichtigsten Flags

# Standard-Abfrage (A-Record)
dig google.com

# Bestimmten Server fragen (Cloudflare)
dig @1.1.1.1 google.com

# MX-Records (Mail) prüfen
dig google.com MX

# Reverse Lookup (IP zu Name)
dig -x 8.8.8.8

# 4. Split-DNS und Multicast DNS (mDNS)

Wenn lokale Namen nicht aufgelöst werden.

# Split-DNS (VPN-Szenario)

Oft sollen Namen wie *.intern über den VPN-Tunnel aufgelöst werden, aber alles andere über das lokale Internet.

# Prüfen, welche Domains auf welchen Link geroutet werden
resolvectl domain

# mDNS / Avahi

In kleinen Netzen ohne DNS-Server nutzen Linux-Systeme oft .local Adressen via mDNS.

# Finden eines anderen Linux-Nodes im Netz
getent hosts node1.local

# 5. Troubleshooting & “War Stories”

Praxiserfahrung.

# Story 1: “Der falsche Cache-Hit”

Symptom: IP-Adresse eines Webservers wurde geändert, aber der Linux-Server sendet Traffic immer noch an die alte IP. dig zeigt die neue IP, aber ping nutzt die alte. Ursache: systemd-resolved hat einen positiven Cache-Eintrag mit langer TTL (Time-To-Live). Lösung: resolvectl flush-caches.

# Story 2: “DNS-Loop durch mDNS”

Symptom: Massive Last auf dem DNS-Server, Anfragen für .local Domains fluten das Netz. Ursache: Eine Fehlkonfiguration in /etc/nsswitch.conf, bei der mdns4_minimal vor dns steht, kombiniert mit einem Unicast-DNS-Server, der sich für .local zuständig fühlt. Lösung: .local sollte niemals im öffentlichen Unicast-DNS genutzt werden! Nutzen Sie .intern oder .lan.

# 6. Fazit & Empfehlung

• Reihenfolge: Erst resolvectl query (System-Sicht), dann dig (Netzwerk-Sicht).
• Kein nslookup: nslookup ist veraltet und verhält sich manchmal anders als das OS. Nutzen Sie dig.
• Logging: Bei hartnäckigen Problemen tcpdump -i eth0 port 53 nutzen, um zu sehen, ob Pakete den Server überhaupt verlassen.

# Anhang: Cheatsheet