7.12 Systematischer DNS-Diagnoseablauf

Kurz erklärt

DNS-Störungen dürfen nicht durch wahlloses Leeren von Caches, Ändern von DNS-Servern oder Neuerstellen von Einträgen diagnostiziert werden.

Der sichere Ablauf beginnt beim exakten Fehlerbild und verfolgt die Namensauflösung schrittweise vom Client über den verwendeten Resolver, den Transportweg und rekursive DNS-Server bis zum autoritativen Server und den tatsächlichen Zonendaten.

7.12.1 Ziel des Diagnoseablaufs

Der Diagnoseablauf soll eindeutig bestimmen:

welcher Name oder welche IP-Adresse betroffen ist;

welcher Datensatztyp benötigt wird;

welcher Client und welche Anwendung betroffen sind;

welcher Resolverweg tatsächlich verwendet wird;

welcher DNS-Server die Anfrage erhält;

ob eine Antwort eintrifft;

welcher Antwortcode zurückgegeben wird;

ob die Antwort korrekt und aktuell ist;

ob die Antwort aus einem Cache oder einer autoritativen Zone stammt;

an welcher Stelle eine Verzögerung oder ein Fehler entsteht;

welche einzelne Maßnahme die nachgewiesene Ursache behebt;

wie die vollständige Funktion anschließend verifiziert wird.

DNS-Diagnose bedeutet nicht nur, irgendeine erfolgreiche Antwort zu erhalten. Die Antwort muss vom vorgesehenen DNS-Pfad stammen, fachlich korrekt sein und innerhalb einer angemessenen Zeit eintreffen.

7.12.2 Grundregeln

Zuerst beobachten und dokumentieren.

Den exakten Namen und Datensatztyp verwenden.

Clientverhalten und direkte DNS-Abfrage unterscheiden.

Den tatsächlich verwendeten DNS-Server bestimmen.

Antwortcode und Antwortinhalt getrennt bewerten.

Positive, negative und ausgebliebene Antworten unterscheiden.

Cache-, rekursive und autoritative Antworten trennen.

UDP, TCP, DoH und DoT nicht gleichsetzen.

Pro Versuch nur eine relevante Variable verändern.

Vor jeder Änderung Risiko und Rückweg dokumentieren.

Nach der Maßnahme denselben Test wiederholen.

Erst nach technischer Verifikation den Vorgang abschließen.

Folgende Maßnahmen sind keine geeigneten ersten Diagnoseschritte:

DNS-Cache sofort löschen;

öffentlichen DNS-Server eintragen;

DNS-Dienst neu starten;

Zone neu erstellen;

DNS-Einträge vorsorglich löschen;

Forwarder verändern;

Scavenging aktivieren;

Client erneut in die Domäne aufnehmen;

Firewall oder DNSSEC deaktivieren;

VPN-, NRPT- oder DoH-Richtlinien entfernen.

7.12.3 Fehleraufnahme

Vor dem ersten Test sind mindestens folgende Angaben zu erfassen:

Angabe	Beispiel
Zeitpunkt	`2026-08-02 14:35:20`
Client	`client25.example.test`
Benutzer beziehungsweise Dienst	betroffene Sitzung oder Dienstkonto
Anwendung	Browser, RDP, Mail, Dateifreigabe, AD-Anmeldung
eingegebener Name	`app.example.test`
erwarteter FQDN	`app.example.test.`
erwarteter Datensatztyp	A, AAAA, CNAME, PTR, SRV, MX oder TXT
erwartetes Ergebnis	vorgesehene IP-Adresse oder Zielname
tatsächliches Ergebnis	Fehlertext oder falsche Antwort
verwendetes Netzwerk	LAN, WLAN, VPN oder Mobilfunk
Quell-IP-Adresse	aktive Clientadresse
konfigurierte DNS-Server	Reihenfolge und Schnittstelle
Fehlerumfang	einzelner Client, Standort, Zone oder alle Systeme
letzte Änderung	DNS, DHCP, VPN, Firewall, Server, Zertifikat oder Netzwerk

Kennwörter, Zugangsdaten und unnötige personenbezogene Daten dürfen nicht in die Fehlerdokumentation übernommen werden.

7.12.4 Störung einordnen

Fehlerklasse	Typisches Symptom
vollständiger Ausfall	keine DNS-Abfrage funktioniert
namensbezogener Fehler	nur ein bestimmter Name schlägt fehl
zonenbezogener Fehler	alle Namen einer Zone schlagen fehl
datensatzbezogener Fehler	A funktioniert, SRV oder PTR jedoch nicht
resolverbezogener Fehler	nur ein bestimmter DNS-Server liefert Fehler
clientbezogener Fehler	derselbe Name funktioniert an anderen Clients
anwendungsbezogener Fehler	direkte DNS-Abfrage funktioniert, Anwendung nicht
standortbezogener Fehler	Fehler tritt nur in einem Netz oder VPN auf
zeitabhängiger Fehler	Fehler tritt nur zeitweise auf
leistungsbezogener Fehler	Antwort ist korrekt, aber zu langsam
datenbezogener Fehler	DNS liefert eine falsche oder veraltete Antwort
transportbezogener Fehler	UDP, TCP, DoH oder DoT verhalten sich unterschiedlich
validierungsbezogener Fehler	DNSSEC führt zu `SERVFAIL` oder Validierungsfehler
reversebezogener Fehler	IP-Adresse lässt sich nicht korrekt in einen Namen auflösen

Diese Einordnung bestimmt, welche Vergleichstests aussagekräftig sind.

7.12.5 Geeignete Testdaten festlegen

Für reproduzierbare Tests müssen folgende Werte feststehen:

exakter FQDN;

gewünschter Datensatztyp;

erwarteter Wert;

vorgesehener DNS-Server;

autoritativer DNS-Server;

Vergleichsname, der sicher funktioniert;

Vergleichsname, der sicher nicht existiert;

vorgesehene Antwortzeit oder vorhandene Baseline.

Ein kurzer Name wie:

server01

ist für eine eindeutige DNS-Diagnose ungeeignet, solange nicht feststeht, welches DNS-Suffix ergänzt wird.

Besser:

server01.example.test.

Der abschließende Punkt kennzeichnet einen vollständig qualifizierten absoluten DNS-Namen. Viele Werkzeuge funktionieren auch ohne diesen Punkt, können dann jedoch abhängig von Suchsuffixen zusätzliche Namen prüfen.

7.12.6 DNS-Auflösung als Kette betrachten

Eine Namensauflösung kann folgende Stationen durchlaufen:

Station	Aufgabe
Anwendung	fordert eine Namensauflösung an oder verwendet eigenen Resolver
lokale Namensquelle	Hosts-Datei oder anwendungseigener Cache
Betriebssystemresolver	wertet Cache, Suffixe, Richtlinien und DNS-Server aus
lokaler Stub-Resolver	nimmt Anfragen lokal entgegen und leitet sie weiter
VPN-, Container- oder Sicherheitsresolver	beeinflusst den Abfrageweg
rekursiver DNS-Server	beschafft die vollständige Antwort für den Client
Forwarder	übernimmt weitergeleitete Anfragen
DNS-Hierarchie	verweist schrittweise auf zuständige Server
autoritativer DNS-Server	liefert die maßgeblichen Zonendaten
Cache auf dem Rückweg	speichert positive oder negative Antworten

Die Diagnose folgt dieser Kette vom Client in Richtung autoritativer Datenquelle.

7.12.7 Umfang der Störung bestimmen

Kontrollierte Vergleiche:

Vergleich	Aussage
gleicher Name, anderer Client	clientbezogenen Fehler prüfen
gleicher Client, anderer Name	namens- oder zonenbezogenen Fehler prüfen
gleicher Name, anderer DNS-Server	resolverbezogenen Fehler prüfen
gleiche Abfrage, direkt gegen autoritativen Server	Rekursion und Autorität trennen
gleiche Abfrage mit und ohne VPN	VPN-, NRPT- oder Split-DNS-Fehler prüfen
gleiche Abfrage über UDP und TCP	Transportfehler prüfen
direkte DNS-Abfrage und Anwendung	DNS- und Anwendungsfehler trennen
Vorwärts- und Rückwärtsauflösung	A/AAAA und PTR getrennt prüfen
erste und wiederholte Abfrage	Cachewirkung prüfen
interner und externer Name	interne Zone und Rekursion trennen

Erst nach diesen Vergleichen sollte eine konkrete Ursache angenommen werden.

7.12.8 Clientidentität und Netzwerkzustand prüfen

Windows

Get-NetIPConfiguration

ipconfig /all

Linux

ip address

ip route

macOS

ifconfig

route -n get default

Zu prüfen sind:

aktive Schnittstelle;

IPv4- und IPv6-Adresse;

Subnetz beziehungsweise Präfix;

Standardgateway;

DNS-Server;

DHCP- oder statische Konfiguration;

Verbindungssuffix;

VPN-Schnittstelle;

unerwartete zusätzliche Schnittstellen;

Container-, Hypervisor- oder Sicherheitsadapter.

Eine vorhandene IP-Adresse beweist nicht, dass der vorgesehene DNS-Server erreichbar ist.

7.12.9 DNS-Server und Resolverkonfiguration ermitteln

Windows

Get-DnsClientServerAddress

Get-DnsClient

Linux

cat /etc/resolv.conf

Bei systemd-resolved:

resolvectl status

macOS

scutil --dns

Zu prüfen sind:

DNS-Server pro Schnittstelle;

Reihenfolge der DNS-Server;

DNS-Suffixe;

Suchliste;

VPN-spezifische Resolver;

IPv4- und IPv6-DNS-Server;

lokale Stub-Adressen;

namensraumabhängige Resolver.

/etc/resolv.conf kann lediglich auf einen lokalen Stub-Resolver verweisen. In diesem Fall müssen die tatsächlichen Upstream-DNS-Server über den zuständigen Resolverdienst ermittelt werden.

7.12.10 Interne Clients und öffentliche DNS-Server

Domänenmitglieder und interne Clients müssen für interne Namensräume die vorgesehenen internen DNS-Server verwenden.

Das Eintragen eines öffentlichen DNS-Servers wie eines Resolverdienstes im Internet kann:

interne Zonen unauflösbar machen;

Active-Directory-SRV-Einträge verbergen;

Split-DNS umgehen;

interne Namen an externe Resolver übertragen;

Anmeldungen, Gruppenrichtlinien und Dienstsuche beeinträchtigen;

zu wechselnden Ergebnissen führen.

Ein öffentlicher DNS-Server darf deshalb nicht als pauschale Reparatur für einen internen DNS-Fehler eingetragen werden.

7.12.11 Hosts-Datei und lokale Namensquellen prüfen

Hosts-Dateien:

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

Zu prüfen sind:

existiert ein Eintrag für den betroffenen Namen?

stimmt die eingetragene IP-Adresse?

existieren doppelte oder auskommentierte Varianten?

verwendet die Anwendung einen eigenen lokalen Namensspeicher?

stammt die erfolgreiche Auflösung überhaupt aus DNS?

Eine direkte Abfrage mit ausdrücklich angegebenem DNS-Server kann erfolgreich sein, während eine Anwendung wegen eines falschen lokalen Eintrags eine andere Adresse verwendet.

7.12.12 Kurznamen und DNS-Suffixe prüfen

Wenn ein Benutzer nur folgenden Namen verwendet:

server01

kann der Resolver abhängig von seiner Suchliste nacheinander verschiedene Namen bilden:

server01.example.test
server01.branch.example.test
server01.other.example.test

Windows-Konfiguration prüfen:

Get-DnsClient

Linux mit systemd-resolved:

resolvectl status

macOS:

scutil --dns

Mögliche Fehler:

falsches Verbindungssuffix;

fehlende Suchdomäne;

zu lange Suchliste;

unerwartete Reihenfolge;

unterschiedliche Suffixe zwischen LAN und VPN;

ein Kurzname trifft unbeabsichtigt auf eine andere Zone;

Suchanfragen erzeugen zusätzliche Verzögerungen.

Für die technische Diagnose sollte zuerst der vollständige FQDN verwendet werden.

7.12.13 Tatsächlichen Windows-Resolverpfad bestimmen

Unter Windows können NRPT, VPN-Richtlinien und verschlüsseltes DNS den Abfrageweg verändern.

Wirksame NRPT-Richtlinien:

Get-DnsClientNrptPolicy

Konfigurierte NRPT-Regeln:

Get-DnsClientNrptRule

DNS-Clientzustand:

netsh dnsclient show state

Globale verschlüsselte DNS-Einstellungen:

netsh dnsclient show global

Konfigurierte DoH- oder DoT-Endpunkte:

netsh dnsclient show encryption

Wichtig:

Resolve-DnsName kann den Windows-Resolverpfad einschließlich NRPT verwenden.

nslookup verwendet einen eigenen Abfrageweg und eignet sich nicht allein zur Prüfung der NRPT.

Browser oder andere Anwendungen können eigene DoH-Resolver verwenden.

Eine direkte Abfrage mit -Server prüft den angegebenen DNS-Server, aber nicht zwingend die gesamte normale Resolverauswahl der Anwendung.

Deshalb müssen Systemauflösung und direkte Serverabfrage getrennt getestet werden.

7.12.14 Anwendung und DNS voneinander abgrenzen

Folgende Ergebnisse sind getrennt zu prüfen:

Kann die Ziel-IP-Adresse direkt erreicht werden?

Liefert eine direkte DNS-Abfrage die erwartete Adresse?

Liefert der normale Betriebssystemresolver dieselbe Adresse?

Verwendet die Anwendung dieselbe Adresse?

Ist der eigentliche Dienst auf der Zieladresse erreichbar?

Beispiel:

Resolve-DnsName "app.example.test"

Direkte Abfrage gegen einen bestimmten DNS-Server:

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

Wenn DNS die richtige IP-Adresse liefert, die Anwendung aber weiterhin fehlschlägt, müssen unter anderem Anwendungscache, Proxy, TLS-Zertifikat, Dienstport und Anwendungsrichtlinien geprüft werden.

Ein erfolgreicher DNS-Test beweist nicht, dass der Zielservice funktioniert.

7.12.15 Direkte DNS-Abfragen durchführen

Windows PowerShell

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

Windows Eingabeaufforderung

nslookup app.example.test 192.0.2.53

Linux und macOS

dig @192.0.2.53 app.example.test A

Bei jedem Test sind zu dokumentieren:

Abfragename;

Datensatztyp;

verwendeter DNS-Server;

Antwortcode;

Antwortinhalt;

TTL;

Antwortzeit;

Flags;

autoritative oder rekursive Antwort;

zusätzliche CNAME-Ziele.

7.12.16 Datensatztypen gezielt prüfen

Aufgabe	Datensatz
IPv4-Adresse ermitteln	A
IPv6-Adresse ermitteln	AAAA
Alias verfolgen	CNAME
Mailserver ermitteln	MX
Dienst und Port ermitteln	SRV
IP-Adresse rückwärts auflösen	PTR
Zonenautorität prüfen	SOA
autoritative Server ermitteln	NS
Richtlinien- oder Verifikationstext prüfen	TXT
DNSSEC-Schlüssel prüfen	DNSKEY
Delegationssignatur prüfen	DS

Beispiele:

Resolve-DnsName "app.example.test" -Type A

Resolve-DnsName "alias.example.test" -Type CNAME

Resolve-DnsName "_service._tcp.example.test" -Type SRV

Resolve-DnsName "example.test" -Type SOA

Resolve-DnsName "example.test" -Type NS

Bei CNAME, MX und SRV muss zusätzlich geprüft werden, ob der zurückgegebene Zielname über A oder AAAA auflösbar ist.

7.12.17 DNS-Antwortcodes auswerten

Ergebnis	Bedeutung	Nächster Schritt
`NOERROR` mit Antwort	Abfrage erfolgreich	Inhalt, TTL und Quelle prüfen
`NOERROR` ohne gesuchten Datensatz	Name kann existieren, Datensatztyp fehlt	anderen Datensatztyp und SOA prüfen
`NXDOMAIN`	abgefragter Name existiert laut Antwort nicht	Name, Zone, Autorität und negativen Cache prüfen
`SERVFAIL`	Server konnte keine verwertbare Antwort erzeugen	Delegation, DNSSEC, Forwarder und Serverprotokolle prüfen
`REFUSED`	Server verweigert die Abfrage	ACL, Rekursion, Richtlinie und Quellnetz prüfen
`FORMERR`	DNS-Nachricht wurde als fehlerhaft bewertet	Client, Server und Netzwerkgerät prüfen
`NOTIMP`	angeforderte Funktion wird nicht unterstützt	Abfragefunktion und Serverfähigkeit prüfen
Timeout	keine verwertbare Antwort innerhalb der Wartezeit	Netzwerk, Transport und Serververfügbarkeit prüfen
`TC` gesetzt	UDP-Antwort wurde abgeschnitten	erneuten Versuch über TCP prüfen

Wichtige Unterscheidungen:

NODATA ist kein eigener RCODE, sondern beschreibt typischerweise NOERROR ohne den angefragten Datensatz.

Timeout ist keine DNS-Antwort.

SERVFAIL beweist nicht, dass der Name nicht existiert.

NXDOMAIN und ein fehlender einzelner Datensatztyp sind nicht dasselbe.

Extended DNS Errors können zusätzliche Hinweise liefern, werden aber nicht von jedem Resolver oder Diagnosewerkzeug angezeigt.

7.12.18 Antwortflags berücksichtigen

Typische DNS-Flags:

Flag	Bedeutung
`AA`	Antwort ist für die beantwortete Zone autoritativ
`RD`	Client hat Rekursion angefordert
`RA`	Server bietet Rekursion an
`TC`	Antwort wurde abgeschnitten
`AD`	Resolver kennzeichnet Daten als DNSSEC-validiert
`CD`	Client fordert an, Validierungsfehler nicht als Sperre zu verwenden

Ein gesetztes AD-Flag muss im Zusammenhang mit dem verwendeten validierenden Resolver bewertet werden. Das bloße Anfordern von DNSSEC-Daten beweist keine erfolgreiche Validierung.

7.12.19 Antwortzeit messen

Windows

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

Linux und macOS

dig @192.0.2.53 app.example.test A +stats

Zu vergleichen sind:

erste Abfrage;

unmittelbar wiederholte Abfrage;

vorhandener Name;

nicht vorhandener Name;

interner Name;

externer Name;

primärer DNS-Server;

alternativer DNS-Server;

rekursiver DNS-Server;

autoritativer DNS-Server;

UDP;

TCP;

mit und ohne VPN.

Measure-Command enthält auch den PowerShell-Befehlsaufwand. Es eignet sich deshalb vor allem für Vergleiche unter denselben Bedingungen.

7.12.20 Cachezustand prüfen

Windows-Clientcache

Get-DnsClientCache

Alternativ:

ipconfig /displaydns

Linux mit systemd-resolved

resolvectl statistics

Windows-DNS-Servercacheeinstellungen

Get-DnsServerCache

Get-DnsServerCache zeigt Cacheeinstellungen des Windows-DNS-Servers und nicht einfach eine vollständige Liste aller zwischengespeicherten Antworten.

Zu prüfen sind:

positiver oder negativer Cacheeintrag;

Datensatztyp;

gespeicherter Wert;

verbleibende TTL;

Herkunft des Eintrags;

Verhalten nach Ablauf der TTL;

Unterschiede zwischen Anwendung, Client und DNS-Server.

Cachelöschung verändert Beweisdaten und darf erst nach der Dokumentation als kontrollierter Vergleich erfolgen.

7.12.21 Positive und negative Zwischenspeicherung unterscheiden

Positive Antworten können A-, AAAA-, CNAME-, PTR- oder andere Datensätze zwischenspeichern.

Negative Zwischenspeicherung kann unter anderem betreffen:

nicht vorhandenen Namen;

vorhandenen Namen ohne angefragten Datensatztyp;

vorübergehende Auflösungsfehler, abhängig vom Resolververhalten.

Mögliche Folge:

Ein Name wird abgefragt und liefert NXDOMAIN.

Der fehlende Datensatz wird anschließend angelegt.

Der Client oder rekursive Resolver liefert zunächst weiterhin die gespeicherte negative Antwort.

Erst nach Ablauf oder kontrollierter Löschung des Cacheeintrags wird der neue Datensatz sichtbar.

Deshalb müssen SOA-Daten, negative TTL und alle beteiligten Cacheebenen berücksichtigt werden.

7.12.22 DNS-Server vergleichen

Eine identische Abfrage muss gezielt an jeden vorgesehenen DNS-Server gesendet werden.

Windows

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

Resolve-DnsName `
  -Name "app.example.test" `
  -Type A `
  -Server "192.0.2.54" `
  -DnsOnly

Linux und macOS

dig @192.0.2.53 app.example.test A

dig @192.0.2.54 app.example.test A

Zu vergleichen sind:

Antwortcode;

Datensatzwert;

TTL;

CNAME-Kette;

Antwortzeit;

Autoritätsflag;

SOA- und NS-Daten;

DNSSEC-Verhalten.

Unterschiedliche Antworten können auf Cache-, Zonen-, Replikations-, Zonentransfer- oder Konfigurationsprobleme hinweisen.

7.12.23 UDP und TCP prüfen

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

bei abgeschnittenen UDP-Antworten;

bei größeren Antworten;

bei bestimmten DNSSEC-Antworten;

bei Zonentransfers;

wenn TCP ausdrücklich angefordert wird.

TCP-Erreichbarkeit unter Windows:

Test-NetConnection "192.0.2.53" -Port 53

Dieser Befehl prüft nur TCP.

Normale DNS-Abfrage:

Resolve-DnsName `
  -Name "app.example.test" `
  -Server "192.0.2.53" `
  -DnsOnly

TCP erzwingen:

Resolve-DnsName `
  -Name "app.example.test" `
  -Server "192.0.2.53" `
  -DnsOnly `
  -TcpOnly

Mit dig:

dig @192.0.2.53 app.example.test A

dig @192.0.2.53 app.example.test A +tcp

Wenn UDP fehlschlägt und TCP funktioniert, sind Firewall, Paketverlust, EDNS, MTU und Fragmentierung zu prüfen.

7.12.24 EDNS, MTU und Fragmentierung prüfen

Hinweise auf ein Größen- oder Transportproblem:

einfache A-Abfrage funktioniert;

größere TXT-, DNSKEY- oder DNSSEC-Antwort schlägt fehl;

Fehler tritt nur über VPN oder Tunnel auf;

UDP endet im Timeout;

dieselbe Abfrage funktioniert über TCP;

Netzwerkaufzeichnung zeigt fragmentierte oder verlorene Pakete.

Vergleich:

dig @192.0.2.53 example.com A +dnssec

dig @192.0.2.53 example.com A +dnssec +tcp

Test ohne EDNS:

dig @192.0.2.53 example.com A +noedns

Das testweise Unterdrücken von EDNS dient nur der Eingrenzung. EDNS darf nicht dauerhaft deaktiviert werden, um einen fehlerhaften Netzwerkpfad zu verdecken.

7.12.25 Verschlüsseltes DNS prüfen

DNS over HTTPS und DNS over TLS verändern den Transportweg.

Zu prüfen sind:

verwendetes Protokoll;

Resolveradresse;

DoH-URI beziehungsweise DoT-Hostname;

TCP-Port;

TLS-Zertifikat;

Zertifikatsname;

Vertrauenskette;

Fallback auf klassisches DNS;

Firewall- und Proxyweg;

Anwendung mit eigenem DoH-Resolver;

Erreichbarkeit interner Zonen.

Windows-Zustand:

netsh dnsclient show state

netsh dnsclient show encryption

Bei verschlüsseltem DNS kann eine klassische Paketaufzeichnung den DNS-Inhalt nicht ohne zusätzliche, autorisierte Entschlüsselungsinformationen anzeigen.

Ein erfolgreicher Test gegen UDP- oder TCP-Port 53 beweist nicht, dass ein DoH- oder DoT-Endpunkt funktioniert.

7.12.26 Rekursiven und autoritativen DNS-Server unterscheiden

Ein rekursiver DNS-Server beschafft die Antwort im Auftrag des Clients.

Ein autoritativer DNS-Server verwaltet die maßgeblichen Daten einer Zone.

Diagnosevergleich:

Client fragt vorgesehenen rekursiven DNS-Server.

Rekursiver Server liefert Fehler oder langsame Antwort.

Autoritativer DNS-Server wird direkt abgefragt.

Ergebnisse werden verglichen.

Wenn der autoritative Server korrekt und schnell antwortet, liegt die Ursache wahrscheinlich bei:

Rekursion;

Forwarder;

Cache;

DNSSEC-Validierung;

Netzwerkpfad;

Richtlinie des rekursiven Servers.

Wenn bereits der autoritative Server falsche Daten liefert, sind Zone, Datensatz, Delegation und Replikation zu prüfen.

7.12.27 SOA-, NS- und Delegationsdaten prüfen

SOA prüfen:

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

NS prüfen:

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

Mit dig:

dig @192.0.2.53 example.test SOA

dig @192.0.2.53 example.test NS

Öffentliche Delegationskette verfolgen:

dig app.example.test A +trace

Zu prüfen sind:

richtige Zonengrenze;

zuständige autoritative Server;

Erreichbarkeit aller autoritativen Server;

korrekte NS-Einträge;

erforderliche Glue Records;

SOA-Seriennummer;

widersprüchliche Antworten;

veraltete Delegation;

fehlende oder falsche Child-Zone.

dig +trace folgt der öffentlichen DNS-Hierarchie. Interne Split-DNS-Zonen, bedingte Forwarder und private Namensräume müssen über den internen DNS-Pfad geprüft werden.

7.12.28 Forwarder, bedingte Forwarder und Rekursion prüfen

Auf einem Windows-DNS-Server:

Get-DnsServerForwarder

Get-DnsServerRecursion

Get-DnsServerRootHint

Zonen und bedingte Weiterleitungen:

Get-DnsServerZone

Zu prüfen sind:

Erreichbarkeit aller Forwarder;

Antwortzeit jedes Forwarders;

bedingter Forwarder für den betroffenen Namensraum;

aktuelle Zieladressen;

Replikationsbereich eines AD-integrierten bedingten Forwarders;

aktivierte oder deaktivierte Rekursion;

Root-Hint-Verwendung;

DNS-Richtlinien und Rekursionsbereiche;

Timeout- und Fallbackverhalten.

Ein nicht erreichbarer erster Forwarder kann Verzögerungen verursachen, bevor ein weiterer Auflösungspfad verwendet wird.

7.12.29 Reverse-Lookups prüfen

Windows

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

Linux und macOS

dig @192.0.2.53 -x 192.0.2.25

Danach muss der PTR-Zielname wieder vorwärts geprüft werden:

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

Zu prüfen sind:

Reverse-Zone;

Delegation;

PTR-Eintrag;

Zielname;

TTL;

Vorwärts-Rückwärts-Konsistenz;

veraltete Einträge;

öffentliche oder private Zuständigkeit;

dynamische Aktualisierung.

Ein fehlender PTR-Eintrag beweist keinen vollständigen DNS-Ausfall.

7.12.30 DNSSEC systematisch abgrenzen

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

Zu prüfen sind:

tritt SERVFAIL nur bei signierten Zonen auf?

funktioniert die Abfrage über einen nicht validierenden Vergleichspfad?

existieren DS- und DNSKEY-Datensätze?

sind Signaturen gültig?

stimmt die Systemzeit?

ist der Trust Anchor vorhanden?

verlangt die NRPT DNSSEC-Validierung?

zeigt der Resolver einen Extended DNS Error an?

besteht ein Größen- oder Transportproblem?

-DnssecOk und +dnssec fordern DNSSEC-bezogene Daten an. Diese Optionen beweisen allein keine erfolgreiche Validierung.

nslookup ist nicht für eine vollständige DNSSEC-Diagnose geeignet.

7.12.31 Windows-DNS-Serverzustand prüfen

Dienststatus:

Get-Service -Name DNS

Zonen:

Get-DnsServerZone

Bestimmte Zone:

Get-DnsServerZone `
  -Name "example.test"

Datensätze:

Get-DnsServerResourceRecord `
  -ZoneName "example.test"

Serverstatistiken:

Get-DnsServerStatistics

Verfügbare Leistungsindikatoren:

Get-Counter -ListSet DNS

Zu prüfen sind:

Dienststatus;

geladene und angehaltene Zonen;

primäre, sekundäre, Stub- oder AD-integrierte Zone;

Replikationsbereich;

dynamische Updates;

Zonentransfer;

Serverfehler;

Rekursionsfehler;

Abfragerate;

CPU, Speicher und Netzwerk;

Unterschiede zwischen DNS-Servern.

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

7.12.32 Active-Directory-DNS prüfen

LDAP-SRV-Einträge:

Resolve-DnsName `
  -Name "_ldap._tcp.dc._msdcs.<AD-DNS-Domäne>" `
  -Type SRV

Kerberos-SRV-Einträge:

Resolve-DnsName `
  -Name "_kerberos._tcp.<AD-DNS-Domäne>" `
  -Type SRV

DNS-Test eines Domänencontrollers:

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

Replikationsübersicht:

repadmin /replsummary

Replikationsdetails:

repadmin /showrepl

Zu prüfen sind:

verwendet der Client ausschließlich vorgesehene AD-DNS-Server?

existieren die benötigten SRV-Einträge?

sind die SRV-Zielhosts über A oder AAAA auflösbar?

sind die veröffentlichten Dienste erreichbar?

existiert die Zone auf allen vorgesehenen DNS-Servern?

funktioniert AD-Replikation?

stimmen Standort- und Subnetzzuordnung?

liefern verschiedene DCs unterschiedliche Antworten?

Eine manuelle Neuerstellung von SRV-Einträgen ist keine erste Maßnahme. Zuerst müssen Registrierung, Netlogon, Zone, Berechtigungen und Replikation geprüft werden.

7.12.33 Dynamische Updates und DHCP prüfen

Vor einer erneuten Registrierung sind vorhandene Datensätze, Zeitstempel und Ereignisse zu dokumentieren.

Verändernde Clientregistrierung:

Register-DnsClient

Alternativ:

ipconfig /registerdns

Zu prüfen sind:

Existenz der Forward- und Reverse-Zone;

erlaubte Aktualisierungsart;

sichere dynamische Updates;

Client- oder DHCP-Verantwortung;

DHCP-Lease;

DNS-Optionen des DHCP-Bereichs;

Aktualisierung von A- und PTR-Einträgen;

Datensatzeigentümer;

Berechtigungen;

statische Altbestände;

DHCP-Failover;

DNS- und DHCP-Ereignisse.

Das wiederholte Registrieren behebt keine fehlende Zone, falsche Berechtigung oder fehlerhafte DHCP-DNS-Konfiguration.

7.12.34 Aging und Scavenging prüfen

Zu prüfen sind:

Aging-Einstellung der Zone;

Scavenging-Einstellung des Servers;

No-Refresh-Intervall;

Refresh-Intervall;

Scavenging-Zyklus;

Zeitstempel des Datensatzes;

statischer oder dynamischer Eintrag;

DHCP-Leasezeit;

Zeitpunkt der letzten Aktualisierung;

unerwartet gelöschte Datensätze.

Scavenging beinhaltet Löschvorgänge und darf nicht spontan aktiviert oder erzwungen werden, um einzelne veraltete Einträge zu beseitigen.

7.12.35 Ereignisse und Protokolle auswerten

Vorhandene DNS-Protokolle unter Windows anzeigen:

Get-WinEvent -ListLog "*DNS*"

Mögliche Bereiche:

DNS-Client-Protokolle;

DNS-Server-Audit-Protokoll;

DNS-Server-Analytical-Protokoll;

Systemprotokoll;

DHCP-Serverprotokoll;

Verzeichnisdienstprotokoll;

anwendungsspezifische Protokolle.

Zu korrelieren sind:

genauer Zeitpunkt;

Clientadresse;

Abfragename;

Datensatztyp;

Antwortcode;

verwendeter Server;

dynamische Aktualisierung;

Zonenladen;

Replikation;

DNSSEC;

DoH;

Dienststart oder Dienstfehler.

Analytische DNS-Protokollierung muss gezielt und zeitlich begrenzt aktiviert werden. Sie kann bei hohen Abfrageraten die Leistung beeinflussen und enthält schützenswerte interne Namensinformationen.

7.12.36 Netzwerkaufzeichnung gezielt einsetzen

Eine Netzwerkaufzeichnung ist sinnvoll, wenn unklar bleibt:

ob die Abfrage den Client verlässt;

welcher DNS-Server angesprochen wird;

ob eine Antwort zurückkommt;

ob Wiederholungen stattfinden;

ob UDP oder TCP verwendet wird;

ob die UDP-Antwort abgeschnitten ist;

ob anschließend TCP verwendet wird;

ob Fragmentierung oder Paketverlust auftritt;

wie lang die Antwort tatsächlich benötigt;

ob der Client zu einem anderen DNS-Server wechselt.

Bei DoH und DoT ist der DNS-Inhalt verschlüsselt. Sichtbar bleiben unter anderem Zieladresse, Port, TLS-Verbindung und Zeitverhalten, nicht jedoch ohne Weiteres der eigentliche DNS-Nachrichteninhalt.

Aufzeichnungen müssen auf die betroffenen Systeme, Namen und Zeiträume begrenzt sowie geschützt gespeichert werden.

7.12.37 Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Der erste konfigurierte DNS-Forwarder ist nicht erreichbar und verursacht die Verzögerung.

Erwarteter Befund:
Direkte Abfragen gegen den ersten Forwarder laufen in einen Timeout.
Direkte Abfragen gegen den zweiten Forwarder funktionieren sofort.

Gegenbeweis:
Der erste Forwarder antwortet unter denselben Bedingungen schnell und korrekt.

Eine belastbare Hypothese enthält:

vermutete Ursache;

erwarteten messbaren Befund;

möglichen Gegenbeweis;

Testmethode;

Erfolgskriterium;

Risiko des Tests.

Erst danach sollte eine Änderung vorgenommen werden.

7.12.38 Kontrollierte Maßnahmen

Maßnahme	Voraussetzung	Risiko
DNS-Serveradresse korrigieren	falscher Resolver nachgewiesen	andere Namensräume können beeinflusst werden
Suffix oder NRPT-Regel korrigieren	falscher Abfrageweg nachgewiesen	VPN- und Split-DNS-Verhalten ändert sich
DNS-Datensatz korrigieren	autoritative Daten sind nachweislich falsch	Anwendungen können auf neues Ziel wechseln
PTR-Eintrag korrigieren	falscher Reverse-Eintrag bestätigt	Protokoll- oder Sicherheitszuordnung ändert sich
Forwarder korrigieren	nicht erreichbarer oder falscher Forwarder bestätigt	externe oder interne Rekursion betroffen
Delegation korrigieren	falsche NS- oder Glue-Daten bestätigt	gesamte Zone kann betroffen sein
dynamische Updates korrigieren	Updatefehler und Berechtigung nachgewiesen	viele Clients können Einträge verändern
Cache kontrolliert löschen	falscher Cacheeintrag dokumentiert	Beweisdaten gehen verloren
DNSSEC-Konfiguration korrigieren	Validierungsfehler nachgewiesen	Vertrauenskette und Sicherheit betroffen
Aging oder Scavenging anpassen	Fehlkonfiguration nachgewiesen	gültige Datensätze können gelöscht werden
Replikationsfehler beheben	AD-Replikationsfehler bestätigt	mehrere Verzeichnisdaten betroffen

Vor der Maßnahme sind zu dokumentieren:

Ausgangszustand;

betroffene Systeme und Zonen;

Berechtigung;

Risiko;

Rückweg;

Erfolgskriterium;

vorgesehenes Testverfahren.

7.12.39 Vollständiger Diagnoseablauf

Exakte Fehlermeldung aufnehmen
Wortlaut, Anwendung, Benutzer, Client und Uhrzeit dokumentieren.

Betroffenen Namen bestimmen
Kurzname, FQDN oder IP-Adresse unterscheiden.

Erwarteten Datensatztyp bestimmen
A, AAAA, CNAME, PTR, SRV, MX, TXT, NS oder SOA festlegen.

Erwartetes Ergebnis dokumentieren
Vorgesehene IP-Adresse, Zielname oder Dienstinformation festhalten.

Umfang bestimmen
Einzelnen Client, Standort, DNS-Server, Namen, Zone oder alle Systeme unterscheiden.

Anwendung und DNS abgrenzen
Direkte IP-Verbindung, Systemresolver und Anwendung getrennt prüfen.

Netzwerkzustand erfassen
Schnittstelle, Adresse, Gateway, VPN und Routing dokumentieren.

Konfigurierte DNS-Server erfassen
DNS-Server pro Schnittstelle und Reihenfolge bestimmen.

Suffixe und lokale Namensquellen prüfen
Suchliste, Hosts-Datei und Anwendungscache berücksichtigen.

Resolverrichtlinien prüfen
NRPT, Split-DNS, Container-DNS und Sicherheitsresolver berücksichtigen.

Verschlüsselten DNS-Pfad bestimmen
Klassisches DNS, DoH und DoT unterscheiden.

Normale Systemauflösung testen
Prüfen, welches Ergebnis die Anwendung grundsätzlich erhalten kann.

Direkte Abfrage durchführen
Vorgesehenen DNS-Server und Datensatztyp ausdrücklich angeben.

Antwortcode auswerten
NOERROR, NXDOMAIN, SERVFAIL, REFUSED oder Timeout unterscheiden.

Antwortinhalt auswerten
Wert, TTL, CNAME-Kette und Flags prüfen.

Antwortzeit messen
Erste und wiederholte Abfrage vergleichen.

Alternativen DNS-Server prüfen
Unterschiede zwischen vorgesehenen Resolvern dokumentieren.

Cachezustand prüfen
Positive und negative Einträge auf allen relevanten Ebenen berücksichtigen.

UDP und TCP vergleichen
Transportabhängige Fehler bestimmen.

EDNS, MTU und Fragmentierung prüfen
Besonders bei großen Antworten oder VPN-Verbindungen.

Rekursiven und autoritativen Server unterscheiden
Abfrageweg in einzelne Ebenen zerlegen.

SOA, NS und Delegation prüfen
Zuständigkeit und Zonengrenze bestätigen.

Autoritative Server direkt vergleichen
Datensatz, TTL, Seriennummer und Antwortcode auswerten.

Forwarder und Rekursion prüfen
Erreichbarkeit, Richtlinien und Timeoutpfad untersuchen.

DNSSEC prüfen
Signaturen, DS, DNSKEY, Trust Anchor und Validierungsfehler berücksichtigen.

Reverse-Lookup prüfen
PTR, Reverse-Zone, Delegation und Vorwärtskonsistenz auswerten.

DNS-Serverzustand prüfen
Dienst, Zonen, Statistiken, Last und Ereignisse untersuchen.

AD-DNS und Replikation prüfen
Wenn AD-integrierte Zonen oder SRV-Einträge beteiligt sind.

Dynamische Updates und DHCP prüfen
Registrierung, Eigentümer, Berechtigungen und Leasezustand auswerten.

Aging und Scavenging prüfen
Bei veralteten oder unerwartet fehlenden Einträgen.

Protokolle korrelieren
Client, DNS-Server, DHCP und Anwendung auf denselben Versuch begrenzen.

Bei Bedarf Netzwerkaufzeichnung durchführen
Nur zeitlich und technisch begrenzt.

Hypothese und Gegenbeweis formulieren
Ursache vor der Änderung messbar beschreiben.

Eine kontrollierte Maßnahme ausführen
Risiko, Rückweg und Erfolgskriterium beachten.

Identischen Test wiederholen
Antwortcode, Wert und Zeit mit dem Ausgangszustand vergleichen.

Alternativen Pfad erneut prüfen
Weitere Clients, Resolver oder autoritative Server kontrollieren.

Anwendung verifizieren
Nicht nur das Diagnosewerkzeug testen.

Temporäre Änderungen zurücknehmen
Logging, Testregeln und Ausnahmen entfernen.

Ursache dokumentieren
Technischen Nachweis und betroffenen Pfad festhalten.

Prävention festlegen
Monitoring, Standardisierung oder Konfigurationsverbesserung umsetzen.

7.12.40 Befundmatrix

Befund	Mögliche Einordnung	Nächster Nachweis
IP-Verbindung funktioniert, Name nicht	DNS oder lokaler Resolverpfad	direkte A-/AAAA-Abfrage
direkter DNS-Test funktioniert, Anwendung nicht	Anwendungscache, Proxy oder eigener Resolver	Anwendungsresolver und Zieladresse prüfen
nur Kurzname schlägt fehl	Suffix- oder Suchlistenproblem	FQDN und Suffixkonfiguration vergleichen
nur ein Client betroffen	lokale Konfiguration, Cache oder Hosts-Datei	anderen Client und direkte Serverabfrage vergleichen
nur ein DNS-Server betroffen	Zone, Cache, Dienst oder Replikation	DNS-Server direkt vergleichen
ganze Zone liefert `NXDOMAIN`	falscher Resolver oder fehlende Delegation	SOA, NS und autoritative Server prüfen
`NOERROR`, aber keine A-Antwort	Name vorhanden, Datensatztyp fehlt	CNAME, AAAA und SOA prüfen
`SERVFAIL`	Rekursion, DNSSEC oder Serverfehler	autoritative Abfrage und Protokolle
`REFUSED`	Richtlinie, ACL oder deaktivierte Rekursion	Serverkonfiguration und Quellnetz prüfen
Timeout	fehlende Antwort	Transport, Netzwerk und Serverlast prüfen
UDP schlägt fehl, TCP funktioniert	Firewall, MTU, Fragmentierung oder EDNS	Netzwerkaufzeichnung und große Antwort prüfen
erste Abfrage langsam, zweite schnell	Cacheeffekt	kalte und warme Abfrage vergleichen
externe Namen langsam	Forwarder oder Rekursion	Forwarder direkt prüfen
interne Namen langsam	interne Delegation, Forwarder oder AD-DNS	interne autoritative Server prüfen
mit VPN falsche Antwort	NRPT oder Split-DNS	Resolver vor und nach VPN vergleichen
Browser und System liefern verschiedene Antworten	Browser-DoH oder Anwendungscache	Browserresolver und Systemresolver vergleichen
PTR fehlt, A funktioniert	Reverse-Zone oder PTR fehlt	Reverse-Delegation prüfen
unterschiedliche Antworten je DC	AD-Replikation	`repadmin` und direkte DNS-Abfragen
nur große Antworten scheitern	EDNS-, MTU- oder Fragmentierungsproblem	UDP/TCP-Vergleich
nur signierte Zonen scheitern	DNSSEC-Validierungsfehler	DS-, DNSKEY- und EDE-Auswertung
neuer Datensatz bleibt unsichtbar	positiver oder negativer Cache	TTL und Cacheebenen prüfen
SRV vorhanden, Dienst nicht erreichbar	Zielhost, Port oder Dienst fehlerhaft	SRV-Ziel und Dienstport prüfen

7.12.41 Typische Diagnosefehler

Fehlermeldung nicht vollständig dokumentieren.

Kurzname und FQDN verwechseln.

Den benötigten Datensatztyp nicht bestimmen.

ping als vollständigen DNS-Test verwenden.

Einen erfolgreichen Ping als Nachweis des Dienstes betrachten.

Nur nslookup verwenden.

NRPT mit nslookup prüfen.

Anwendung und direkten DNS-Test gleichsetzen.

Den tatsächlich verwendeten DNS-Server nicht bestimmen.

Öffentlichen DNS-Server auf einem Domänenclient eintragen.

Cache vor der Beweissicherung löschen.

NXDOMAIN, NODATA, SERVFAIL und Timeout gleich behandeln.

Nur den Antwortcode, aber nicht den Antwortinhalt prüfen.

Nur den Antwortwert, aber nicht TTL und Quelle prüfen.

Rekursiven und autoritativen DNS-Server verwechseln.

Nur einen DNS-Server testen.

UDP und TCP nicht getrennt prüfen.

TCP-Port 53 als UDP-Nachweis verwenden.

EDNS, MTU und Fragmentierung ignorieren.

DoH oder DoT über einen klassischen DNS-Test als funktionsfähig bewerten.

DNSSEC allein mit nslookup prüfen.

+dnssec als vollständigen Validierungsnachweis interpretieren.

Öffentliche +trace-Abfrage für eine interne Split-DNS-Zone verwenden.

CNAME-, MX- oder SRV-Zielnamen nicht weiter auflösen.

Erfolgreichen SRV-Lookup mit erreichbarem Dienst gleichsetzen.

PTR-Fehler als vollständigen DNS-Ausfall bewerten.

Forwarder verändern, ohne ihr Verhalten direkt zu testen.

DNS-Dienst vorsorglich neu starten.

Zone vorsorglich neu erstellen.

Einträge löschen, ohne Eigentümer, TTL und Replikation zu prüfen.

Scavenging unkontrolliert aktivieren.

AD-Replikationsfehler durch manuelle DNS-Änderungen verdecken.

Pro Diagnoseversuch mehrere Variablen verändern.

Nur das Diagnosewerkzeug, aber nicht die Anwendung verifizieren.

Temporäre Logging- oder Firewalländerungen aktiv lassen.

7.12.42 Verifikation

Nach einer Maßnahme müssen mindestens folgende Punkte geprüft werden:

Client besitzt eine gültige Netzwerkkonfiguration;

vorgesehene DNS-Server sind eingetragen;

richtige Schnittstelle und VPN-Regel werden verwendet;

Suffixe und Suchliste sind korrekt;

Hosts-Datei enthält keinen widersprüchlichen Eintrag;

NRPT und Split-DNS funktionieren wie vorgesehen;

DoH oder DoT funktioniert, sofern vorgesehen;

exakter FQDN wird korrekt aufgelöst;

benötigter Datensatztyp ist vorhanden;

Antwortcode ist korrekt;

Antwortwert entspricht dem Sollzustand;

TTL ist plausibel;

rekursive und autoritative Antworten sind konsistent;

alle vorgesehenen DNS-Server liefern den richtigen Wert;

UDP und TCP funktionieren;

DNSSEC-Validierung funktioniert, sofern vorgesehen;

Vorwärts- und Rückwärtsauflösung stimmen überein, sofern erforderlich;

SRV-, MX- und CNAME-Ziele sind vollständig auflösbar;

AD-SRV-Einträge sind vorhanden;

AD-Replikation ist fehlerfrei;

dynamische Aktualisierung funktioniert, sofern vorgesehen;

keine neuen DNS-, DHCP- oder Replikationsfehler entstehen;

Antwortzeit entspricht der Baseline;

ursprüngliche Anwendung funktioniert;

weitere repräsentative Clients funktionieren;

temporäre Diagnoseänderungen wurden zurückgenommen;

Ursache, Maßnahme und Prävention wurden dokumentiert.

Eine einzelne erfolgreiche Cacheabfrage ist keine ausreichende Verifikation.

7.12.43 Dokumentationsvorlage

Störung:
<exakte Beschreibung>

Zeitpunkt:
<Datum und Uhrzeit>

Betroffener Client:
<Hostname und IP-Adresse>

Betroffene Anwendung:
<Anwendung oder Dienst>

Abfragename:
<FQDN oder IP-Adresse>

Datensatztyp:
<A, AAAA, CNAME, PTR, SRV, MX, TXT, NS oder SOA>

Erwartetes Ergebnis:
<Sollwert>

Tatsächliches Ergebnis:
<Istwert, Antwortcode und Antwortzeit>

Verwendeter Resolver:
<DNS-Server und Schnittstelle>

Resolverpfad:
<klassisches DNS, NRPT, VPN, DoH, DoT oder Anwendungsresolver>

Vergleichstests:
<anderer Client, DNS-Server, Transport oder autoritativer Server>

Nachgewiesene Ursache:
<technischer Befund>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genau eine kontrollierte Änderung>

Risiko und Rückweg:
<Beschreibung>

Verifikation:
<identischer Test, Anwendungstest und weitere Systeme>

Präventionsmaßnahme:
<Monitoring, Standardisierung oder Konfigurationsänderung>

7.12.44 Checkliste

7.12.45 Schnellreferenz

Aufgabe	Befehl
Windows-Netzwerkkonfiguration	`Get-NetIPConfiguration`
vollständige Windows-IP-Konfiguration	`ipconfig /all`
Windows-DNS-Serveradressen	`Get-DnsClientServerAddress`
Windows-DNS-Clientkonfiguration	`Get-DnsClient`
Linux-Resolverzustand	`resolvectl status`
macOS-Resolverzustand	`scutil --dns`
wirksame NRPT-Richtlinie	`Get-DnsClientNrptPolicy`
konfigurierte NRPT-Regeln	`Get-DnsClientNrptRule`
verschlüsselter DNS-Clientzustand	`netsh dnsclient show state`
verschlüsselte DNS-Endpunkte	`netsh dnsclient show encryption`
Systemauflösung unter Windows	`Resolve-DnsName <Name>`
direkte A-Abfrage	`Resolve-DnsName <Name> -Type A -Server <DNS-IP> -DnsOnly`
direkte AAAA-Abfrage	`Resolve-DnsName <Name> -Type AAAA -Server <DNS-IP> -DnsOnly`
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`
PTR prüfen	`Resolve-DnsName <IP> -Type PTR -Server <DNS-IP> -DnsOnly`
SOA prüfen	`Resolve-DnsName <Zone> -Type SOA -Server <DNS-IP> -DnsOnly`
NS prüfen	`Resolve-DnsName <Zone> -Type NS -Server <DNS-IP> -DnsOnly`
direkte Abfrage mit `dig`	`dig @<DNS-IP> <Name> <Typ>`
Reverse-Abfrage mit `dig`	`dig @<DNS-IP> -x <IP>`
öffentliche Delegation verfolgen	`dig <Name> <Typ> +trace`
TCP-DNS unter Windows	`Resolve-DnsName <Name> -Server <DNS-IP> -DnsOnly -TcpOnly`
TCP-DNS mit `dig`	`dig @<DNS-IP> <Name> <Typ> +tcp`
DNSSEC-Daten anfordern	`dig @<DNS-IP> <Name> <Typ> +dnssec`
Windows-Clientcache	`Get-DnsClientCache`
Windows-DNS-Dienst	`Get-Service DNS`
Windows-DNS-Zonen	`Get-DnsServerZone`
Windows-DNS-Datensätze	`Get-DnsServerResourceRecord -ZoneName <Zone>`
Windows-DNS-Forwarder	`Get-DnsServerForwarder`
Windows-DNS-Rekursion	`Get-DnsServerRecursion`
Windows-DNS-Statistiken	`Get-DnsServerStatistics`
DNS-Leistungsindikatoren	`Get-Counter -ListSet DNS`
vorhandene Windows-DNS-Protokolle	`Get-WinEvent -ListLog "DNS"`
AD-DNS-Test	`dcdiag /test:DNS /v /s:<DC-Name>`
AD-Replikationsübersicht	`repadmin /replsummary`
AD-Replikationsdetails	`repadmin /showrepl`

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

Clear-DnsClientCache
Clear-DnsServerCache
Register-DnsClient
ipconfig /flushdns
ipconfig /registerdns
Set-DnsClientServerAddress
Set-DnsServerForwarder
Set-DnsServerRecursion
Set-DnsServerCache
Set-DnsServerZoneAging
Start-DnsServerScavenging
Add-DnsServerPrimaryZone
Add-DnsServerResourceRecord
Remove-DnsServerResourceRecord
Restart-Service DNS

7.12.46 Quellen

Offizielle Microsoft-Dokumentation