DNS gehört zu den Diensten, die im Hintergrund so selbstverständlich funktionieren, dass man sie im normalen Betrieb kaum bemerkt. Fällt die Namensauflösung jedoch aus oder liefert falsche Informationen, wirkt plötzlich die halbe Infrastruktur kaputt.

DNS ist selten spektakulär – aber wenn es nicht funktioniert, sehen sehr viele andere Systeme plötzlich ebenfalls kaputt aus.

Was DNS eigentlich macht

DNS – das Domain Name System – übersetzt Namen in Informationen, die Computer für die Kommunikation benötigen.

Das bekannteste Beispiel ist die Zuordnung eines Hostnamens zu einer IP-Adresse:

server01.example.local
        ↓
10.20.30.15

Im Internet funktioniert das nach demselben Prinzip:

nolden.tech
     ↓
IPv4- oder IPv6-Adresse

DNS besteht allerdings aus wesentlich mehr als nur der Zuordnung eines Namens zu einer IPv4-Adresse.

  • A – IPv4-Adresse eines Hosts
  • AAAA – IPv6-Adresse
  • CNAME – Alias auf einen anderen DNS-Namen
  • MX – zuständiger Mailserver einer Domain
  • TXT – Textinformationen, beispielsweise für SPF oder Domain-Verifikation
  • PTR – Reverse-DNS-Zuordnung einer IP-Adresse zu einem Namen
  • SRV – beschreibt Dienste inklusive Port und Priorität
  • NS – zuständige Nameserver einer Zone

Gerade in Windows-Domänen spielen SRV-Records zusätzlich eine wichtige Rolle. Active Directory nutzt DNS beispielsweise, damit Clients Domain Controller, Kerberos-Dienste und LDAP-Endpunkte finden können.

DNS ist deshalb nicht einfach nur ein „Telefonbuch für IP-Adressen“. Es ist ein fundamentaler Bestandteil moderner Infrastruktur.

Warum DNS-Probleme so verwirrend wirken

Das Gemeine an DNS ist: Ein DNS-Fehler sieht häufig überhaupt nicht wie ein DNS-Fehler aus.

Angenommen, ein Webserver läuft unter:

10.10.20.50

und soll über folgenden Namen erreichbar sein:

intranet.example.local

Folgendes funktioniert:

ping 10.10.20.50

aber:

ping intranet.example.local

schlägt fehl.

Der Server selbst kann dabei vollkommen gesund sein. Auch Routing und Netzwerkverbindung können einwandfrei funktionieren. Vielleicht läuft sogar der Webserver ohne jeden Fehler.

Lediglich die Namensauflösung funktioniert nicht.

Für den Benutzer lautet das Ergebnis trotzdem:

„Das Intranet ist kaputt.“

Aus Sicht des Servers stimmt das gar nicht. Aus Sicht des Benutzers aber sehr wohl.

Genau deshalb sollte man beim Troubleshooting versuchen, die einzelnen Schichten voneinander zu trennen.

Der erste wichtige Test: Name oder Netzwerk?

Eine der einfachsten Fragen bei einem vermeintlichen Netzwerkproblem lautet:

Funktioniert der Dienst über die IP-Adresse?

Wenn beispielsweise:

https://intranet.example.local

nicht funktioniert, kann ein Test gegen die IP-Adresse bereits sehr viel verraten.

Ist der Host über seine IP erreichbar, über seinen Namen aber nicht, verschiebt sich der Verdacht deutlich in Richtung Namensauflösung.

Wichtig: Das bedeutet noch nicht automatisch, dass der DNS-Server selbst defekt ist. DNS besteht aus mehreren Komponenten – Client-Konfiguration, Resolver, Cache, Zonen, Records, Weiterleitungen und gegebenenfalls lokalen Überschreibungen.

Mögliche Ursachen sind beispielsweise:

  • falscher DNS-Server am Client
  • fehlender DNS-Record
  • falscher oder veralteter DNS-Record
  • veralteter Resolver-Cache
  • Split-DNS
  • falscher DNS-Suffix
  • fehlerhafte Weiterleitungen
  • mehrere DNS-Server mit unterschiedlichen Informationen
  • VPN oder virtuelle Adapter verändern die Resolver-Konfiguration
  • IPv4 und IPv6 liefern unterschiedliche Ziele
  • lokale Hosts-Einträge überschreiben DNS

Welchen DNS-Server benutzt der Client überhaupt?

Bevor ich DNS-Records untersuche, möchte ich zuerst wissen, welchen Resolver der betroffene Client tatsächlich verwendet.

Windows

Get-DnsClientServerAddress

Alternativ klassisch:

ipconfig /all

Linux

Bei Systemen mit systemd-resolved:

resolvectl status

oder:

resolvectl dns

Je nach System kann außerdem hilfreich sein:

cat /etc/resolv.conf

Dabei sollte man berücksichtigen, dass /etc/resolv.conf auf modernen Linux-Systemen teilweise lediglich auf einen lokalen Resolver verweist.

Die entscheidende Frage lautet nicht: „Welchen DNS-Server sollte der Client verwenden?“ sondern: „Welchen DNS-Server fragt dieser Client tatsächlich?“

Gerade bei VPN-Verbindungen, mehreren Netzwerkadaptern, Docker, Hyper-V oder virtuellen Maschinen kann die Antwort überraschend sein.

DNS gezielt abfragen

Anschließend kann der betroffene Name gezielt geprüft werden.

Windows

Resolve-DnsName server01.example.local

Gezielt gegen einen bestimmten DNS-Server:

Resolve-DnsName server01.example.local -Server 10.0.0.10

Linux

dig server01.example.local

Oder gezielt gegen einen Resolver:

dig @10.0.0.10 server01.example.local

Auch nslookup ist auf vielen Systemen weiterhin vorhanden:

nslookup server01.example.local

Besonders interessant ist der Vergleich zwischen der normalen Client-Auflösung und einer direkten Anfrage an den erwarteten DNS-Server.

Angenommen:

dig server01.example.local

liefert keine brauchbare Antwort, während:

dig @10.0.0.10 server01.example.local

sofort die richtige Adresse liefert.

Dann kann der DNS-Server den Namen offensichtlich auflösen. Der Client verwendet möglicherweise nur nicht den erwarteten Resolver oder erreicht diesen nicht korrekt.

Damit ist das Problem bereits deutlich enger eingegrenzt.

DNS-Cache: hilfreich und manchmal nervig

DNS wäre wesentlich langsamer, wenn jede Anfrage jedes Mal vollständig neu aufgelöst werden müsste. Deshalb werden Antworten zwischengespeichert.

Genau dieser Cache kann bei Änderungen allerdings irritieren.

Ein Record wurde beispielsweise geändert von:

10.0.0.20

auf:

10.0.0.30

Der DNS-Server liefert bereits die neue Adresse, während ein Client noch die alte Antwort verwendet.

Windows

Cache anzeigen:

ipconfig /displaydns

Cache leeren:

ipconfig /flushdns

Linux mit systemd-resolved

sudo resolvectl flush-caches
Nicht reflexartig löschen: Ein Cache kann selbst ein wertvoller Hinweis sein. Interessanter ist zunächst, welche Antwort gespeichert ist und welche Antwort der zuständige DNS-Server aktuell liefert.

TTL – wie lange darf DNS sich etwas merken?

DNS-Records besitzen eine TTL – Time to Live. Sie bestimmt, wie lange ein Resolver eine Antwort zwischenspeichern darf.

Beispielsweise:

nolden.tech.  3600  IN  A  203.0.113.10

Eine TTL von 3600 entspricht einer Stunde.

Wird die IP-Adresse geändert, kann ein Resolver die alte Information bis zum Ablauf dieser TTL weiterhin verwenden.

Das ist besonders bei geplanten Migrationen relevant.

Ein sinnvolles Vorgehen kann beispielsweise sein:

  1. TTL rechtzeitig vor der Migration reduzieren.
  2. Alte TTL auslaufen lassen.
  3. DNS-Änderung durchführen.
  4. Funktion und Erreichbarkeit prüfen.
  5. TTL später wieder auf einen normalen Wert erhöhen.

DNS-Änderungen brauchen also nicht zwangsläufig „ewig“. Entscheidend ist, wie Caching und TTL konfiguriert sind.

Wenn DNS-Server unterschiedliche Antworten liefern

Besonders unangenehm sind Fehler, bei denen mehrere Resolver nicht denselben Informationsstand besitzen.

DNS-Server 1:

server01.example.local → 10.0.0.20

DNS-Server 2:

server01.example.local → 10.0.0.30

Der Client verwendet beide:

10.0.0.10
10.0.0.11

Das Problem kann dadurch scheinbar zufällig auftreten.

  • Mal funktioniert der Dienst.
  • Mal nicht.
  • Nach einem Neustart funktioniert es plötzlich.
  • Später tritt derselbe Fehler erneut auf.

Das sieht schnell nach einem instabilen Netzwerk, einem defekten Server oder einem Anwendungsproblem aus.

Dabei liefern lediglich zwei Resolver unterschiedliche Informationen.

Linux

dig @10.0.0.10 server01.example.local
dig @10.0.0.11 server01.example.local

Windows

Resolve-DnsName server01.example.local -Server 10.0.0.10
Resolve-DnsName server01.example.local -Server 10.0.0.11

Die Antworten sollten nachvollziehbar zusammenpassen.

Die hosts-Datei: der kleine DNS-Troll

Manchmal funktioniert DNS vollkommen korrekt und trotzdem erhält ein Rechner die falsche Adresse.

Dann lohnt sich ein Blick in die lokale Hosts-Datei.

Windows

C:\Windows\System32\drivers\etc\hosts

Linux

/etc/hosts

Dort könnte beispielsweise noch stehen:

10.0.0.20 server01.example.local

Während DNS inzwischen korrekt liefert:

10.0.0.30

Je nach Betriebssystem und Anwendung kann der lokale Eintrag Vorrang haben.

Dann bringt auch ein DNS-Flush nichts. Der DNS-Server kann vollkommen korrekt funktionieren, während der Client ihn für diesen Namen möglicherweise gar nicht fragt.

Nicht jeder Auflösungstest testet dasselbe

Ein weiterer Punkt wird beim Troubleshooting gerne übersehen: 

dig server01.example.local

und:

ping server01.example.local

müssen technisch nicht zwangsläufig exakt denselben Auflösungsweg verwenden.

dig fragt DNS relativ direkt ab. Anwendungen und Betriebssystemfunktionen verwenden dagegen häufig den systemweiten Resolver.

Unter Linux kann deshalb zusätzlich interessant sein:

getent hosts server01.example.local

Damit kann beispielsweise auch die Name Service Switch-Konfiguration berücksichtigt werden.

Wenn dig die richtige Adresse liefert, die Anwendung aber weiterhin die falsche verwendet, ist DNS damit noch nicht automatisch vollständig ausgeschlossen.

Wenn A funktioniert, aber AAAA Ärger macht

IPv6 ist ebenfalls ein interessanter Kandidat.

Ein Host besitzt beispielsweise:

A     → 192.0.2.10
AAAA  → 2001:db8::10

IPv4 funktioniert. Der AAAA-Record zeigt aber möglicherweise auf einen nicht erreichbaren Server oder der IPv6-Pfad ist fehlerhaft.

Dadurch können manche Clients problemlos funktionieren, während andere Fehler zeigen.

Linux

dig A example.com
dig AAAA example.com

Windows

Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA

Wenn ein Problem nur auf einzelnen Geräten auftritt, gehört der Vergleich von IPv4 und IPv6 deshalb für mich relativ früh ins Troubleshooting.

DNS und Active Directory

In einer Windows-Domäne wird DNS noch wichtiger.

Active Directory verwendet DNS nicht nur, um Domain Controller mit einer IP-Adresse zu verbinden. Clients suchen unter anderem über SRV-Records nach bestimmten Diensten.

Eine solche Abfrage kann beispielsweise aussehen:

Resolve-DnsName _ldap._tcp.dc._msdcs.example.local -Type SRV

Fehlen solche Records oder verwenden Clients externe Resolver statt der vorgesehenen internen DNS-Server, entstehen teilweise sehr merkwürdige Symptome:

  • Anmeldungen dauern ungewöhnlich lange
  • Gruppenrichtlinien werden nicht korrekt angewendet
  • Domänenbeitritt schlägt fehl
  • Domain Controller werden nicht gefunden
  • Kerberos funktioniert nicht erwartungsgemäß
  • Dienste wirken sporadisch unerreichbar
Typischer Fehler: Ein Domain-Client bekommt direkt einen öffentlichen Resolver wie 8.8.8.8 oder 1.1.1.1 eingetragen. Öffentliche Domains funktionieren dann zwar, interne AD-Records kennt dieser Resolver jedoch nicht.

Domain-Clients sollten normalerweise die dafür vorgesehenen internen DNS-Server verwenden. Diese können externe Anfragen anschließend über Forwarder oder eine entsprechende rekursive Auflösung weiterbearbeiten.

„Ping geht“ beweist erstaunlich wenig

Beim Troubleshooting hört man häufig:

„Ping funktioniert, also ist das Netzwerk okay.“

So einfach ist es leider nicht.

Ping beziehungsweise ICMP zeigt zunächst nur, dass genau diese Art der Kommunikation funktioniert.

Ein Webserver benötigt möglicherweise TCP/443. DNS verwendet üblicherweise Port 53 und kann sowohl UDP als auch TCP benötigen.

Ein erfolgreicher Ping beweist deshalb nicht:

  • dass DNS funktioniert
  • dass HTTPS funktioniert
  • dass die Anwendung läuft
  • dass der benötigte Port erreichbar ist
  • dass eine Firewall den Dienst erlaubt

Umgekehrt bedeutet ein fehlgeschlagener Ping ebenfalls nicht automatisch, dass ein Host nicht erreichbar ist.

ICMP kann bewusst blockiert sein.

Deshalb teste ich möglichst den Dienst, der tatsächlich benötigt wird.

Mein DNS-Troubleshooting in der Praxis

Wenn ich vermute, dass die Namensauflösung beteiligt ist, gehe ich ungefähr in dieser Reihenfolge vor:

  1. Symptom eingrenzen: Welcher Name funktioniert nicht und auf welchen Clients tritt das Problem auf?
  2. IP-Konnektivität prüfen: Ist der Zielhost beziehungsweise der benötigte Dienst grundsätzlich erreichbar?
  3. Konfigurierte Resolver prüfen: Welche DNS-Server verwendet der Client tatsächlich?
  4. DNS-Namen normal auflösen: Welche Antwort bekommt der Client?
  5. Resolver direkt abfragen: Antworten die zuständigen DNS-Server gleich?
  6. A und AAAA vergleichen: Gibt es unterschiedliche IPv4- und IPv6-Ziele?
  7. Cache kontrollieren: Wird möglicherweise eine alte Antwort verwendet?
  8. Hosts-Datei prüfen: Existiert eine lokale Überschreibung?
  9. DNS-Suffix und Suchdomänen prüfen: Besonders relevant bei kurzen Hostnamen und VPN-Verbindungen.
  10. Dienst selbst testen: Eine korrekte DNS-Antwort bedeutet noch nicht, dass der Zielservice tatsächlich funktioniert.
  11. Erst danach Änderungen durchführen: Nicht direkt DNS-Dienste neu starten oder Records verändern, bevor klar ist, wo das Problem liegt.
Erst beobachten und eingrenzen, dann verändern.

Ein kleines Praxisbeispiel

Angenommen: 

https://wiki.example.local

ist auf einem Windows-Client nicht erreichbar.

Zuerst prüfe ich die Namensauflösung:

Resolve-DnsName wiki.example.local

Ergebnis:

10.20.30.50

Anschließend teste ich den benötigten Port:

Test-NetConnection 10.20.30.50 -Port 443

TCP/443 antwortet.

Damit wissen wir bereits:

  • Der Zielhost ist erreichbar.
  • Der benötigte Port antwortet.
  • Der Netzwerkpfad funktioniert grundsätzlich.

Nun:

Test-NetConnection wiki.example.local -Port 443

Wenn auch dieser Test erfolgreich ist, liegt das ursprüngliche Problem wahrscheinlich nicht an DNS oder am grundlegenden Netzwerkpfad.

Liefert Resolve-DnsName dagegen beispielsweise: 

10.20.30.40

obwohl der aktuelle Server unter 10.20.30.50 erreichbar ist, haben wir einen sehr konkreten Ansatzpunkt.

Das ist der Unterschied zwischen:

„Die Webseite geht nicht.“

und:

„Der Client erhält für wiki.example.local einen veralteten A-Record.“

Mit der zweiten Aussage kann man arbeiten.

Was ich bei DNS-Problemen nicht sofort mache

Einige Maßnahmen versuche ich bewusst nicht als erste Reaktion:

  • wahllos DNS-Caches leeren
  • Netzwerkadapter deaktivieren und wieder aktivieren
  • DNS-Server neu starten
  • Records löschen und neu anlegen
  • Firewallregeln verändern
  • DHCP-Konfigurationen ändern
  • einfach einen öffentlichen DNS-Server eintragen

Solche Maßnahmen können zufällig helfen.

Das Problem daran: Danach weiß man häufig nicht, warum es funktioniert hat.

Beim nächsten Auftreten beginnt die Suche wieder von vorne.

Interessanter ist für mich:

Welche Anfrage wurde gestellt, welcher Resolver hat geantwortet und welche Antwort wurde tatsächlich verwendet?

Damit wird aus Herumprobieren echte Fehleranalyse.

Fazit

DNS gehört zu den Technologien, die man im Alltag kaum bemerkt, solange sie funktionieren.

Genau deshalb können Fehler in der Namensauflösung so irritierend sein.

Server, Netzwerk und Anwendung können vollkommen gesund sein – und für den Benutzer funktioniert trotzdem nichts, weil bereits der Name nicht korrekt zum Ziel führt.

Der beste Ansatz ist deshalb nicht:

„DNS kaputt – Cache löschen.“

Sondern:

Welchen Namen möchte ich auflösen, welchen Resolver frage ich, welche Antwort erhalte ich und stimmt diese Antwort mit meiner Umgebung überein?

Wer diese Fragen beantworten kann, hat viele vermeintlich komplizierte Netzwerkprobleme bereits erheblich eingegrenzt.

Und ja: Manchmal ist es wirklich DNS.

← Zurück zu allen Artikeln