7.11 DNS-Leistung und fehlerhafte Reverse-Lookups

Kurz erklärt

Eine DNS-Abfrage kann grundsätzlich funktionieren und trotzdem langsam sein. Ebenso beweist ein fehlender Reverse-Lookup nicht automatisch, dass die normale Namensauflösung gestört ist.

Für eine saubere Diagnose müssen Abfragerichtung, verwendeter DNS-Server, Antwortcode, Antwortzeit, Cachezustand, Rekursion, Weiterleitung, Transportweg und Zonenverantwortung getrennt untersucht werden.

7.11.1 Ziel der Diagnose

Bei DNS-Leistungsproblemen müssen folgende Fragen beantwortet werden:

Ziel ist nicht nur eine erfolgreiche Einzelabfrage, sondern eine reproduzierbare und ausreichend schnelle Namensauflösung über den vorgesehenen DNS-Pfad.

7.11.2 Typische Störungsbilder

7.11.3 Vorwärts- und Rückwärtsauflösung unterscheiden

Abfragerichtung Eingabe Gesuchter Datensatz Ergebnis
Vorwärtsauflösung IPv4 Hostname A IPv4-Adresse
Vorwärtsauflösung IPv6 Hostname AAAA IPv6-Adresse
Rückwärtsauflösung IPv4 IPv4-Adresse PTR unter in-addr.arpa Hostname
Rückwärtsauflösung IPv6 IPv6-Adresse PTR unter ip6.arpa Hostname

Beispiel:

host25.example.test → 192.0.2.25

Dies ist eine Vorwärtsauflösung über einen A-Eintrag.

192.0.2.25 → host25.example.test

Dies ist eine Rückwärtsauflösung über einen PTR-Eintrag.

A-, AAAA- und PTR-Einträge sind getrennte DNS-Datensätze in unterschiedlichen Zonen. Ein vorhandener A- oder AAAA-Eintrag erzeugt deshalb nicht automatisch einen PTR-Eintrag, sofern kein entsprechend konfigurierter Aktualisierungsprozess vorhanden ist.

7.11.4 Aufbau einer IPv4-Rückwärtsauflösung

Für IPv4 werden die Oktette der Adresse umgekehrt und mit in-addr.arpa ergänzt.

Beispiel:

192.0.2.25

Daraus entsteht der Abfragename:

25.2.0.192.in-addr.arpa.

Der zugehörige PTR-Eintrag kann auf folgenden Namen zeigen:

host25.example.test.

Für das Netz 192.0.2.0/24 lautet die typische Reverse-Lookup-Zone:

2.0.192.in-addr.arpa

Der Knoten für die Adresse 192.0.2.25 lautet innerhalb dieser Zone:

25

Bei Adressbereichen, die nicht an einer Oktettgrenze delegiert werden, kann eine klassenlose Delegation nach RFC 2317 erforderlich sein. Der Zonenaufbau darf dann nicht allein aus der Subnetzmaske abgeleitet werden, sondern muss mit der tatsächlichen Delegation des Adressbereichs übereinstimmen.

7.11.5 Aufbau einer IPv6-Rückwärtsauflösung

IPv6-Rückwärtsauflösungen verwenden die Zone ip6.arpa.

Dabei wird:

  1. die IPv6-Adresse vollständig ausgeschrieben;
  2. jede Hexadezimalstelle einzeln betrachtet;
  3. die Reihenfolge aller Hexadezimalstellen umgekehrt;
  4. zwischen jeder Stelle ein Punkt eingefügt;
  5. ip6.arpa angehängt.

Die Delegation erfolgt auf Basis einzelner Hexadezimalstellen, sogenannter Nibbles. Eine IPv6-Reverse-Zone muss deshalb anhand des tatsächlich delegierten IPv6-Präfixes erstellt werden.

IPv6-Reverse-Namen dürfen nicht durch einfaches Umkehren der durch Doppelpunkte getrennten Adressblöcke gebildet werden.

7.11.6 Bedeutung eines fehlenden Reverse-Lookups

Ein fehlender PTR-Eintrag bedeutet zunächst nur, dass für die IP-Adresse kein entsprechender Name über Reverse-DNS ermittelt werden konnte.

Das beweist nicht automatisch:

Reverse-Lookups werden unter anderem verwendet von:

Eine Anwendung kann bei einem fehlenden PTR-Eintrag ohne Verzögerung weiterarbeiten. Eine deutliche Verzögerung entsteht eher dann, wenn die Reverse-Abfrage nicht eindeutig negativ beantwortet wird, sondern in Timeouts, fehlerhaften Delegationen oder nicht erreichbaren DNS-Servern endet.

7.11.7 nslookup zeigt den DNS-Server als „Unknown“

Eine typische Ausgabe kann folgendermaßen aussehen:

Server:  UnKnown
Address: 192.0.2.53

Das bedeutet häufig, dass für die IP-Adresse des verwendeten DNS-Servers kein auflösbarer PTR-Eintrag vorhanden ist.

Diese Meldung beweist nicht, dass der DNS-Server keine anderen Anfragen beantworten kann.

Zur Abgrenzung müssen kontrollierte Abfragen durchgeführt werden:

nslookup host25.example.test 192.0.2.53

nslookup 192.0.2.25 192.0.2.53

PTR des DNS-Servers selbst prüfen:

nslookup 192.0.2.53 192.0.2.53

Wenn die erste Abfrage erfolgreich ist, funktioniert die getestete Vorwärtsauflösung trotz der Anzeige Unknown. Der fehlende PTR-Eintrag des DNS-Servers bleibt dennoch ein zu prüfender Konfigurationsbefund.

7.11.8 DNS-Antworten richtig einordnen

Ergebnis Bedeutung Einordnung
NOERROR mit Antwort Abfrage wurde erfolgreich beantwortet Datensatz und Inhalt prüfen
NOERROR ohne gesuchten Datensatz Name kann existieren, der angefragte Datensatztyp fehlt häufig als NODATA bezeichnet
NXDOMAIN abgefragter DNS-Name existiert laut DNS-Antwort nicht Zone, Name und negative Zwischenspeicherung prüfen
SERVFAIL Server konnte keine verwertbare Antwort erzeugen Weiterleitung, Delegation, DNSSEC und Serverprotokolle prüfen
REFUSED Server lehnt die Abfrage aufgrund seiner Konfiguration oder Richtlinie ab Rekursion, ACL, Richtlinie und Abfragequelle prüfen
FORMERR DNS-Nachricht konnte nicht korrekt verarbeitet werden Client, Server, Netzwerkgerät und Paketformat prüfen
Timeout innerhalb der Wartezeit kam keine verwertbare Antwort Netzwerk, Transport, Serverlast und nachgelagerte Server prüfen
Antwort mit TC UDP-Antwort wurde abgeschnitten erneuter Versuch über TCP erforderlich
falsche Adresse oder falscher PTR DNS antwortet, aber mit unerwarteten Daten Zone, Replikation, Cache und Datensatz prüfen

Ein Timeout ist kein DNS-Antwortcode. Er bedeutet, dass der Client innerhalb seiner Wartezeit keine verwendbare DNS-Antwort erhalten hat.

7.11.9 Ausgangszustand dokumentieren

Vor Änderungen sind mindestens folgende Informationen zu erfassen:

DNS-Caches dürfen nicht gelöscht werden, bevor der ursprüngliche Cachezustand und die fehlerhafte Antwort dokumentiert wurden.

7.11.10 Verwendete DNS-Konfiguration prüfen

Windows

ipconfig /all

Get-DnsClientServerAddress

Get-DnsClient

Linux

cat /etc/resolv.conf

Bei Systemen mit systemd-resolved zusätzlich:

resolvectl status

macOS

scutil --dns

Zu prüfen sind:

Die Datei /etc/resolv.conf kann bei dynamisch verwalteten Linux-Systemen nur auf einen lokalen Stub-Resolver verweisen. Bei systemd-resolved muss deshalb zusätzlich dessen tatsächliche Schnittstellenkonfiguration geprüft werden.

7.11.11 Lokale Namensquellen und Resolverpfad berücksichtigen

Eine Anwendung muss nicht zwingend direkt den konfigurierten DNS-Server abfragen. Je nach Betriebssystem und Anwendung können vorher oder zusätzlich verwendet werden:

Hosts-Dateien:

Betriebssystem Pfad
Windows C:\Windows\System32\drivers\etc\hosts
Linux /etc/hosts
macOS /etc/hosts

Eine erfolgreiche Anwendungssuche beweist nicht, dass DNS verwendet wurde. Umgekehrt beweist eine erfolgreiche direkte DNS-Abfrage nicht, dass die Anwendung denselben Resolverpfad benutzt.

7.11.12 Split-DNS, VPN und NRPT prüfen

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

Beispiel:

app.example.test → interne IP über Unternehmens-DNS
app.example.test → öffentliche IP über öffentlichen DNS

Unter Windows können VPN-Profile über die Name Resolution Policy Table festlegen, welche Namensräume an bestimmte DNS-Server gesendet werden.

Wirksame NRPT-Richtlinien anzeigen:

Get-DnsClientNrptPolicy

Konfigurierte NRPT-Regeln anzeigen:

Get-DnsClientNrptRule

Zu prüfen sind:

nslookup verwendet für solche Tests nicht zwingend denselben Windows-Resolverpfad wie Anwendungen, die die Windows-DNS-API und NRPT nutzen. Für die Prüfung von NRPT sollte deshalb zusätzlich Resolve-DnsName verwendet werden.

7.11.13 Verschlüsseltes DNS mit DoH und DoT abgrenzen

DNS over HTTPS und DNS over TLS verändern den Transportweg der DNS-Abfrage.

Dadurch können klassische Tests über UDP- oder TCP-Port 53 erfolgreich sein, obwohl der verschlüsselte DNS-Pfad fehlschlägt – oder umgekehrt.

Windows-DNS-Clientzustand anzeigen:

netsh dnsclient show state

Globale Einstellungen anzeigen:

netsh dnsclient show global

Konfigurierte verschlüsselte DNS-Server anzeigen:

netsh dnsclient show encryption

Zu prüfen sind:

Für die DNS-Serverrolle unterstützt Microsoft DoH ab Windows Server 2025 mit dem in der Microsoft-Bereitstellungsdokumentation genannten Sicherheitsupdate KB5094125 vom Juni 2026 oder einem späteren Update.

Serverkonfiguration auf einem unterstützten System anzeigen:

Get-DnsServerEncryptionProtocol

DoH schützt den Transport zwischen DoH-Client und DNS-Server. Nachgelagerte Abfragen an Forwarder oder autoritative DNS-Server, Zonentransfers und dynamische Updates werden dadurch nicht automatisch verschlüsselt.

DoH und DNSSEC erfüllen unterschiedliche Aufgaben:

7.11.14 Vorwärtsauflösung gezielt testen

Windows PowerShell

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

AAAA-Eintrag:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type AAAA `
  -Server "192.0.2.53" `
  -DnsOnly

Windows Eingabeaufforderung

nslookup host25.example.test 192.0.2.53

Linux und macOS

dig @192.0.2.53 host25.example.test A

dig @192.0.2.53 host25.example.test AAAA

Entscheidend ist, den DNS-Server ausdrücklich anzugeben. Andernfalls können unterschiedliche Resolver, VPN-Regeln oder Cachezustände zu nicht vergleichbaren Ergebnissen führen.

7.11.15 Rückwärtsauflösung gezielt testen

Windows PowerShell

Resolve-DnsName `
  -Name "192.0.2.25" `
  -Type PTR `
  -Server "192.0.2.53" `
  -DnsOnly

Windows Eingabeaufforderung

nslookup 192.0.2.25 192.0.2.53

Linux und macOS

dig @192.0.2.53 -x 192.0.2.25

Kompakte Ausgabe mit Antwort und Statistik:

dig @192.0.2.53 -x 192.0.2.25 +noall +answer +comments +stats

Direkte Abfrage des vollständigen Reverse-Namens:

dig @192.0.2.53 25.2.0.192.in-addr.arpa PTR

Zu dokumentieren sind:

7.11.16 A-, AAAA-, CNAME-, PTR- und SRV-Probleme abgrenzen

Datensatz Aufgabe Typischer Fehler
A Name zu IPv4-Adresse falsche oder veraltete IPv4-Adresse
AAAA Name zu IPv6-Adresse falsche oder nicht erreichbare IPv6-Adresse
CNAME Alias zu anderem DNS-Namen fehlerhaftes Ziel oder lange Alias-Kette
PTR IP-Adresse zu Name fehlender, falscher oder veralteter Reverse-Eintrag
SRV Dienst zu Zielhost und Port falsches Ziel, falscher Port oder fehlender Zielhost

CNAME prüfen:

Resolve-DnsName `
  -Name "alias.example.test" `
  -Type CNAME `
  -Server "192.0.2.53" `
  -DnsOnly

SRV prüfen:

Resolve-DnsName `
  -Name "_service._tcp.example.test" `
  -Type SRV `
  -Server "192.0.2.53" `
  -DnsOnly

Mit dig:

dig @192.0.2.53 alias.example.test CNAME

dig @192.0.2.53 _service._tcp.example.test SRV

Bei CNAME- und SRV-Datensätzen muss zusätzlich geprüft werden, ob der zurückgegebene Zielname über A oder AAAA auflösbar und anschließend über den angegebenen Dienstport erreichbar ist.

Ein erfolgreicher SRV-Lookup beweist nicht, dass der veröffentlichte Dienst erreichbar ist.

7.11.17 Antwortzeit reproduzierbar messen

Ein einzelner Messwert reicht nicht aus. Mindestens folgende Fälle müssen getrennt betrachtet werden:

Linux und macOS

dig zeigt die DNS-Abfragezeit als Query time an:

dig @192.0.2.53 host25.example.test A +stats

TCP erzwingen:

dig @192.0.2.53 host25.example.test A +tcp +stats

Windows PowerShell

Measure-Command {
    Resolve-DnsName `
      -Name "host25.example.test" `
      -Type A `
      -Server "192.0.2.53" `
      -DnsOnly
}

TCP erzwingen:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly `
  -TcpOnly

Measure-Command misst den gesamten PowerShell-Befehlsablauf und nicht ausschließlich die reine DNS-Übertragungszeit. Die Werte eignen sich deshalb vor allem zum kontrollierten Vergleich unter denselben Bedingungen.

7.11.18 Kalte und zwischengespeicherte Abfragen unterscheiden

Eine erste rekursive Abfrage kann langsamer sein, weil der DNS-Server weitere Server kontaktieren muss. Eine Wiederholung kann aus einem Cache beantwortet werden.

Beobachtung Mögliche Einordnung
erste Abfrage langsam, Wiederholung schnell Server-, Client- oder Anwendungscache wirkt
jede Abfrage langsam Netzwerk, Serverlast, Weiterleitung oder autoritativen Pfad prüfen
nur nicht vorhandene Namen langsam negative Antworten, fehlerhafte Delegation oder Timeoutpfad prüfen
nur externe Namen langsam Rekursion, Forwarder oder Internetpfad prüfen
nur interne Namen langsam interne Zone, Delegation, AD-Replikation oder Standort prüfen
nur Reverse-Lookups langsam Reverse-Zone, Delegation und PTR-Pfad prüfen
autoritativer Server schnell, rekursiver Server langsam Rekursion, Cache oder Forwarder prüfen
UDP langsam oder fehlerhaft, TCP erfolgreich Firewall, Fragmentierung, EDNS oder Netzwerkpfad prüfen

Ein schneller Cachetreffer beweist nicht, dass der vollständige rekursive beziehungsweise autoritative Pfad funktioniert.

7.11.19 Windows-DNS-Clientcache prüfen

Cacheinhalt anzeigen:

ipconfig /displaydns

Alternativ:

Get-DnsClientCache

Zu prüfen sind:

Cache löschen:

Clear-DnsClientCache

Alternativ:

ipconfig /flushdns

Das Löschen des Clientcaches verändert den Ausgangszustand. Es darf erst nach Dokumentation und nur als kontrollierter Vergleich erfolgen.

7.11.20 TTL und negative Zwischenspeicherung berücksichtigen

Die TTL bestimmt, wie lange ein Datensatz zwischengespeichert werden darf.

Eine sehr niedrige TTL kann:

Eine sehr hohe TTL kann:

Auch negative Antworten werden zwischengespeichert. Deshalb kann ein Name nach dem nachträglichen Anlegen des Datensatzes zunächst weiterhin als nicht vorhanden erscheinen.

Zu prüfen sind:

Caches dürfen nicht routinemäßig geleert werden, um eine falsche TTL- oder Zonenplanung dauerhaft zu umgehen.

7.11.21 DNS über UDP und TCP abgrenzen

Klassische DNS-Abfragen verwenden häufig UDP-Port 53. TCP-Port 53 wird unter anderem benötigt:

Windows-TCP-Test:

Test-NetConnection "192.0.2.53" -Port 53

Dieser Befehl prüft ausschließlich TCP. Er beweist nicht, dass UDP-Port 53 funktioniert.

Ein echter UDP-DNS-Test erfolgt durch eine normale DNS-Abfrage:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Vergleich über TCP:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly `
  -TcpOnly

Wenn UDP-Abfragen scheitern und TCP-Abfragen funktionieren, sind unter anderem Firewallregeln, Paketverlust, Fragmentierung, EDNS-Verarbeitung, MTU und zwischengeschaltete Netzwerkgeräte zu prüfen.

7.11.22 EDNS, MTU, Fragmentierung und DNSSEC prüfen

EDNS ermöglicht unter anderem größere DNS-Antworten über UDP. Auf Netzwerkpfaden mit ungeeigneter MTU oder fehlerhafter Fragmentbehandlung können deshalb kleine Abfragen funktionieren, während größere Antworten ausfallen.

Typische Hinweise:

DNSSEC-Daten anfordern:

Resolve-DnsName `
  -Name "example.com" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly `
  -DnssecOk

Mit dig:

dig @192.0.2.53 example.com A +dnssec

Vergleich über TCP:

dig @192.0.2.53 example.com A +dnssec +tcp

EDNS testweise unterdrücken:

dig @192.0.2.53 example.com A +noedns

Zu beachten ist:

7.11.23 Autoritative Antwort, Rekursion und Weiterleitung unterscheiden

Ein DNS-Server kann eine Antwort liefern:

Für eine saubere Diagnose sind mindestens drei Ebenen zu vergleichen:

  1. Abfrage über den vom Client verwendeten DNS-Server;
  2. Abfrage über einen alternativen vorgesehenen DNS-Server;
  3. Abfrage über den autoritativen DNS-Server der betroffenen Zone.

Wenn der autoritative Server schnell und korrekt antwortet, der rekursive Server jedoch langsam ist, liegt die Ursache wahrscheinlich bei Rekursion, Cache, Weiterleitung oder Delegationspfad.

7.11.24 Delegation der Reverse-Zone prüfen

Für eine Rückwärtsauflösung muss die DNS-Hierarchie auf den zuständigen autoritativen Server verweisen.

Linux und macOS

dig -x 192.0.2.25 +trace

Zuständige Nameserver der Reverse-Zone prüfen:

dig 2.0.192.in-addr.arpa NS

Zu prüfen sind:

Eine lokal erstellte Reverse-Zone ersetzt bei öffentlichen Adressen nicht die Delegation durch den Eigentümer beziehungsweise Provider des IP-Adressbereichs.

7.11.25 Private und öffentliche Reverse-Zonen unterscheiden

Private IP-Adressen

Für interne private Netze kann die Organisation die Reverse-Zonen auf ihren internen DNS-Servern verwalten.

Zu prüfen sind:

Öffentliche IP-Adressen

Der PTR-Eintrag einer öffentlichen IP-Adresse wird normalerweise durch den Betreiber verwaltet, dem der entsprechende Adressbereich delegiert wurde.

Ein PTR-Eintrag für eine öffentliche IP-Adresse kann daher nicht allein dadurch veröffentlicht werden, dass in der normalen Forward-Zone der eigenen Domain ein Datensatz angelegt wird.

Zu klären sind:

7.11.26 Vorwärts- und Rückwärtskonsistenz prüfen

Beispiel für einen konsistenten Zustand:

host25.example.test. A 192.0.2.25

25.2.0.192.in-addr.arpa. PTR host25.example.test.

Anschließend wird der PTR-Zielname wieder vorwärts aufgelöst:

host25.example.test. A 192.0.2.25

Prüfschritte:

  1. IP-Adresse rückwärts auflösen.
  2. PTR-Zielnamen dokumentieren.
  3. PTR-Zielnamen über A und AAAA auflösen.
  4. Prüfen, ob die ursprüngliche IP-Adresse in den Ergebnissen enthalten ist.
  5. Alle beteiligten autoritativen DNS-Server vergleichen.

Mögliche Befunde:

Befund Einordnung
kein PTR vorhanden Reverse-Eintrag fehlt oder Zone ist nicht erreichbar
PTR zeigt auf alten Hostnamen veralteter Datensatz
PTR-Zielname existiert nicht unvollständige DNS-Konfiguration
PTR-Zielname zeigt auf andere IP Vorwärts- und Rückwärtsdaten stimmen nicht überein
mehrere PTR-Einträge technisch möglich, kann Anwendungen jedoch unterschiedlich beeinflussen
mehrere A- oder AAAA-Adressen kann bei Clustern, Load Balancing oder Mehrfachanbindung vorgesehen sein
verschiedene DNS-Server liefern verschiedene PTR-Werte Replikation, Zonentransfer oder uneinheitliche Konfiguration prüfen

Eine Vorwärts-Rückwärts-Konsistenz ist nicht für jede DNS-Anwendung zwingend vorgeschrieben. Bestimmte Mail-, Sicherheits- oder Identitätsprüfungen können sie jedoch voraussetzen.

7.11.27 Windows-DNS-Serverdienst und Zonen prüfen

Auf dem DNS-Server:

Get-Service -Name DNS

Zonen anzeigen:

Get-DnsServerZone

Nur Reverse-Lookup-Zonen:

Get-DnsServerZone |
    Where-Object { $_.IsReverseLookupZone }

Zustand einer bestimmten Zone:

Get-DnsServerZone `
  -Name "2.0.192.in-addr.arpa"

Zu prüfen sind:

Ein laufender DNS-Dienst beweist nicht, dass eine bestimmte Zone korrekt geladen oder erreichbar ist.

7.11.28 PTR-Datensätze auf dem Windows-DNS-Server prüfen

Alle PTR-Einträge einer Zone:

Get-DnsServerResourceRecord `
  -ZoneName "2.0.192.in-addr.arpa" `
  -RRType PTR

Bestimmten Eintrag prüfen:

Get-DnsServerResourceRecord `
  -ZoneName "2.0.192.in-addr.arpa" `
  -Name "25" `
  -RRType PTR

Von einem bestimmten DNS-Server lesen:

Get-DnsServerResourceRecord `
  -ComputerName "dns01.example.test" `
  -ZoneName "2.0.192.in-addr.arpa" `
  -Name "25" `
  -RRType PTR

Zu vergleichen sind:

Ein fehlender beziehungsweise als statisch dargestellter Zeitstempel kann auf einen statisch angelegten Datensatz hinweisen. Solche Datensätze werden nicht wie dynamisch gealterte Datensätze behandelt.

7.11.29 Rekursion, Forwarder und Cache des Windows-DNS-Servers prüfen

Allgemeine Forwarder:

Get-DnsServerForwarder

Rekursionseinstellungen:

Get-DnsServerRecursion

Root Hints:

Get-DnsServerRootHint

Cacheeinstellungen:

Get-DnsServerCache

Zu prüfen sind:

Nicht erreichbare Forwarder können Verzögerungen verursachen, bevor ein weiterer Forwarder oder ein alternativer Auflösungspfad verwendet wird.

7.11.30 DNS-Serverstatistiken auswerten

Aggregierte Statistiken:

Get-DnsServerStatistics

Statistiken einer bestimmten Zone:

Get-DnsServerStatistics `
  -ZoneName "2.0.192.in-addr.arpa"

Die genaue Struktur der Ausgabe hängt von der Windows-Server-Version ab. Zu untersuchen sind unter anderem:

Statistiken dürfen nicht ohne vorherige Sicherung des Ausgangswerts zurückgesetzt werden.

Das Cmdlet kann bei zonenbezogener Verwendung mit -Clear Zähler verändern. Diese Option ist deshalb keine rein lesende Diagnosemaßnahme.

7.11.31 Leistungsindikatoren überwachen

Verfügbare DNS-Leistungsindikatoren anzeigen:

Get-Counter -ListSet DNS

Beispiel für empfangene DNS-Abfragen und gesendete Antworten:

Get-Counter `
  '\DNS\Total Query Received/sec',
  '\DNS\Total Response Sent/sec' `
  -SampleInterval 2 `
  -MaxSamples 10

DNS-Prozess überwachen:

Get-Counter `
  '\Process(dns)\% Processor Time',
  '\Process(dns)\Working Set' `
  -SampleInterval 2 `
  -MaxSamples 10

Die Namen der Leistungsindikatoren können auf lokalisierten Windows-Systemen abweichen. Deshalb sollte zuerst Get-Counter -ListSet DNS verwendet werden.

Zu korrelieren sind:

Eine hohe Anzahl von Abfragen ist allein kein Fehler. Entscheidend sind Baseline, Hardware, Abfrageart, Cachetreffer, Rekursion, Fehlerquote und Antwortzeit.

7.11.32 Protokollierung kontrolliert einsetzen

Windows DNS Server stellt unter anderem folgende Ereignisprotokolle bereit:

Applications and Services Logs
└─ Microsoft
   └─ Windows
      └─ DNS-Server
         ├─ Audit
         └─ Analytical

Das Audit-Protokoll erfasst administrative und sicherheitsrelevante DNS-Vorgänge. Das analytische Protokoll kann detaillierte Abfrageinformationen liefern, ist jedoch standardmäßig nicht aktiviert.

Zu beachten ist:

Microsoft weist darauf hin, dass analytische DNS-Protokollierung bei sehr hohen Abfrageraten messbare Leistungseinflüsse verursachen kann. Deshalb muss sie mit den Leistungswerten des Servers korreliert werden.

7.11.33 Netzwerkaufzeichnung gezielt verwenden

Wenn DNS-Abfragen weiterhin unklar bleiben, kann eine zeitlich und inhaltlich begrenzte Netzwerkaufzeichnung erforderlich sein.

Zu prüfen sind:

DNS-Pakete können interne Hostnamen, Dienstnamen und andere schützenswerte Informationen enthalten. Aufzeichnungen müssen deshalb nach Sicherheits- und Datenschutzvorgaben behandelt werden.

7.11.34 Dynamische DNS-Aktualisierung prüfen

Windows-Clients können ihre DNS-Namen dynamisch registrieren:

Register-DnsClient

Alternativ:

ipconfig /registerdns

Diese Befehle lösen eine dynamische Aktualisierung aus und verändern damit möglicherweise den DNS-Zustand. Vorher sind vorhandene Datensätze, Zeitstempel und Ereignisse zu dokumentieren.

Zu prüfen sind:

Das wiederholte Ausführen von Register-DnsClient behebt keine fehlende Reverse-Zone, falsche Berechtigungen oder fehlerhafte DHCP-DNS-Einstellungen.

7.11.35 DHCP und PTR-Registrierung prüfen

Bei dynamisch vergebenen IP-Adressen kann der DHCP-Server DNS-Einträge im Auftrag des Clients aktualisieren.

Zu untersuchen sind:

Mögliche Fehlerbilder:

7.11.36 Aging und Scavenging berücksichtigen

Aging und Scavenging können veraltete dynamische DNS-Datensätze entfernen. Die Funktion beinhaltet Löschvorgänge und muss deshalb kontrolliert geplant werden.

Zu prüfen sind:

Scavenging sollte nicht spontan aktiviert oder manuell erzwungen werden, nur weil einzelne PTR-Einträge veraltet sind. Eine falsche Konfiguration kann gültige DNS-Datensätze löschen.

7.11.37 Active-Directory-integrierte DNS-Zonen prüfen

Bei AD-integrierten Zonen können unterschiedliche Antworten auf Replikationsprobleme hinweisen.

DNS-Test für einen Domänencontroller:

dcdiag /test:DNS /v /s:<DC-Name>

Replikationsübersicht:

repadmin /replsummary

Replikationsdetails:

repadmin /showrepl

Zu prüfen sind:

Eine erzwungene Replikation ist keine erste Diagnosemaßnahme. Zuerst müssen Richtung, Partner, Fehlercode und Ursache bestimmt werden.

7.11.38 Systematischer Diagnoseablauf

  1. Störungsbild dokumentieren
    Client, Anwendung, Name oder IP-Adresse, Uhrzeit und genaue Verzögerung erfassen.

  2. Abfragerichtung bestimmen
    Vorwärtsauflösung, Rückwärtsauflösung oder beide unterscheiden.

  3. Umfang bestimmen
    Einzelner Client, Anwendung, Standort, Zone oder alle Systeme unterscheiden.

  4. Resolverpfad erfassen
    DNS-Server, VPN, Suchsuffixe, Hosts-Datei, NRPT, DoH, DoT und lokale Resolver prüfen.

  5. Abfrage reproduzieren
    Den vorgesehenen DNS-Server ausdrücklich angeben.

  6. Antwortcode dokumentieren
    NOERROR, NXDOMAIN, SERVFAIL, REFUSED oder Timeout unterscheiden.

  7. Antwortzeit messen
    Erste und wiederholte Abfrage getrennt messen.

  8. Vorwärts- und Reverse-Abfrage vergleichen
    A beziehungsweise AAAA und PTR unabhängig testen.

  9. Alternativen DNS-Server testen
    Unterschiedliche Serverantworten dokumentieren.

  10. UDP und TCP vergleichen
    Transportabhängige Fehler abgrenzen.

  11. DoH oder DoT abgrenzen
    Verschlüsselten und klassischen DNS-Pfad getrennt prüfen.

  12. Autoritativen Server bestimmen
    Delegation und zuständige Zone prüfen.

  13. Direkte autoritative Abfrage durchführen
    Rekursion und Forwarder vom Zonenzustand trennen.

  14. PTR-Datensatz prüfen
    Zielname, TTL, Zeitstempel und Eigentümer auswerten.

  15. Vorwärts-Rückwärts-Konsistenz prüfen
    PTR-Zielnamen erneut über A und AAAA auflösen.

  16. Weitere Datensatztypen prüfen
    CNAME- oder SRV-Abhängigkeiten berücksichtigen.

  17. Cachezustand prüfen
    Client-, Server- und Anwendungscache unterscheiden.

  18. Forwarder und Rekursion prüfen
    Besonders bei langsamen externen oder bedingt weitergeleiteten Zonen.

  19. EDNS, MTU und DNSSEC prüfen
    Wenn kleine Antworten funktionieren und größere Antworten ausfallen.

  20. Serverleistung prüfen
    Abfragerate, CPU, Speicher, Fehler und Timeouts korrelieren.

  21. Dynamische Aktualisierung prüfen
    Client, DHCP, Berechtigungen und Zonenrichtlinie untersuchen.

  22. Aging und Scavenging prüfen
    Veraltete oder unerwartet gelöschte Datensätze abgrenzen.

  23. AD-Replikation prüfen
    Wenn DNS-Server unterschiedliche Antworten liefern.

  24. Hypothese formulieren
    Erwarteten Befund und möglichen Gegenbeweis festlegen.

  25. Eine kontrollierte Maßnahme durchführen
    Risiko, Rückweg und Erfolgskriterium dokumentieren.

  26. Erneut unter denselben Bedingungen messen
    Antwort, Code und Zeit mit dem Ausgangswert vergleichen.

  27. Gesamten DNS-Pfad verifizieren
    Client, rekursiven Server, autoritativen Server und Anwendung prüfen.

  28. Präventionsmaßnahme dokumentieren
    Ursache und dauerhafte Verbesserung festhalten.

7.11.39 Befundmatrix

Befund Mögliche Erklärung Nächster Nachweis
nslookup zeigt Unknown, andere Abfragen funktionieren PTR des DNS-Servers fehlt DNS-Server-IP rückwärts abfragen
Vorwärtsauflösung funktioniert, Reverse nicht PTR oder Reverse-Zone fehlt PTR-Abfrage und Zonenprüfung
Reverse-Abfrage endet sofort mit NXDOMAIN Name oder Zone meldet Nichtvorhandensein Autorität und SOA der Antwort prüfen
Reverse-Abfrage läuft in Timeout Server, Delegation oder Netzwerkpfad antwortet nicht autoritative Server und Paketpfad prüfen
PTR zeigt auf alten Hostnamen veralteter statischer oder dynamischer Eintrag Lease, Zeitstempel und Datensatzeigentümer prüfen
PTR-Zielname besitzt keinen A-/AAAA-Eintrag unvollständige DNS-Konfiguration Zielnamen vorwärts auflösen
PTR-Zielname zeigt auf andere IP Vorwärts-Rückwärts-Abweichung vorgesehene Mehrfachadressierung prüfen
erste Abfrage langsam, zweite schnell Cacheeffekt kalte und warme Messung vergleichen
jede externe Abfrage langsam Forwarder oder Rekursion direkte Abfragen gegen Forwarder und Autorität
nur interne Zone langsam interne Delegation oder AD-DNS autoritative interne Server vergleichen
nur ein DNS-Server liefert falsche Antwort lokaler Cache, Zone oder Replikation Server direkt vergleichen
UDP fehlerhaft, TCP erfolgreich Firewall, EDNS, Fragmentierung oder MTU Transportvergleich und Netzwerkaufzeichnung
SERVFAIL nur bei signierter Zone DNSSEC-Validierung oder Delegation Validierungskette und Serverereignisse prüfen
REFUSED Rekursion oder Richtlinie verweigert Abfrage Serverrichtlinie und Quellnetz prüfen
A-Eintrag vorhanden, PTR fehlt Reverse-Zone oder Updatepfad fehlt DHCP-, Client- und Zonenupdate prüfen
PTR wird nach IP-Wechsel nicht entfernt Aging, Scavenging oder DHCP-Bereinigung Leaseablauf, Zeitstempel und Zonenalterung
unterschiedliche Antworten je DC AD-Replikation oder uneinheitliche Zone repadmin, dcdiag und direkte Abfragen
Auflösung über IP schnell, über Namen langsam DNS oder nachgelagerte Namensprüfung direkte DNS-Zeit und Anwendungspfad vergleichen
öffentliche IP besitzt keinen PTR Provider hat keinen Reverse-Eintrag gesetzt Betreiber des IP-Präfixes ermitteln
neuer Datensatz bleibt zunächst unsichtbar positiver oder negativer Cache TTL und Cacheebenen prüfen
nslookup und Anwendung liefern verschiedene Ergebnisse NRPT, DoH oder anwendungseigener Resolver tatsächlichen Resolverpfad bestimmen
nur große Antworten schlagen fehl EDNS-, MTU- oder Fragmentierungsproblem UDP/TCP und Antwortgrößen vergleichen
SRV wird gefunden, Dienst funktioniert nicht Zielhost, Port oder Dienst fehlerhaft SRV-Ziel und Dienstport prüfen
CNAME wird aufgelöst, Zielname jedoch nicht fehlerhaftes Aliasziel CNAME-Kette vollständig prüfen
klassisches DNS funktioniert, DoH nicht Zertifikat, HTTPS-Port oder DoH-Endpunkt DoH-Zustand und TLS-Verbindung prüfen

7.11.40 Ursachen und erforderliche Nachweise

Mögliche Ursache Erforderlicher Nachweis
falscher DNS-Server Clientkonfiguration und direkte Abfragen bestätigen abweichenden Resolver
falsches DNS-Suffix Resolverkonfiguration zeigt unerwartete Suchdomäne
Hosts-Datei überschreibt DNS lokaler Eintrag liefert abweichende Zuordnung
anwendungseigener DNS-Cache Anwendung liefert trotz korrektem Systemtest alten Wert
NRPT-Fehler wirksame Richtlinie leitet den Namensraum an falschen Resolver
fehlerhafter Split-DNS-Pfad interne und externe Resolver liefern unbeabsichtigt verschiedene Antworten
DoH- oder DoT-Fehler verschlüsselter Pfad scheitert bei funktionierendem klassischem DNS
fehlende Reverse-Zone zuständiger DNS-Server besitzt oder erreicht die Zone nicht
fehlender PTR-Eintrag autoritative PTR-Abfrage liefert keinen Datensatz
falscher PTR-Eintrag autoritative Antwort enthält unerwarteten Zielnamen
fehlerhafte Delegation übergeordnete Zone verweist auf falsche oder nicht erreichbare Server
fehlerhafte RFC-2317-Konfiguration CNAME- und Zonendelegation des Teilnetzes sind unvollständig
fehlerhafte IPv6-Reverse-Zone Nibble-Zone stimmt nicht mit dem delegierten Präfix überein
nicht erreichbarer Forwarder direkte Abfrage zum Forwarder scheitert reproduzierbar
langsamer autoritativer Server direkte autoritative Abfrage zeigt erhöhte Antwortzeit
UDP-Blockierung UDP-DNS scheitert, TCP-DNS funktioniert
TCP-Blockierung abgeschnittene UDP-Antwort kann nicht über TCP wiederholt werden
Paketverlust Aufzeichnung zeigt Wiederholungen oder fehlende Antworten
MTU- oder Fragmentierungsproblem große UDP-Antworten scheitern, TCP funktioniert
DNS-Serverüberlastung erhöhte Antwortzeit korreliert mit Abfragerate und Ressourcenlast
ungeeignete TTL Datensatz- und Cachewerte bestätigen zu kurze oder zu lange Speicherung
negativer Cache zuvor negative Antwort bleibt bis zum Ablauf wirksam
falscher CNAME Alias verweist auf fehlenden oder falschen Zielnamen
falscher SRV-Eintrag Dienstziel, Port, Priorität oder Gewicht sind unzutreffend
DHCP aktualisiert PTR nicht DHCP-Ereignis oder Konfiguration bestätigt fehlgeschlagene Aktualisierung
fehlende Updateberechtigung DNS- oder DHCP-Protokoll zeigt Zugriffsfehler
veralteter statischer PTR statischer Datensatz enthält alten Namen
fehlerhaftes Scavenging Konfiguration oder Ereignisse bestätigen unerwartete Löschung
AD-Replikationsproblem DNS-Server liefern unterschiedliche autoritative Daten und repadmin meldet Fehler
DNSSEC-Validierungsfehler SERVFAIL und Validierungsdaten bestätigen fehlerhafte Vertrauenskette
öffentlicher PTR nicht delegiert Provider beziehungsweise Präfixbetreiber bestätigt fehlende Reverse-Konfiguration

7.11.41 Kontrollierte Maßnahmen, Risiko und Rückweg

Maßnahme Risiko Rückweg beziehungsweise Kontrolle
vorgesehenen DNS-Server konfigurieren andere Namensräume können beeinflusst werden bisherige DNS-Werte dokumentieren
falsches DNS-Suffix korrigieren Suchverhalten verändert sich ursprüngliche Suffixliste sichern
fehlerhaften Hosts-Eintrag entfernen Anwendung verliert lokale Sonderzuordnung Datei und ursprünglichen Eintrag sichern
NRPT-Regel korrigieren VPN-Namensauflösung kann ausfallen bisherige Regel und Zielserver sichern
DoH- oder DoT-Konfiguration korrigieren Transport und Fallbackverhalten ändern sich bisherigen Verschlüsselungszustand dokumentieren
fehlende Reverse-Zone anlegen falscher Adressbereich kann überschrieben werden Netz-ID und Zuständigkeit vorher bestätigen
PTR-Eintrag anlegen falscher Name wird veröffentlicht IP, FQDN und Forward-Eintrag vorher prüfen
veralteten PTR korrigieren bestehende Abhängigkeiten können betroffen sein alten Wert und Eigentümer dokumentieren
Forwarder korrigieren externe und interne Auflösung kann beeinflusst werden bisherige Forwarderliste sichern
Delegation korrigieren gesamter Reverse-Bereich kann betroffen sein bisherige NS- und CNAME-Daten sichern
dynamische Updates korrigieren viele Clients können Datensätze verändern Zonenrichtlinie und Berechtigungen dokumentieren
Clientregistrierung auslösen mehrere A- oder PTR-Einträge können entstehen vorhandene Einträge vorher erfassen
Clientcache kontrolliert löschen ursprünglicher Cachebefund geht verloren Cacheinhalt vorher dokumentieren
DNS-Servercache löschen viele Abfragen müssen erneut rekursiv aufgelöst werden nur gezielt und mit Lastkontrolle
TTL ändern Cacheverhalten vieler Resolver ändert sich bisherigen Wert und Änderungszeit sichern
Aging oder Scavenging anpassen gültige Datensätze können gelöscht werden Zonenexport und Änderungsplan vorsehen
AD-Replikationsfehler beheben mehrere DNS- und AD-Daten können betroffen sein DC-spezifischen Wiederherstellungsplan verwenden
analytische Protokollierung aktivieren Leistung und Datenschutz können betroffen sein Zeitfenster, Speicherlimit und Abschaltung festlegen

Pro Diagnoseversuch sollte möglichst nur eine relevante Variable verändert werden.

7.11.42 Beispiel: Reverse-Zone und PTR-Eintrag anlegen

Die folgenden Befehle sind verändernde Administrationsmaßnahmen und dürfen erst nach Prüfung von Netzbereich, Zonenverantwortung, Replikationsbereich und bestehender Konfiguration ausgeführt werden.

AD-integrierte IPv4-Reverse-Zone für das Dokumentationsnetz 192.0.2.0/24:

Add-DnsServerPrimaryZone `
  -NetworkID "192.0.2.0/24" `
  -ReplicationScope "Forest"

PTR-Eintrag für 192.0.2.25:

Add-DnsServerResourceRecordPtr `
  -Name "25" `
  -ZoneName "2.0.192.in-addr.arpa" `
  -PtrDomainName "host25.example.test."

Danach kontrollieren:

Get-DnsServerResourceRecord `
  -ZoneName "2.0.192.in-addr.arpa" `
  -Name "25" `
  -RRType PTR

Resolve-DnsName `
  -Name "192.0.2.25" `
  -Type PTR `
  -Server "192.0.2.53" `
  -DnsOnly

Zusätzlich muss der PTR-Zielname vorwärts geprüft werden:

Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly

Die Beispieladressen und Namen dienen ausschließlich der Dokumentation und müssen durch die tatsächlich autorisierten Werte ersetzt werden.

7.11.43 Verifikation

Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen:

Eine einzelne erfolgreiche Cacheabfrage ist keine ausreichende Verifikation des vollständigen DNS-Pfads.

7.11.44 Präventionsmaßnahmen

7.11.45 Typische Fehler bei der Diagnose

7.11.46 Checkliste

7.11.47 Schnellreferenz

Aufgabe Befehl
Windows-Netzwerk- und DNS-Konfiguration ipconfig /all
Windows-DNS-Serveradressen Get-DnsClientServerAddress
Windows-DNS-Clientzustand Get-DnsClient
Linux-Resolverzustand resolvectl status
macOS-Resolverzustand scutil --dns
wirksame NRPT-Richtlinie Get-DnsClientNrptPolicy
konfigurierte NRPT-Regeln Get-DnsClientNrptRule
DoH-/DoT-Clientzustand netsh dnsclient show state
verschlüsselte DNS-Server netsh dnsclient show encryption
Vorwärtsauflösung IPv4 Resolve-DnsName <Name> -Type A -Server <DNS-IP> -DnsOnly
Vorwärtsauflösung IPv6 Resolve-DnsName <Name> -Type AAAA -Server <DNS-IP> -DnsOnly
Rückwärtsauflösung Resolve-DnsName <IP> -Type PTR -Server <DNS-IP> -DnsOnly
Rückwärtsauflösung mit dig dig @<DNS-IP> -x <IP>
CNAME prüfen Resolve-DnsName <Name> -Type CNAME -Server <DNS-IP> -DnsOnly
SRV prüfen Resolve-DnsName <SRV-Name> -Type SRV -Server <DNS-IP> -DnsOnly
TCP-DNS-Abfrage Resolve-DnsName <Name> -Server <DNS-IP> -TcpOnly -DnsOnly
TCP-Port 53 prüfen Test-NetConnection <DNS-IP> -Port 53
DNSSEC-Daten anfordern Resolve-DnsName <Name> -Server <DNS-IP> -DnssecOk
Clientcache anzeigen Get-DnsClientCache
Clientcache löschen Clear-DnsClientCache
DNS-Serverdienst Get-Service DNS
DNS-Zonen Get-DnsServerZone
PTR-Einträge Get-DnsServerResourceRecord -ZoneName <Zone> -RRType PTR
Forwarder Get-DnsServerForwarder
Rekursion Get-DnsServerRecursion
Cacheeinstellungen Get-DnsServerCache
Serverstatistiken Get-DnsServerStatistics
Leistungsindikatoren Get-Counter -ListSet DNS
DoH-Serverkonfiguration Get-DnsServerEncryptionProtocol
Clientregistrierung Register-DnsClient
AD-DNS-Test dcdiag /test:DNS /v
AD-Replikation repadmin /replsummary

Ändernde Befehle, die nicht als erste Diagnose verwendet werden dürfen:

Clear-DnsClientCache
Clear-DnsServerCache
Register-DnsClient
ipconfig /flushdns
ipconfig /registerdns
Add-DnsServerPrimaryZone
Add-DnsServerResourceRecordPtr
Set-DnsServerForwarder
Set-DnsServerRecursion
Set-DnsServerCache
Set-DnsServerZoneAging
Start-DnsServerScavenging
Set-DnsServerEncryptionProtocol
Remove-DnsServerResourceRecord

7.11.48 Quellen

Offizielle Microsoft-Dokumentation

Standards

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

Revision #1
Created 2 August 2026 14:52:27 by Admin
Updated 2 August 2026 14:52:41 by Admin