Zum Inhalt

DNS-Namensauflösungs-Architektur & Layer 1–7 Bottom-Up Troubleshooting unter Linux

Erstellt: 08.11.2026  ·  Zuletzt aktualisiert: 08.11.2026  ·  Nejat Hakan

Management Summary: Wenn eine Anwendung mit Connection timed out oder Temporary failure in name resolution abbricht, neigen unerfahrene Administratoren dazu, planlos Firewallregeln anzupassen oder Konfigurationsdateien zu verändern. Professionelles Systems Engineering verlangt eine deterministische Methodik: Das exakte Verständnis, wie die GNU C Library (glibc) Domänennamen über /etc/nsswitch.conf verarbeitet, wie Caching-Dienste wie systemd-resolved arbeiten, wie DNS-Hierarchien mit dig +trace auditiert werden und wie ein strenger Bottom-Up-Diagnosepfad von Schicht 1 bis Schicht 7 die wahre Fehlerursache in Minuten isoliert.

  • Das Linux-DNS-Subsystem

    Der vollständige Auflösungspfad: getaddrinfo()-Aufrufe, NSS-Reihenfolge in /etc/nsswitch.conf, /etc/hosts-Priorität und /etc/resolv.conf.

  • systemd-resolved beherrschen

    Den lokalen Stub-Resolver 127.0.0.53 verstehen, schnittstellenspezifische Suchdomänen prüfen, Caches leeren und Abfragen mit resolvectl steuern.

  • DNS-Hierarchietracing mit dig

    Vollständige Wurzelzonen-Traversierung (+trace), EDNS0-Puffergrößen, Reverse-DNS (PTR) und maschinenlesbare DNS-Ausgaben analysieren.

  • Layer 1–7 Runbook

    Deterministische Bottom-Up-Diagnosematrix: Vom physischen Link und ARP/NDP über Routing und Firewall-Drops bis hin zu fehlerhaften TLS-Handshakes.

1. Die Linux-DNS-Auflösungskette: Vom Funktionsaufruf zum Netzwerkpaket

Wenn ein Anwendungsprozess getaddrinfo("api.internal.corp") aufruft, ist der Linux-Kernel zunächst überhaupt nicht an der DNS-Auflösung beteiligt. Die Namensauflösung ist eine Funktion des User-Spaces, die von der GNU C Library (glibc) über den Name Service Switch (NSS) gesteuert wird:

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    APP["User-Space App<br/>getaddrinfo()"] --> NSS["1. /etc/nsswitch.conf<br/>files, resolve, dns"]
    NSS -->|"Zuerst: files"| HOSTS["2. /etc/hosts<br/>Statische Einträge"]
    HOSTS -->|"Gefunden"| SUCCESS["IP an App liefern"]
    HOSTS -->|"Nicht gefunden"| RESOLV["3. /etc/resolv.conf<br/>Stub oder Upstream-IP"]
    RESOLV --> RES["4. Lokaler Resolver<br/>systemd-resolved"]
    RES -->|"Cache Miss"| UPSTREAM["5. Upstream DNS<br/>Rekursiver Resolver"]
    UPSTREAM --> SUCCESS

Konfiguration von NSS: /etc/nsswitch.conf

Die Direktive hosts: bestimmt die Reihenfolge der Informationsquellen:

# Datei: /etc/nsswitch.conf (Typisches Debian mit systemd-resolved)
hosts:          files resolve [!UNAVAIL=return] dns myhostname
  • files: Überprüft zuerst statische Einträge in /etc/hosts. Wird hier ein Treffer erzielt, erfolgt keine DNS-Netzwerkabfrage.
  • resolve: Leitet die Anfrage an die D-Bus-Schnittstelle von systemd-resolved weiter.
  • [!UNAVAIL=return]: Wenn systemd-resolved aktiv ist und meldet, dass die Domäne nicht existiert, wird die Suche sofort beendet.
  • dns: Klassischer Fallback auf direkte DNS-Abfragen über die Nameserver aus /etc/resolv.conf.
  • myhostname: Löst den lokalen Hostnamen und Loopback-Adressen automatisch auf.

Auflösungsreihenfolge mit getent verifizieren

Verwende zur Diagnose niemals bloß ping oder nslookup. Nutze stattdessen getent, da dieser Befehl exakt dieselbe glibc-NSS-Logik verwendet wie echte Anwendungen: 

# Prüft den vollständigen NSS-Stack (/etc/hosts + systemd-resolved + DNS)
getent ahosts nejat-hakan.de

2. DNS-Verwaltung mit systemd-resolved auf Debian

Moderne Debian-Installationen nutzen systemd-resolved für lokales Caching, DNSSEC-Validierung und interfacespezifisches Routing.

Der lokale Stub-Resolver 127.0.0.53

Verweist /etc/resolv.conf auf die IP 127.0.0.53, wickelt systemd-resolved alle Anfragen lokal über eine Loopback-Schnittstelle ab:

# Symlink-Konfiguration überprüfen
ls -la /etc/resolv.conf
# Ausgabe: /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

Diagnose-Befehle mit resolvectl

# Globale und schnittstellenspezifische DNS-Server und DNSSEC-Status anzeigen
resolvectl status

# DNS-Abfrage über den resolved-Dienst ausführen (inkl. Latenz & DNSSEC-Prüfung)
resolvectl query nejat-hakan.de

# Lokalen DNS-Cache sofort leeren
sudo resolvectl flush-caches

# Cache-Statistiken abfragen (Hit-/Miss-Quote)
resolvectl statistics

3. Autoritative DNS-Diagnose mit dig

Das Werkzeug dig (Domain Information Groper) ist das wichtigste Werkzeug für die DNS-Fehleranalyse.

1. Präzise Abfragen & saubere Skriptausgaben

# Kompakte Abfrage für IPv4- (A) und IPv6-Adressen (AAAA)
dig +noall +answer nejat-hakan.de A nejat-hakan.de AAAA

# Bestimmte Record-Typen abfragen (MX, TXT, CNAME, SOA)
dig +short nejat-hakan.de MX
dig +short nejat-hakan.de TXT

# Reverse-DNS-Lookup (PTR) für eine IP-Adresse
dig +short -x 93.184.216.34

2. DNS-Hierarchietracing: dig +trace

Um DNS-Fehler oder Verzögerungen bei der weltweiten Zonen-Verteilung zu analysieren, umgehe lokale Zwischenspeicher und frage direkt von den Root-Servern an abwärts:

dig nejat-hakan.de +trace

Ablauf des Tracing-Pfads: 1. Fragt einen der 13 Root-Server-Cluster ([a-m].root-servers.net) nach der TLD .de. 2. Erhält die autoritativen DENIC-Nameserver ([a-z].denic.de). 3. Fragt DENIC nach den zuständigen Nameservern für nejat-hakan.de. 4. Ruft die endgültigen A- / AAAA-Records direkt von den autoritativen Servern der Domäne ab.

4. Das Layer 1 bis Layer 7 Bottom-Up Troubleshooting Runbook

Wenn ein Dienst nicht erreichbar ist, führt die Fehlersuche von oben nach unten (z. B. das Anpassen von Anwendungsconfigs) oft in die Irre. Diagnostiziere stets strikt Bottom-Up von Schicht 1 bis Schicht 7.

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    L1["Schicht 1: Link<br/>ethtool: Link erkannt?"] -->|OK| L2["Schicht 2: Nachbarn<br/>ip neigh: MAC aufgelöst?"]
    L2 -->|OK| L3["Schicht 3: IP-Routing<br/>ip route & ping Gateway"]
    L3 -->|OK| L4["Schicht 4: Transport<br/>nc -zv Port & ss -tulpn"]
    L4 -->|OK| L5["Schicht 5/6: TLS<br/>openssl s_client Zertifikat"]
    L5 -->|OK| L7["Schicht 7: App & DNS<br/>curl HTTP 200 & dig"]

5. Umfassende Diagnose- und Behebungsmatrix

Schicht Prüfschritt Diagnosebefehl Fehlersymptom Ursache & Behebung
Layer 1 Physischer Link sudo ethtool eth0 Link detected: no oder Speed: Unknown! Kabel nicht eingesteckt, defektes Patchkabel, Switchport deaktiviert oder Transceiver defekt.
Layer 2 Link-Status & Fehler ip -s link show dev eth0 state DOWN oder viele RX/TX errors / dropped Interface administrativ deaktiviert (sudo ip link set eth0 up) oder Duplex-Fehlkonfiguration am Switch.
Layer 2 Nachbar-ARP/NDP ip neigh show 192.168.1.1 dev eth0 FAILED oder INCOMPLETE Falsches VLAN am Switchport getaggt, falsche Subnetzmaske konfiguriert oder Gateway offline.
Layer 3 Standard-Gateway ip route show & ping -c 2 192.168.1.1 Network is unreachable oder Destination Host Unreachable Fehlende Default-Route (sudo ip route add default via 192.168.1.1) oder IP-Adresskonflikt im LAN.
Layer 3 WAN-Routing traceroute -n 1.1.1.1 oder mtr -n 1.1.1.1 Hops brechen beim Upstream-Provider ab (* * *) Störung beim Provider, BGP-Ausfall oder fehlendes NAT-Masquerading am WAN-Ausgang.
Layer 4 Lokale Port-Bindung sudo ss -tulpn \| grep :5432 Prozess taucht in der Ausgabe nicht auf Dienst ist abgestürzt, deaktiviert oder lauscht fälschlicherweise nur auf 127.0.0.1 statt auf 0.0.0.0.
Layer 4 Remote-Port / Firewall nc -zv 10.10.20.11 5432 Fall A: Connection timed out
Fall B: Connection refused		 Timed out: Paket wird von nftables/ufw lautlos verworfen.
Refused: Port wird erreicht, aber kein Dienst lauscht darauf.
Layer 6 TLS-Handshake openssl s_client -connect api.example.com:443 -servername api.example.com verify error:num=10:certificate has expired Abgelaufenes Zertifikat, fehlendes Intermediate-Zertifikat oder falscher SNI-Servername.
Layer 7 DNS-Namensauflösung dig +short api.example.com Temporary failure in name resolution Falscher nameserver in /etc/resolv.conf, Firewall blockiert UDP-Port 53 oder DNS-Ausfall.
Layer 7 HTTP-Anwendung curl -Iv https://api.example.com HTTP/1.1 502 Bad Gateway oder 504 Gateway Time-out Reverse-Proxy (Nginx/HAProxy) läuft, aber der Backend-Anwendungsdienst antwortet nicht.

6. Nächste Schritte: Wechsel zu Cluster 2

Herzlichen Glückwunsch! Du hast Cluster 1: Grundlagen & Kernprotokolle vollständig abgeschlossen. Im nächsten Schritt geht es an die Absicherung von Netzwerkperimetern, verschlüsselte Bastion-Hosts und moderne Firewalls:

  • Cluster 2: Kryptografische OpenSSH-Architektur & Bastions

    ED25519-Schlüsselmanagement, SSH-Härtung, Jump-Hosts (ProxyJump) und verschlüsseltes Port-Forwarding.

    Zum OpenSSH-Härtungs-Leitfaden