# 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** 1. Zuerst beobachten und dokumentieren. 2. Den exakten Namen und Datensatztyp verwenden. 3. Clientverhalten und direkte DNS-Abfrage unterscheiden. 4. Den tatsächlich verwendeten DNS-Server bestimmen. 5. Antwortcode und Antwortinhalt getrennt bewerten. 6. Positive, negative und ausgebliebene Antworten unterscheiden. 7. Cache-, rekursive und autoritative Antworten trennen. 8. UDP, TCP, DoH und DoT nicht gleichsetzen. 9. Pro Versuch nur eine relevante Variable verändern. 10. Vor jeder Änderung Risiko und Rückweg dokumentieren. 11. Nach der Maßnahme denselben Test wiederholen. 12. 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: ```text server01 ``` ist für eine eindeutige DNS-Diagnose ungeeignet, solange nicht feststeht, welches DNS-Suffix ergänzt wird. Besser: ```text 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** ```powershell Get-NetIPConfiguration ``` ```cmd ipconfig /all ``` **Linux** ```bash ip address ``` ```bash ip route ``` **macOS** ```bash ifconfig ``` ```bash 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** ```powershell Get-DnsClientServerAddress ``` ```powershell Get-DnsClient ``` **Linux** ```bash cat /etc/resolv.conf ``` Bei `systemd-resolved`: ```bash resolvectl status ``` **macOS** ```bash 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: ```text server01 ``` kann der Resolver abhängig von seiner Suchliste nacheinander verschiedene Namen bilden: ```text server01.example.test server01.branch.example.test server01.other.example.test ``` Windows-Konfiguration prüfen: ```powershell Get-DnsClient ``` Linux mit `systemd-resolved`: ```bash resolvectl status ``` macOS: ```bash 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: ```powershell Get-DnsClientNrptPolicy ``` Konfigurierte NRPT-Regeln: ```powershell Get-DnsClientNrptRule ``` DNS-Clientzustand: ```cmd netsh dnsclient show state ``` Globale verschlüsselte DNS-Einstellungen: ```cmd netsh dnsclient show global ``` Konfigurierte DoH- oder DoT-Endpunkte: ```cmd 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: 1. Kann die Ziel-IP-Adresse direkt erreicht werden? 2. Liefert eine direkte DNS-Abfrage die erwartete Adresse? 3. Liefert der normale Betriebssystemresolver dieselbe Adresse? 4. Verwendet die Anwendung dieselbe Adresse? 5. Ist der eigentliche Dienst auf der Zieladresse erreichbar? Beispiel: ```powershell Resolve-DnsName "app.example.test" ``` Direkte Abfrage gegen einen bestimmten DNS-Server: ```powershell 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** ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` **Windows Eingabeaufforderung** ```cmd nslookup app.example.test 192.0.2.53 ``` **Linux und macOS** ```bash 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: ```powershell Resolve-DnsName "app.example.test" -Type A ``` ```powershell Resolve-DnsName "alias.example.test" -Type CNAME ``` ```powershell Resolve-DnsName "_service._tcp.example.test" -Type SRV ``` ```powershell Resolve-DnsName "example.test" -Type SOA ``` ```powershell 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** ```powershell Measure-Command { Resolve-DnsName ` -Name "app.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly } ``` **Linux und macOS** ```bash 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** ```powershell Get-DnsClientCache ``` Alternativ: ```cmd ipconfig /displaydns ``` **Linux mit systemd-resolved** ```bash resolvectl statistics ``` **Windows-DNS-Servercacheeinstellungen** ```powershell 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: 1. Ein Name wird abgefragt und liefert `NXDOMAIN`. 2. Der fehlende Datensatz wird anschließend angelegt. 3. Der Client oder rekursive Resolver liefert zunächst weiterhin die gespeicherte negative Antwort. 4. 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** ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ``` ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Type A ` -Server "192.0.2.54" ` -DnsOnly ``` **Linux und macOS** ```bash dig @192.0.2.53 app.example.test A ``` ```bash 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: ```powershell Test-NetConnection "192.0.2.53" -Port 53 ``` Dieser Befehl prüft nur TCP. Normale DNS-Abfrage: ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Server "192.0.2.53" ` -DnsOnly ``` TCP erzwingen: ```powershell Resolve-DnsName ` -Name "app.example.test" ` -Server "192.0.2.53" ` -DnsOnly ` -TcpOnly ``` Mit `dig`: ```bash dig @192.0.2.53 app.example.test A ``` ```bash 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: ```bash dig @192.0.2.53 example.com A +dnssec ``` ```bash dig @192.0.2.53 example.com A +dnssec +tcp ``` Test ohne EDNS: ```bash 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: ```cmd netsh dnsclient show state ``` ```cmd 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: 1. Client fragt vorgesehenen rekursiven DNS-Server. 2. Rekursiver Server liefert Fehler oder langsame Antwort. 3. Autoritativer DNS-Server wird direkt abgefragt. 4. 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: ```powershell Resolve-DnsName ` -Name "example.test" ` -Type SOA ` -Server "192.0.2.53" ` -DnsOnly ``` NS prüfen: ```powershell Resolve-DnsName ` -Name "example.test" ` -Type NS ` -Server "192.0.2.53" ` -DnsOnly ``` Mit `dig`: ```bash dig @192.0.2.53 example.test SOA ``` ```bash dig @192.0.2.53 example.test NS ``` Öffentliche Delegationskette verfolgen: ```bash 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: ```powershell Get-DnsServerForwarder ``` ```powershell Get-DnsServerRecursion ``` ```powershell Get-DnsServerRootHint ``` Zonen und bedingte Weiterleitungen: ```powershell 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** ```powershell Resolve-DnsName ` -Name "192.0.2.25" ` -Type PTR ` -Server "192.0.2.53" ` -DnsOnly ``` **Linux und macOS** ```bash dig @192.0.2.53 -x 192.0.2.25 ``` Danach muss der PTR-Zielname wieder vorwärts geprüft werden: ```powershell 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: ```powershell Resolve-DnsName ` -Name "example.com" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ` -DnssecOk ``` Mit `dig`: ```bash 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: ```powershell Get-Service -Name DNS ``` Zonen: ```powershell Get-DnsServerZone ``` Bestimmte Zone: ```powershell Get-DnsServerZone ` -Name "example.test" ``` Datensätze: ```powershell Get-DnsServerResourceRecord ` -ZoneName "example.test" ``` Serverstatistiken: ```powershell Get-DnsServerStatistics ``` Verfügbare Leistungsindikatoren: ```powershell 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: ```powershell Resolve-DnsName ` -Name "_ldap._tcp.dc._msdcs." ` -Type SRV ``` Kerberos-SRV-Einträge: ```powershell Resolve-DnsName ` -Name "_kerberos._tcp." ` -Type SRV ``` DNS-Test eines Domänencontrollers: ```cmd dcdiag /test:DNS /v /s: ``` Replikationsübersicht: ```cmd repadmin /replsummary ``` Replikationsdetails: ```cmd 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: ```powershell Register-DnsClient ``` Alternativ: ```cmd 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: ```powershell 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: ```text 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** 1. **Exakte Fehlermeldung aufnehmen** Wortlaut, Anwendung, Benutzer, Client und Uhrzeit dokumentieren. 2. **Betroffenen Namen bestimmen** Kurzname, FQDN oder IP-Adresse unterscheiden. 3. **Erwarteten Datensatztyp bestimmen** A, AAAA, CNAME, PTR, SRV, MX, TXT, NS oder SOA festlegen. 4. **Erwartetes Ergebnis dokumentieren** Vorgesehene IP-Adresse, Zielname oder Dienstinformation festhalten. 5. **Umfang bestimmen** Einzelnen Client, Standort, DNS-Server, Namen, Zone oder alle Systeme unterscheiden. 6. **Anwendung und DNS abgrenzen** Direkte IP-Verbindung, Systemresolver und Anwendung getrennt prüfen. 7. **Netzwerkzustand erfassen** Schnittstelle, Adresse, Gateway, VPN und Routing dokumentieren. 8. **Konfigurierte DNS-Server erfassen** DNS-Server pro Schnittstelle und Reihenfolge bestimmen. 9. **Suffixe und lokale Namensquellen prüfen** Suchliste, Hosts-Datei und Anwendungscache berücksichtigen. 10. **Resolverrichtlinien prüfen** NRPT, Split-DNS, Container-DNS und Sicherheitsresolver berücksichtigen. 11. **Verschlüsselten DNS-Pfad bestimmen** Klassisches DNS, DoH und DoT unterscheiden. 12. **Normale Systemauflösung testen** Prüfen, welches Ergebnis die Anwendung grundsätzlich erhalten kann. 13. **Direkte Abfrage durchführen** Vorgesehenen DNS-Server und Datensatztyp ausdrücklich angeben. 14. **Antwortcode auswerten** `NOERROR`, `NXDOMAIN`, `SERVFAIL`, `REFUSED` oder Timeout unterscheiden. 15. **Antwortinhalt auswerten** Wert, TTL, CNAME-Kette und Flags prüfen. 16. **Antwortzeit messen** Erste und wiederholte Abfrage vergleichen. 17. **Alternativen DNS-Server prüfen** Unterschiede zwischen vorgesehenen Resolvern dokumentieren. 18. **Cachezustand prüfen** Positive und negative Einträge auf allen relevanten Ebenen berücksichtigen. 19. **UDP und TCP vergleichen** Transportabhängige Fehler bestimmen. 20. **EDNS, MTU und Fragmentierung prüfen** Besonders bei großen Antworten oder VPN-Verbindungen. 21. **Rekursiven und autoritativen Server unterscheiden** Abfrageweg in einzelne Ebenen zerlegen. 22. **SOA, NS und Delegation prüfen** Zuständigkeit und Zonengrenze bestätigen. 23. **Autoritative Server direkt vergleichen** Datensatz, TTL, Seriennummer und Antwortcode auswerten. 24. **Forwarder und Rekursion prüfen** Erreichbarkeit, Richtlinien und Timeoutpfad untersuchen. 25. **DNSSEC prüfen** Signaturen, DS, DNSKEY, Trust Anchor und Validierungsfehler berücksichtigen. 26. **Reverse-Lookup prüfen** PTR, Reverse-Zone, Delegation und Vorwärtskonsistenz auswerten. 27. **DNS-Serverzustand prüfen** Dienst, Zonen, Statistiken, Last und Ereignisse untersuchen. 28. **AD-DNS und Replikation prüfen** Wenn AD-integrierte Zonen oder SRV-Einträge beteiligt sind. 29. **Dynamische Updates und DHCP prüfen** Registrierung, Eigentümer, Berechtigungen und Leasezustand auswerten. 30. **Aging und Scavenging prüfen** Bei veralteten oder unerwartet fehlenden Einträgen. 31. **Protokolle korrelieren** Client, DNS-Server, DHCP und Anwendung auf denselben Versuch begrenzen. 32. **Bei Bedarf Netzwerkaufzeichnung durchführen** Nur zeitlich und technisch begrenzt. 33. **Hypothese und Gegenbeweis formulieren** Ursache vor der Änderung messbar beschreiben. 34. **Eine kontrollierte Maßnahme ausführen** Risiko, Rückweg und Erfolgskriterium beachten. 35. **Identischen Test wiederholen** Antwortcode, Wert und Zeit mit dem Ausgangszustand vergleichen. 36. **Alternativen Pfad erneut prüfen** Weitere Clients, Resolver oder autoritative Server kontrollieren. 37. **Anwendung verifizieren** Nicht nur das Diagnosewerkzeug testen. 38. **Temporäre Änderungen zurücknehmen** Logging, Testregeln und Ausnahmen entfernen. 39. **Ursache dokumentieren** Technischen Nachweis und betroffenen Pfad festhalten. 40. **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** ```text Störung: Zeitpunkt: Betroffener Client: Betroffene Anwendung: Abfragename: Datensatztyp: Erwartetes Ergebnis: Tatsächliches Ergebnis: Verwendeter Resolver: Resolverpfad: Vergleichstests: Nachgewiesene Ursache: Gegenbeweis ausgeschlossen durch: Durchgeführte Maßnahme: Risiko und Rückweg: Verifikation: Präventionsmaßnahme: ``` --- **7.12.44 Checkliste** - [ ] exakte Fehlermeldung dokumentiert - [ ] Datum und Uhrzeit erfasst - [ ] betroffenen Client erfasst - [ ] betroffene Anwendung erfasst - [ ] Kurzname, FQDN und IP-Adresse unterschieden - [ ] benötigten Datensatztyp bestimmt - [ ] erwartetes Ergebnis dokumentiert - [ ] Fehlerumfang bestimmt - [ ] aktive Netzwerkschnittstelle geprüft - [ ] IP-Adresse und Gateway geprüft - [ ] VPN-Zustand dokumentiert - [ ] konfigurierte DNS-Server erfasst - [ ] DNS-Serverreihenfolge geprüft - [ ] DNS-Suffixe und Suchliste geprüft - [ ] Hosts-Datei geprüft - [ ] Anwendungscache berücksichtigt - [ ] NRPT geprüft - [ ] Split-DNS berücksichtigt - [ ] DoH oder DoT berücksichtigt - [ ] normalen Systemresolver getestet - [ ] direkte DNS-Abfrage durchgeführt - [ ] DNS-Server ausdrücklich angegeben - [ ] Antwortcode dokumentiert - [ ] Antwortinhalt dokumentiert - [ ] TTL dokumentiert - [ ] Antwortflags berücksichtigt - [ ] Antwortzeit gemessen - [ ] erste und wiederholte Abfrage verglichen - [ ] positiven Cache geprüft - [ ] negativen Cache geprüft - [ ] alternativen DNS-Server getestet - [ ] UDP getestet - [ ] TCP getestet - [ ] EDNS und MTU berücksichtigt - [ ] rekursiven Server bestimmt - [ ] autoritativen Server bestimmt - [ ] SOA geprüft - [ ] NS-Einträge geprüft - [ ] Delegation geprüft - [ ] autoritative Server direkt verglichen - [ ] Forwarder geprüft - [ ] bedingte Forwarder geprüft - [ ] Rekursion geprüft - [ ] A- und AAAA-Einträge geprüft - [ ] CNAME-Kette geprüft - [ ] SRV- oder MX-Ziele bei Bedarf geprüft - [ ] Reverse-Lookup geprüft - [ ] DNSSEC bei Bedarf geprüft - [ ] DNS-Serverdienst geprüft - [ ] Zonenstatus geprüft - [ ] Serverstatistiken geprüft - [ ] Serverlast geprüft - [ ] DNS-Ereignisse ausgewertet - [ ] AD-SRV-Einträge bei Bedarf geprüft - [ ] AD-Replikation bei Bedarf geprüft - [ ] dynamische Updates bei Bedarf geprüft - [ ] DHCP-DNS-Aktualisierung bei Bedarf geprüft - [ ] Aging und Scavenging bei Bedarf geprüft - [ ] Hypothese formuliert - [ ] Gegenbeweis festgelegt - [ ] Risiko und Rückweg dokumentiert - [ ] nur eine kontrollierte Maßnahme durchgeführt - [ ] identischen Test wiederholt - [ ] ursprüngliche Anwendung getestet - [ ] weitere repräsentative Systeme geprüft - [ ] temporäre Änderungen zurückgenommen - [ ] Ursache und Prävention dokumentiert --- **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 ` | | direkte A-Abfrage | `Resolve-DnsName -Type A -Server -DnsOnly` | | direkte AAAA-Abfrage | `Resolve-DnsName -Type AAAA -Server -DnsOnly` | | CNAME prüfen | `Resolve-DnsName -Type CNAME -Server -DnsOnly` | | SRV prüfen | `Resolve-DnsName -Type SRV -Server -DnsOnly` | | PTR prüfen | `Resolve-DnsName -Type PTR -Server -DnsOnly` | | SOA prüfen | `Resolve-DnsName -Type SOA -Server -DnsOnly` | | NS prüfen | `Resolve-DnsName -Type NS -Server -DnsOnly` | | direkte Abfrage mit `dig` | `dig @ ` | | Reverse-Abfrage mit `dig` | `dig @ -x ` | | öffentliche Delegation verfolgen | `dig +trace` | | TCP-DNS unter Windows | `Resolve-DnsName -Server -DnsOnly -TcpOnly` | | TCP-DNS mit `dig` | `dig @ +tcp` | | DNSSEC-Daten anfordern | `dig @ +dnssec` | | Windows-Clientcache | `Get-DnsClientCache` | | Windows-DNS-Dienst | `Get-Service DNS` | | Windows-DNS-Zonen | `Get-DnsServerZone` | | Windows-DNS-Datensätze | `Get-DnsServerResourceRecord -ZoneName ` | | 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:` | | AD-Replikationsübersicht | `repadmin /replsummary` | | AD-Replikationsdetails | `repadmin /showrepl` | Ändernde Befehle, die nicht als erste Diagnose verwendet werden dürfen: ```text 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** - [Microsoft Learn – Guidance for troubleshooting DNS](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-guidance) - [Microsoft Learn – Troubleshooting DNS clients](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/troubleshoot-dns-client) - [Microsoft Learn – Troubleshooting DNS servers](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/troubleshoot-dns-server) - [Microsoft Learn – Troubleshoot DNS client name resolution issues](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/troubleshoot-dns-client-resolution-issues) - [Microsoft Learn – Troubleshoot DNS name resolution on the Internet](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-name-resolution) - [Microsoft Learn – DNS queries and lookups](https://learn.microsoft.com/en-us/windows-server/networking/dns/queries-lookups) - [Microsoft Learn – DNS architecture](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-architecture) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – DnsClient PowerShell module](https://learn.microsoft.com/en-us/powershell/module/dnsclient/) - [Microsoft Learn – DnsServer PowerShell module](https://learn.microsoft.com/en-us/powershell/module/dnsserver/) - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Best practices for DNS client settings](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings) - [Microsoft Learn – Forwarders and conditional forwarders resolution timeouts](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/forwarders-resolution-timeouts) - [Microsoft Learn – Dynamic DNS Update in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/dynamic-update) - [Microsoft Learn – DNS scavenging setup](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-scavenging-setup) - [Microsoft Learn – Enable DNS logging and diagnostics](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-logging-and-diagnostics) - [Microsoft Learn – Validate and secure DNS responses using DNSSEC](https://learn.microsoft.com/en-us/windows-server/networking/dns/validate-dnssec-responses) - [Microsoft Learn – Secure DNS Client over HTTPS](https://learn.microsoft.com/en-us/windows-server/networking/dns/doh-client-support) - [Microsoft Learn – DNS encryption using DNS over HTTPS](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-encryption-dns-over-https) - [Microsoft Learn – netsh dnsclient](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-dnsclient) - [Microsoft Learn – Dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag) - [Microsoft Learn – Verify DNS functionality to support directory replication](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/troubleshoot/verify-dns-functionality-to-support-directory-replication) **Offizielle Projektdokumentation** - [ISC BIND 9 – dig manual page](https://bind9.readthedocs.io/en/latest/manpages.html) - [ISC BIND 9 – Troubleshooting](https://bind9.readthedocs.io/en/v9.18.28/chapter9.html) - [systemd – resolvectl](https://www.freedesktop.org/software/systemd/man/resolvectl.html) - [systemd – systemd-resolved](https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html) **Standards** - [RFC 1034 – Domain Names: Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://datatracker.ietf.org/doc/html/rfc1035) - [RFC 2308 – Negative Caching of DNS Queries](https://datatracker.ietf.org/doc/html/rfc2308) - [RFC 4033 – DNS Security Introduction and Requirements](https://datatracker.ietf.org/doc/html/rfc4033) - [RFC 4035 – Protocol Modifications for DNS Security Extensions](https://datatracker.ietf.org/doc/html/rfc4035) - [RFC 6891 – Extension Mechanisms for DNS](https://datatracker.ietf.org/doc/html/rfc6891) - [RFC 7766 – DNS Transport over TCP](https://datatracker.ietf.org/doc/html/rfc7766) - [RFC 7858 – DNS over Transport Layer Security](https://datatracker.ietf.org/doc/html/rfc7858) - [RFC 8484 – DNS Queries over HTTPS](https://datatracker.ietf.org/doc/html/rfc8484) - [RFC 8499 – DNS Terminology](https://datatracker.ietf.org/doc/html/rfc8499) - [RFC 8914 – Extended DNS Errors](https://datatracker.ietf.org/doc/html/rfc8914) - [RFC 9520 – Negative Caching of DNS Resolution Failures](https://datatracker.ietf.org/doc/html/rfc9520) Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.