6.3 IP-Adresse erreichbar, Name nicht – DNS- und Namensauflösungsfehler

Wenn ein Ziel über seine IP-Adresse erreichbar ist, der Zugriff über den Namen jedoch scheitert, funktioniert die grundlegende IP-Kommunikation wahrscheinlich. Der Fehler liegt dann häufig bei der Namensauflösung, ihrer Konfiguration oder einem davon abhängigen Dienst.

Typische Meldungen sind:

Die Aussage „IP geht, Name geht nicht“ grenzt den Fehlerbereich ein. Sie beweist aber noch nicht, dass ausschließlich der DNS-Server defekt ist.

1. Technischer Zusammenhang

Anwendungen verwenden häufig Namen statt IP-Adressen.

Benutzer oder Anwendung
        ↓
fragt nach server.example.test
        ↓
Namensauflösung
        ↓
liefert eine IP-Adresse
        ↓
Verbindung zur IP-Adresse

Beispiel:

intranet.example.test → 192.0.2.40

Kann der Client 192.0.2.40 erreichen, den Namen intranet.example.test jedoch nicht auflösen, müssen insbesondere folgende Bereiche untersucht werden:

2. Fehlerbild zuerst bestätigen

Die Benutzeraussage muss durch konkrete Tests bestätigt werden.

Zu dokumentieren sind:

Beispiel:

Name: fileserver.example.test
IP-Adresse: 192.0.2.40
IP-Adresse erreichbar: ja
Name auflösbar: nein
DNS-Server: 192.0.2.10
Betroffener Client: PC-023
Vergleichsclient: PC-024 funktioniert

Ein Test mit einer IP-Adresse muss denselben Zielsystem- und Netzwerkpfad sinnvoll prüfen. Der Aufruf irgendeiner erreichbaren IP-Adresse ist kein ausreichender Vergleich.

3. IP-Erreichbarkeit und Namensauflösung getrennt prüfen

Zuerst wird geprüft, ob das Ziel grundsätzlich per IP erreichbar ist.

Windows

ping <ip-adresse>
Test-NetConnection <ip-adresse>
Test-NetConnection <ip-adresse> -Port <port>

Linux und macOS

ping <ip-adresse>
traceroute <ip-adresse>
nc -vz <ip-adresse> <port>

Danach wird derselbe Dienst über den Namen getestet.

Windows

ping <name>
Resolve-DnsName <name>
Test-NetConnection <name> -Port <port>

Linux und macOS

ping <name>
dig <name>
host <name>
nslookup <name>

Mögliche Einordnung

Ergebnis mögliche Einordnung
IP und Name funktionieren Fehler liegt möglicherweise bei Anwendung, Port, Authentifizierung oder zeitweiligem Zustand
IP funktioniert, Name wird nicht aufgelöst Namensauflösung untersuchen
Name wird korrekt aufgelöst, Verbindung scheitert Zieladresse, Port, Firewall, Routing oder Anwendung untersuchen
IP und Name scheitern grundlegende IP-Verbindung, Routing, Firewall oder Zielsystem untersuchen
Name liefert eine falsche IP-Adresse DNS-Daten, Cache, Hosts-Datei oder Split-DNS untersuchen
nur der Kurzname scheitert DNS-Suffix oder Suchliste untersuchen
vollständiger Name und Kurzname scheitern DNS-Server, Zone, Record oder Transport untersuchen

Eine erfolgreiche Namensauflösung beweist nicht, dass der Zielservice erreichbar ist. Sie bestätigt zunächst nur, dass eine Antwort für den Namen geliefert wurde.

4. Vollständigen Namen verwenden

Bei der Fehlersuche sollte zwischen Kurzname und Fully Qualified Domain Name unterschieden werden.

Beispiel:

Kurzname:
fileserver

Vollständiger Name:
fileserver.example.test

Funktioniert der vollständige Name, der Kurzname jedoch nicht, sind häufig folgende Bereiche betroffen:

Windows

ipconfig /all
Get-DnsClientGlobalSetting
Get-DnsClient

Linux

cat /etc/resolv.conf
resolvectl status

macOS

scutil --dns

Zu prüfen sind:

5. Konfigurierte DNS-Server prüfen

Ein Client muss die vorgesehenen DNS-Server verwenden.

Windows

ipconfig /all
Get-DnsClientServerAddress

Linux

resolvectl status
cat /etc/resolv.conf
nmcli device show

macOS

scutil --dns
networksetup -getdnsservers <netzwerkdienst>

Zu prüfen sind:

In einer Active-Directory-Umgebung dürfen Clients für interne AD-Namen normalerweise nicht ausschließlich beliebige öffentliche DNS-Resolver verwenden. Ein öffentlicher Resolver kennt die internen DNS-Zonen nicht.

6. Jeden DNS-Server einzeln abfragen

Sind mehrere DNS-Server eingetragen, muss jeder Server gezielt getestet werden.

Windows

Resolve-DnsName <name> -Server <dns-server-1>
Resolve-DnsName <name> -Server <dns-server-2>

Alternativ:

nslookup <name> <dns-server-1>
nslookup <name> <dns-server-2>

Linux und macOS

dig @<dns-server-1> <name>
dig @<dns-server-2> <name>

Beispielhafte Auswertung

DNS-Server 1 DNS-Server 2 mögliche Einordnung
richtige Antwort richtige Antwort DNS-Server grundsätzlich konsistent
richtige Antwort keine Antwort zweiter Server, Netzwerkpfad oder Firewall
richtige Antwort falsche Antwort abweichende Zone, Replikation oder veraltete Daten
keine Antwort keine Antwort Erreichbarkeit, Dienst, Firewall oder Clientkonfiguration
NXDOMAIN richtige Antwort inkonsistente Zonen oder verschiedene DNS-Sichten
unterschiedliche IP-Adressen möglicherweise Split-DNS, Replikationsfehler oder abweichende Records

Ein Client wechselt nicht in jedem Fall zum nächsten DNS-Server, nur weil der erste Server eine fachlich falsche Antwort liefert. Eine erhaltene negative oder falsche Antwort ist etwas anderes als ein nicht antwortender Server.

7. Bedeutung häufiger DNS-Ergebnisse

DNS-Abfragen können unterschiedliche Rückmeldungen liefern.

Ergebnis Bedeutung möglicher Untersuchungsbereich
NOERROR mit Antwort Name wurde beantwortet zurückgegebene Daten auf Richtigkeit prüfen
NOERROR ohne passende Antwort Name oder Typ besitzt möglicherweise keinen entsprechenden Record Record-Typ, Zone oder Alias prüfen
NXDOMAIN angefragter Name existiert aus Sicht des antwortenden Servers nicht Schreibweise, Zone, Record, Cache oder falscher DNS-Server
SERVFAIL Server konnte die Anfrage nicht erfolgreich bearbeiten DNSSEC, Delegation, Upstream-Server oder Serverfehler
REFUSED Server verweigert die Anfrage Richtlinie, Rekursion, ACL oder nicht erlaubter Client
Zeitüberschreitung keine rechtzeitige DNS-Antwort Erreichbarkeit, Port 53, Überlastung oder Dienst
falsche IP-Adresse Antwort vorhanden, aber ungeeignet Record, Cache, Hosts-Datei, Split-DNS oder Replikation
CNAME ohne erreichbares Endziel Alias vorhanden, Zielname problematisch CNAME-Kette und Zielzone untersuchen

Die Meldung NXDOMAIN bedeutet nicht automatisch, dass der gesamte DNS-Dienst ausgefallen ist. Der Server hat geantwortet, kennt den angefragten Namen jedoch nicht.

8. Record-Typ gezielt prüfen

DNS enthält verschiedene Resource Records.

Typ Aufgabe
A Name zu IPv4-Adresse
AAAA Name zu IPv6-Adresse
CNAME Alias auf einen anderen Namen
PTR IP-Adresse zu Name bei Rückwärtsauflösung
MX zuständiger Mailserver
NS autoritativer Nameserver einer Zone
SOA Verwaltungsinformationen einer Zone
SRV Dienst und zuständiger Server
TXT Textinformationen, Prüf- und Richtliniendaten

Windows

Resolve-DnsName <name> -Type A
Resolve-DnsName <name> -Type AAAA
Resolve-DnsName <name> -Type CNAME
Resolve-DnsName <domain> -Type NS
Resolve-DnsName <domain> -Type SOA
Resolve-DnsName <dienstname> -Type SRV

Linux und macOS

dig A <name>
dig AAAA <name>
dig CNAME <name>
dig NS <domain>
dig SOA <domain>
dig SRV <dienstname>

Wenn eine Anwendung einen bestimmten Record-Typ benötigt, reicht die erfolgreiche Abfrage eines anderen Typs nicht aus.

Beispielsweise können Active-Directory-Dienste von SRV-Records abhängig sein. Ein vorhandener A-Record des Domain Controllers beweist nicht, dass alle benötigten SRV-Records korrekt vorhanden sind.

9. DNS-Transport und Port 53 prüfen

DNS verwendet grundsätzlich:

UDP wird häufig für normale Abfragen verwendet. TCP kann unter anderem bei größeren, abgeschnittenen oder bestimmten serverseitigen Übertragungen erforderlich sein.

Zu prüfen sind:

Windows

Test-NetConnection <dns-server> -Port 53

Dieser Test prüft TCP Port 53. Er ersetzt keine Prüfung von UDP-DNS.

Linux und macOS

dig @<dns-server> <name>
dig +tcp @<dns-server> <name>

Mögliche Beobachtungen

Beobachtung mögliche Einordnung
UDP-Abfrage funktioniert, TCP-Abfrage scheitert Firewall oder Dienstkonfiguration für TCP 53
kleine Antworten funktionieren, größere nicht TCP-Fallback, Fragmentierung, EDNS oder MTU
Anfrage verlässt Client, keine Antwort sichtbar DNS-Server, Rückweg oder Filter
Antwort erreicht Netzwerkschnittstelle, Anwendung erhält sie nicht lokale Firewall, Resolver oder Sicherheitssoftware
DNS-Server ist per IP erreichbar, Port 53 antwortet nicht Dienst, Firewall oder falsche Zieladresse

10. Lokalen DNS-Cache prüfen

Clients und Resolver speichern DNS-Antworten für eine bestimmte Zeit. Auch negative Antworten können zwischengespeichert werden.

Mögliche Symptome:

Windows

ipconfig /displaydns
Clear-DnsClientCache

Alternativ:

ipconfig /flushdns

Linux mit systemd-resolved

resolvectl statistics
sudo resolvectl flush-caches

macOS

Die verwendeten Cache-Mechanismen können von der macOS-Version und dem aktiven Resolver abhängen. Vor einer Cache-Bereinigung sollte deshalb zuerst geprüft werden, ob eine direkte DNS-Abfrage bereits die korrekte Antwort liefert.

Das Leeren des Cache ist eine Prüf- oder Korrekturmaßnahme für zwischengespeicherte Daten. Es behebt keine fehlenden Records, falschen Zonen oder nicht erreichbaren DNS-Server.

11. Hosts-Datei berücksichtigen

Vor oder neben DNS können lokale Namensquellen eine Rolle spielen. Eine fehlerhafte Hosts-Datei kann DNS-Ergebnisse überlagern.

Windows

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

Linux und macOS

/etc/hosts

Zu prüfen sind:

Die Hosts-Datei sollte nicht ungeprüft als dauerhafte Ersatzlösung für einen fehlerhaften DNS-Eintrag verwendet werden. Dadurch würde die zentrale Ursache verborgen und eine schwer wartbare Sonderkonfiguration geschaffen.

12. Zuständige Zone und autoritative Server prüfen

Für einen internen Namen muss die zuständige DNS-Zone vorhanden und auf den vorgesehenen Servern verfügbar sein.

Zu prüfen sind:

Windows-DNS-Server

Get-DnsServerZone
Get-DnsServerResourceRecord -ZoneName <zone>
Get-DnsServerForwarder

Allgemeine Abfragen

dig NS <domain>
dig SOA <domain>
dig +trace <domain>

dig +trace zeigt eine schrittweise Auflösung über die DNS-Hierarchie. Für rein interne Zonen ist dieser Test nicht in derselben Weise geeignet wie für öffentlich delegierte Zonen.

13. Rekursion und Weiterleitungen prüfen

Ein interner DNS-Server kennt nicht automatisch alle externen Namen. Er verwendet je nach Konfiguration:

Mögliche Fehlerbilder:

Abgrenzung

Ergebnis möglicher Bereich
interne und externe Namen scheitern Client, DNS-Server, Dienst oder Transport
interne Namen funktionieren, externe nicht Rekursion, Forwarder, Root Hints oder Firewall
externe Namen funktionieren, interne nicht interne Zone, falscher DNS-Server oder Split-DNS
nur eine Partnerdomäne scheitert Conditional Forwarder, Delegation oder Partner-DNS
nur einzelne Records fehlen Zone, Replikation oder Record-Verwaltung

14. Split-DNS berücksichtigen

Bei Split-DNS kann derselbe Name abhängig vom verwendeten DNS-Server oder Standort unterschiedliche Antworten liefern.

Beispiel:

intern:
portal.example.test → 192.0.2.50

extern:
portal.example.test → 198.51.100.50

Zu prüfen sind:

Ein korrekt funktionierender öffentlicher DNS-Eintrag beweist nicht, dass der interne Eintrag korrekt ist.

15. VPN und mehrere Netzwerkschnittstellen

VPN-Verbindungen können DNS-Einstellungen gezielt verändern.

Mögliche Fehlerbilder:

Zu prüfen sind:

Windows

Get-NetIPConfiguration
Get-DnsClient
Get-DnsClientServerAddress
Get-NetRoute

Linux

ip address
ip route
resolvectl status

macOS

ifconfig
netstat -rn
scutil --dns

16. IPv4 und IPv6 getrennt betrachten

Ein Name kann sowohl einen A- als auch einen AAAA-Record besitzen.

Mögliche Fehlerbilder:

Zu prüfen sind:

Resolve-DnsName <name> -Type A
Resolve-DnsName <name> -Type AAAA

dig A <name>
dig AAAA <name>
ping -4 <name>
ping -6 <name>

Das pauschale Deaktivieren von IPv6 ist keine fachgerechte Standardlösung. Zuerst muss bestätigt werden, ob tatsächlich ein fehlerhafter AAAA-Record, IPv6-DNS-Server oder IPv6-Datenpfad vorliegt.

17. DNSSEC prüfen

DNSSEC ermöglicht die Prüfung signierter DNS-Daten. Fehler bei Signaturen oder Vertrauenskette können zu SERVFAIL führen.

Mögliche Ursachen:

Linux und macOS mit dig

dig +dnssec <name>
dig +trace <name>

Bei DNSSEC-Problemen sollten geprüft werden:

DNSSEC darf nicht pauschal deaktiviert werden, ohne den Fehler einzugrenzen und die Sicherheitsauswirkung zu bewerten.

18. Browser und verschlüsseltes DNS

Ein Browser oder eine Sicherheitsanwendung kann einen eigenen DNS-Auflösungsweg verwenden, beispielsweise DNS over HTTPS.

Mögliche Beobachtungen:

Zu prüfen sind:

Ein funktionierender Kommandozeilentest beweist daher nicht in jedem Fall, dass die betroffene Anwendung denselben Resolver und dieselben DNS-Daten verwendet.

19. mDNS, LLMNR und NetBIOS nicht mit DNS verwechseln

Kurznamen und lokale Gerätenamen können abhängig vom Betriebssystem auch über andere Verfahren aufgelöst werden.

Mögliche Verfahren:

Wenn ein Kurzname funktioniert, ist damit nicht automatisch bewiesen, dass DNS funktioniert. Der Name könnte über ein anderes Verfahren aufgelöst worden sein.

Für eine eindeutige DNS-Prüfung sollten gezielte Werkzeuge verwendet werden:

Resolve-DnsName <vollständiger-name> -Server <dns-server>

dig @<dns-server> <vollständiger-name>

20. Reverse DNS getrennt prüfen

Die Rückwärtsauflösung ordnet einer IP-Adresse einen Namen zu. Dafür werden PTR-Records verwendet.

Beispiel:

192.0.2.40 → fileserver.example.test

Windows

Resolve-DnsName <ip-adresse> -Type PTR

Linux und macOS

dig -x <ip-adresse>

Eine fehlende Rückwärtsauflösung verhindert nicht grundsätzlich jede Verbindung zur IP-Adresse. Bestimmte Anwendungen, Protokollierungen, Authentifizierungsverfahren oder Sicherheitsprüfungen können jedoch von einem korrekten PTR-Record abhängen.

Vorwärts- und Rückwärtsauflösung sind deshalb getrennt zu prüfen.

21. Active Directory und DNS

Active Directory ist stark von DNS abhängig.

DNS-Fehler können unter anderem beeinträchtigen:

Benötigt werden unter anderem SRV-Records.

Beispielhafte Prüfung:

Resolve-DnsName _ldap._tcp.dc._msdcs.<domain> -Type SRV
Resolve-DnsName _kerberos._tcp.<domain> -Type SRV

Zu prüfen sind:

22. Dynamische DNS-Registrierung

Clients und Server können ihre Records dynamisch registrieren.

Mögliche Fehlerbilder:

Windows-Client

ipconfig /registerdns

Vor der Verwendung ist zu prüfen:

ipconfig /registerdns ist keine Lösung für einen falsch eingerichteten DNS-Server oder eine fehlende Zone.

23. Zeitabhängige und sporadische Fehler

Sporadische Namensauflösungsfehler können entstehen durch:

Sinnvoll sind wiederholte, zeitgestempelte Abfragen.

PowerShell

1..10 | ForEach-Object {
    Get-Date
    Resolve-DnsName <name> -Server <dns-server>
    Start-Sleep -Seconds 2
}

Bash

for i in {1..10}; do
    date
    dig @<dns-server> <name>
    sleep 2
done

Zu vergleichen sind:

24. Paketaufzeichnung für DNS

Eine Paketaufzeichnung kann zeigen:

Wireshark-Filter

dns
udp.port == 53
tcp.port == 53
dns.qry.name == "<name>"
ip.addr == <dns-server>

Typische Beobachtungen

Paketaufzeichnung mögliche Einordnung
keine DNS-Anfrage Anwendungscache, Hosts-Datei, anderer Resolver oder Anwendung sendet nicht
Anfrage an falschen Server Client-, DHCP-, VPN- oder Schnittstellenkonfiguration
Anfrage, keine Antwort Server, Transport, Firewall oder Rückweg
Antwort NXDOMAIN Server kennt den Namen nicht
Antwort SERVFAIL serverseitige Auflösung, DNSSEC oder Delegation
richtige Antwort, Anwendung scheitert Cache, Anwendung, Zielservice oder Datenpfad
wiederholte Anfragen an mehrere Server Antwortausfall oder Zeitüberschreitung
UDP-Antwort abgeschnitten, TCP scheitert TCP Port 53, Firewall oder MTU

Paketaufzeichnungen dürfen nur mit entsprechender Berechtigung erstellt und müssen geschützt gespeichert werden.

25. Praxisfall A: Nur ein Client kann einen internen Namen nicht auflösen

Symptom

Prüfung

  1. DNS-Server des betroffenen Clients prüfen.
  2. mit funktionierendem Client vergleichen.
  3. vollständigen Namen gezielt abfragen.
  4. jeden eingetragenen DNS-Server einzeln testen.
  5. DNS-Cache prüfen.
  6. Hosts-Datei kontrollieren.
  7. VPN- und Schnittstellenkonfiguration prüfen.
  8. Paketaufzeichnung bei Bedarf durchführen.

Mögliche Ursache

Der Client verwendet aufgrund einer statischen Alt-Konfiguration einen öffentlichen DNS-Server. Dieser kann die interne Zone nicht auflösen.

Nachprüfung

26. Praxisfall B: Interne Namen funktionieren, externe Namen nicht

Symptom

Prüfung

  1. DNS-Server direkt abfragen.
  2. interne und externe Namen vergleichen.
  3. allgemeine Forwarder prüfen.
  4. Erreichbarkeit der Forwarder untersuchen.
  5. Rekursion und Root Hints kontrollieren.
  6. Firewallregeln für UDP und TCP Port 53 prüfen.
  7. Serverprotokolle auswerten.
  8. DNSSEC-Fehler ausschließen.

Mögliche Ursache

Der interne DNS-Server kann interne Zonen selbst beantworten. Der konfigurierte Forwarder für externe Namen ist jedoch nicht mehr erreichbar.

Nachprüfung

27. Praxisfall C: Vollständiger Name funktioniert, Kurzname nicht

Symptom

fileserver.example.test → funktioniert
fileserver → funktioniert nicht

Prüfung

  1. DNS-Suffixsuchliste anzeigen.
  2. verbindungsspezifisches Suffix prüfen.
  3. DHCP-Optionen kontrollieren.
  4. VPN-Konfiguration untersuchen.
  5. mit funktionierendem Client vergleichen.
  6. tatsächlich angefragte Namen in einer Paketaufzeichnung prüfen.

Mögliche Ursache

Nach einer DHCP-Änderung wird das interne DNS-Suffix nicht mehr an neue Clients verteilt.

Nachprüfung

28. Praxisfall D: Einige Clients erhalten eine falsche IP-Adresse

Symptom

Prüfung

  1. beide DNS-Server einzeln abfragen.
  2. Records und TTL vergleichen.
  3. Zone und Replikationszustand prüfen.
  4. Cache auf Clients und Resolvern berücksichtigen.
  5. Hosts-Dateien ausschließen.
  6. Split-DNS-Konfiguration prüfen.
  7. Anwendung nach Korrektur erneut testen.

Mögliche Ursache

Ein DNS-Server besitzt aufgrund einer Replikationsstörung noch einen alten A-Record.

Nachprüfung

29. Praxisfall E: DNS-Abfrage funktioniert, Browser nicht

Symptom

Prüfung

  1. Ergebnis des Systemresolvers dokumentieren.
  2. Browser-DNS-Konfiguration prüfen.
  3. verwendeten verschlüsselten Resolver bestimmen.
  4. Browsercache berücksichtigen.
  5. Proxy- und Sicherheitsrichtlinien kontrollieren.
  6. vollständigen Namen im Browser testen.

Mögliche Ursache

Der Browser sendet DNS-over-HTTPS-Abfragen an einen öffentlichen Resolver, der die interne Zone nicht kennt.

Nachprüfung

30. Ungeeignete Sofortmaßnahmen

Problematisch sind insbesondere:

Vor Änderungen sind zu sichern beziehungsweise zu dokumentieren:

31. Vollständige Prüfreihenfolge

  1. exakten betroffenen Namen erfassen.
  2. Kurzname und vollständigen Namen unterscheiden.
  3. bekannte Ziel-IP-Adresse dokumentieren.
  4. Ziel per IP-Adresse und benötigtem Port prüfen.
  5. denselben Dienst über den Namen testen.
  6. Fehlermeldung und Zeitpunkt dokumentieren.
  7. betroffene und funktionierende Clients vergleichen.
  8. konfigurierte DNS-Server feststellen.
  9. jeden DNS-Server einzeln abfragen.
  10. Antwortcode und zurückgegebene Records bewerten.
  11. A- und AAAA-Records getrennt prüfen.
  12. DNS-Suffix und Suchliste kontrollieren.
  13. lokale Hosts-Datei prüfen.
  14. Cache nur nach Dokumentation berücksichtigen.
  15. Erreichbarkeit des DNS-Servers prüfen.
  16. UDP und TCP Port 53 berücksichtigen.
  17. zuständige Zone und Record untersuchen.
  18. autoritative Server und Delegation prüfen.
  19. Replikation zwischen DNS-Servern kontrollieren.
  20. Rekursion, Forwarder oder Conditional Forwarder untersuchen.
  21. Split-DNS und aktuellen Standort berücksichtigen.
  22. VPN und mehrere Schnittstellen prüfen.
  23. anwendungseigene Resolver oder verschlüsseltes DNS berücksichtigen.
  24. bei Bedarf eine autorisierte Paketaufzeichnung erstellen.
  25. konkrete Hypothese formulieren.
  26. genau eine kontrollierbare Änderung durchführen.
  27. DNS-Abfrage erneut testen.
  28. ursprüngliche Anwendung erneut testen.
  29. interne und externe Namen prüfen.
  30. zweiten DNS-Server und Vergleichsclient prüfen.
  31. Ursache, Maßnahme und Ergebnis dokumentieren.
  32. Monitoring oder Präventionsmaßnahme festlegen.

32. Dokumentationsbeispiel

Ticket: INC-20631
Beginn: 02.08.2026, etwa 10:35 Uhr
Umfang: neu verbundene VPN-Clients
Betroffen: interne Servernamen
Nicht betroffen: externe DNS-Namen und direkte IP-Verbindungen

Symptom:
Der Server fileserver.example.test ist über 192.0.2.40 erreichbar.
Der Name kann auf betroffenen VPN-Clients nicht aufgelöst werden.

Ausgangszustand:
- VPN-Tunnel aktiv
- Route zum internen Server vorhanden
- Server per IP und TCP Port 445 erreichbar
- externe Namen werden aufgelöst
- betroffene Clients verwenden einen öffentlichen DNS-Server
- interne DNS-Server werden vom VPN nicht bereitgestellt
- funktionierende interne Clients verwenden 192.0.2.10 und 192.0.2.11

Hypothese:
Die VPN-Konfiguration übermittelt nicht die für interne Zonen
zuständigen DNS-Server.

Prüfung:
- Resolve-DnsName über Standardkonfiguration liefert NXDOMAIN
- direkte Abfrage an 192.0.2.10 liefert 192.0.2.40
- interne DNS-Server sind durch den Tunnel erreichbar
- VPN-Profil besitzt keine DNS-Serverzuweisung
- Änderung des VPN-Profils zum Fehlerzeitpunkt festgestellt

Ursache:
Bei einer Änderung des VPN-Profils wurden die internen DNS-Server
und die interne Suchdomäne nicht übernommen.

Maßnahme:
Interne DNS-Server und Suchdomäne nach Freigabe wieder in das
VPN-Profil aufgenommen.

Nachprüfung:
- vollständiger interner Name wird korrekt aufgelöst
- Kurzname funktioniert über die vorgesehene Suchdomäne
- Dateidienst ist über den Namen erreichbar
- externe Namensauflösung funktioniert
- erneuter VPN-Verbindungsaufbau erfolgreich
- zweiter DNS-Server geprüft
- mehrere VPN-Clients erfolgreich getestet

Prävention:
- DNS-Funktion in den VPN-Abnahmetest aufnehmen
- interne und externe Testnamen überwachen
- Änderungen an VPN-Profilen durch Peer-Review prüfen

33. Checkliste „Name geht nicht, IP geht“

34. Schnellreferenz

Fehlerbild wahrscheinlicher Untersuchungsbereich
IP funktioniert, vollständiger Name nicht DNS-Server, Zone, Record oder DNS-Transport
vollständiger Name funktioniert, Kurzname nicht DNS-Suffix oder Suchliste
interne Namen funktionieren, externe nicht Forwarder, Rekursion, Root Hints oder Firewall
externe Namen funktionieren, interne nicht falscher DNS-Server, interne Zone oder Split-DNS
nur ein Client betroffen Clientkonfiguration, Cache, Hosts-Datei oder Anwendung
alle Clients betroffen zentraler DNS-Dienst, Zone, Netzwerkpfad oder Firewall
nur VPN-Clients betroffen VPN-DNS, Suchdomäne, Route oder Split-DNS
ein DNS-Server liefert falsche Daten Zone, Replikation oder veralteter Record
NXDOMAIN Name aus Sicht des antwortenden Servers nicht vorhanden
SERVFAIL Serververarbeitung, Delegation, Forwarder oder DNSSEC
Zeitüberschreitung Erreichbarkeit, Port 53, Überlastung oder Rückweg
richtige IP wird geliefert, Dienst scheitert kein reiner DNS-Fehler; Port, Firewall, Anwendung oder Zielsystem
A funktioniert, AAAA führt zum Fehler IPv6-Record oder IPv6-Datenpfad
Kommandozeile funktioniert, Browser nicht Browsercache, Proxy oder verschlüsseltes DNS
wechselnde Antworten mehrere DNS-Server, Round-Robin, Split-DNS oder Replikation
Reverse Lookup scheitert PTR-Record oder Reverse-Lookup-Zone

Merksatz

Wenn die IP-Adresse funktioniert, der Name aber nicht, wird die Namensauflösung gezielt und schichtweise geprüft: verwendeter DNS-Server, vollständiger Name, Antwortcode, Record, Zone, Weiterleitung und tatsächlicher Resolver. Eine erreichbare IP-Adresse grenzt den Fehler ein, beweist aber weder einen DNS-Server-Ausfall noch die Funktionsfähigkeit des angesprochenen Dienstes.

Quellen und weiterführende Dokumentation

Revision #1
Created 1 August 2026 22:24:40 by Admin
Updated 2 August 2026 12:21:27 by Admin