7.11 DNS-Leistung und fehlerhafte Reverse-Lookups Kurz erklärt Eine DNS-Abfrage kann grundsätzlich funktionieren und trotzdem langsam sein. Ebenso beweist ein fehlender Reverse-Lookup nicht automatisch, dass die normale Namensauflösung gestört ist. Für eine saubere Diagnose müssen Abfragerichtung, verwendeter DNS-Server, Antwortcode, Antwortzeit, Cachezustand, Rekursion, Weiterleitung, Transportweg und Zonenverantwortung getrennt untersucht werden. 7.11.1 Ziel der Diagnose Bei DNS-Leistungsproblemen müssen folgende Fragen beantwortet werden: Ist nur eine Anwendung oder das gesamte System betroffen? Betrifft der Fehler Vorwärts- oder Rückwärtsauflösungen? Wird tatsächlich der vorgesehene DNS-Server verwendet? Antwortet der DNS-Server gar nicht, langsam oder mit einem Fehlercode? Ist der DNS-Server für die abgefragte Zone autoritativ? Stammt die Antwort aus einem Client-, Anwendungs- oder Servercache? Entsteht die Verzögerung lokal, im Netzwerk oder bei einem nachgelagerten DNS-Server? Existiert die benötigte Reverse-Lookup-Zone? Ist der PTR-Eintrag vorhanden und korrekt? Stimmen Vorwärts- und Rückwärtsauflösung überein? Betrifft der Fehler nur einen DNS-Server oder alle vorgesehenen DNS-Server? Liegt eine fehlerhafte Delegation, Weiterleitung oder dynamische Aktualisierung vor? Verwendet die Anwendung klassisches DNS, DoH, DoT oder einen eigenen Resolver? Ziel ist nicht nur eine erfolgreiche Einzelabfrage, sondern eine reproduzierbare und ausreichend schnelle Namensauflösung über den vorgesehenen DNS-Pfad. 7.11.2 Typische Störungsbilder Anwendungen starten oder verbinden sich mit deutlicher Verzögerung. Verbindungen über IP-Adresse funktionieren schneller als über den Hostnamen. Eine Anwendung wartet vor der eigentlichen Anmeldung mehrere Sekunden. Protokolle zeigen nur IP-Adressen statt Hostnamen. nslookup zeigt als DNS-Server Unknown oder UnKnown . Vorwärtsauflösung funktioniert, Rückwärtsauflösung jedoch nicht. Eine IP-Adresse liefert einen falschen oder veralteten Hostnamen. Derselbe Name liefert abhängig vom DNS-Server unterschiedliche Antworten. Die erste Abfrage ist langsam, weitere Abfragen sind schnell. Abfragen interner Namen funktionieren nur im Firmennetz oder VPN. Externe Namen sind langsam, interne Namen dagegen schnell. Nur Abfragen bestimmter Zonen sind betroffen. Kleine DNS-Antworten funktionieren, größere Antworten schlagen fehl. Abfragen über UDP schlagen fehl, über TCP funktionieren sie. Abfragen enden mit NXDOMAIN , SERVFAIL , REFUSED oder einem Timeout. Mailserver lehnen Verbindungen wegen fehlendem oder unpassendem Reverse-DNS ab. Überwachungssysteme erzeugen falsche Zuordnungen zwischen IP-Adresse und Hostname. Nach einer IP-Adressänderung bleibt der alte PTR-Eintrag bestehen. Neue Geräte erhalten einen A-Eintrag, aber keinen PTR-Eintrag. Browser und Betriebssystem liefern für denselben Namen unterschiedliche Ergebnisse. DNS funktioniert ohne VPN, aber nicht über den VPN-Tunnel. nslookup funktioniert, eine Anwendung mit NRPT-Auswertung jedoch nicht – oder umgekehrt. 7.11.3 Vorwärts- und Rückwärtsauflösung unterscheiden Abfragerichtung Eingabe Gesuchter Datensatz Ergebnis Vorwärtsauflösung IPv4 Hostname A IPv4-Adresse Vorwärtsauflösung IPv6 Hostname AAAA IPv6-Adresse Rückwärtsauflösung IPv4 IPv4-Adresse PTR unter in-addr.arpa Hostname Rückwärtsauflösung IPv6 IPv6-Adresse PTR unter ip6.arpa Hostname Beispiel: host25.example.test → 192.0.2.25 Dies ist eine Vorwärtsauflösung über einen A-Eintrag. 192.0.2.25 → host25.example.test Dies ist eine Rückwärtsauflösung über einen PTR-Eintrag. A-, AAAA- und PTR-Einträge sind getrennte DNS-Datensätze in unterschiedlichen Zonen. Ein vorhandener A- oder AAAA-Eintrag erzeugt deshalb nicht automatisch einen PTR-Eintrag, sofern kein entsprechend konfigurierter Aktualisierungsprozess vorhanden ist. 7.11.4 Aufbau einer IPv4-Rückwärtsauflösung Für IPv4 werden die Oktette der Adresse umgekehrt und mit in-addr.arpa ergänzt. Beispiel: 192.0.2.25 Daraus entsteht der Abfragename: 25.2.0.192.in-addr.arpa. Der zugehörige PTR-Eintrag kann auf folgenden Namen zeigen: host25.example.test. Für das Netz 192.0.2.0/24 lautet die typische Reverse-Lookup-Zone: 2.0.192.in-addr.arpa Der Knoten für die Adresse 192.0.2.25 lautet innerhalb dieser Zone: 25 Bei Adressbereichen, die nicht an einer Oktettgrenze delegiert werden, kann eine klassenlose Delegation nach RFC 2317 erforderlich sein. Der Zonenaufbau darf dann nicht allein aus der Subnetzmaske abgeleitet werden, sondern muss mit der tatsächlichen Delegation des Adressbereichs übereinstimmen. 7.11.5 Aufbau einer IPv6-Rückwärtsauflösung IPv6-Rückwärtsauflösungen verwenden die Zone ip6.arpa . Dabei wird: die IPv6-Adresse vollständig ausgeschrieben; jede Hexadezimalstelle einzeln betrachtet; die Reihenfolge aller Hexadezimalstellen umgekehrt; zwischen jeder Stelle ein Punkt eingefügt; ip6.arpa angehängt. Die Delegation erfolgt auf Basis einzelner Hexadezimalstellen, sogenannter Nibbles. Eine IPv6-Reverse-Zone muss deshalb anhand des tatsächlich delegierten IPv6-Präfixes erstellt werden. IPv6-Reverse-Namen dürfen nicht durch einfaches Umkehren der durch Doppelpunkte getrennten Adressblöcke gebildet werden. 7.11.6 Bedeutung eines fehlenden Reverse-Lookups Ein fehlender PTR-Eintrag bedeutet zunächst nur, dass für die IP-Adresse kein entsprechender Name über Reverse-DNS ermittelt werden konnte. Das beweist nicht automatisch: dass die Vorwärtsauflösung fehlerhaft ist; dass der Host nicht erreichbar ist; dass der Hostname nicht existiert; dass der DNS-Server vollständig ausgefallen ist; dass Active Directory nicht funktioniert; dass die IP-Adresse ungültig ist. Reverse-Lookups werden unter anderem verwendet von: Diagnosewerkzeugen; Protokollierungs- und Überwachungssystemen; Mailservern; Sicherheitsprodukten; Inventarisierungsprogrammen; Netzwerkdiensten mit Hostnamenprüfung; Anwendungen, die eingehende IP-Adressen in Namen auflösen; Administratoren bei der Auswertung von Verbindungen. Eine Anwendung kann bei einem fehlenden PTR-Eintrag ohne Verzögerung weiterarbeiten. Eine deutliche Verzögerung entsteht eher dann, wenn die Reverse-Abfrage nicht eindeutig negativ beantwortet wird, sondern in Timeouts, fehlerhaften Delegationen oder nicht erreichbaren DNS-Servern endet. 7.11.7 nslookup zeigt den DNS-Server als „Unknown“ Eine typische Ausgabe kann folgendermaßen aussehen: Server: UnKnown Address: 192.0.2.53 Das bedeutet häufig, dass für die IP-Adresse des verwendeten DNS-Servers kein auflösbarer PTR-Eintrag vorhanden ist. Diese Meldung beweist nicht, dass der DNS-Server keine anderen Anfragen beantworten kann. Zur Abgrenzung müssen kontrollierte Abfragen durchgeführt werden: nslookup host25.example.test 192.0.2.53 nslookup 192.0.2.25 192.0.2.53 PTR des DNS-Servers selbst prüfen: nslookup 192.0.2.53 192.0.2.53 Wenn die erste Abfrage erfolgreich ist, funktioniert die getestete Vorwärtsauflösung trotz der Anzeige Unknown . Der fehlende PTR-Eintrag des DNS-Servers bleibt dennoch ein zu prüfender Konfigurationsbefund. 7.11.8 DNS-Antworten richtig einordnen Ergebnis Bedeutung Einordnung NOERROR mit Antwort Abfrage wurde erfolgreich beantwortet Datensatz und Inhalt prüfen NOERROR ohne gesuchten Datensatz Name kann existieren, der angefragte Datensatztyp fehlt häufig als NODATA bezeichnet NXDOMAIN abgefragter DNS-Name existiert laut DNS-Antwort nicht Zone, Name und negative Zwischenspeicherung prüfen SERVFAIL Server konnte keine verwertbare Antwort erzeugen Weiterleitung, Delegation, DNSSEC und Serverprotokolle prüfen REFUSED Server lehnt die Abfrage aufgrund seiner Konfiguration oder Richtlinie ab Rekursion, ACL, Richtlinie und Abfragequelle prüfen FORMERR DNS-Nachricht konnte nicht korrekt verarbeitet werden Client, Server, Netzwerkgerät und Paketformat prüfen Timeout innerhalb der Wartezeit kam keine verwertbare Antwort Netzwerk, Transport, Serverlast und nachgelagerte Server prüfen Antwort mit TC UDP-Antwort wurde abgeschnitten erneuter Versuch über TCP erforderlich falsche Adresse oder falscher PTR DNS antwortet, aber mit unerwarteten Daten Zone, Replikation, Cache und Datensatz prüfen Ein Timeout ist kein DNS-Antwortcode. Er bedeutet, dass der Client innerhalb seiner Wartezeit keine verwendbare DNS-Antwort erhalten hat. 7.11.9 Ausgangszustand dokumentieren Vor Änderungen sind mindestens folgende Informationen zu erfassen: betroffener Client; betroffene Anwendung; Datum und genaue Uhrzeit; Quell-IP-Adresse; verwendete Netzwerkschnittstelle; VPN-Zustand; konfigurierte DNS-Server; DNS-Suffixe und Suchliste; abgefragter Name beziehungsweise abgefragte IP-Adresse; Abfragetyp; verwendeter DNS-Server; vollständige Antwort; Antwortcode; Antwortzeit; autoritative oder rekursive Antwort; Verhalten bei Wiederholung; Verhalten über einen alternativen DNS-Server; Verhalten bei direkter IP-Verbindung; vorhandene Client- und Servercaches; vorhandene PTR-, A-, AAAA-, CNAME- oder SRV-Einträge; letzte DNS-, DHCP- oder IP-Adressänderung; verwendeter DNS-Transport. DNS-Caches dürfen nicht gelöscht werden, bevor der ursprüngliche Cachezustand und die fehlerhafte Antwort dokumentiert wurden. 7.11.10 Verwendete DNS-Konfiguration prüfen Windows ipconfig /all Get-DnsClientServerAddress Get-DnsClient Linux cat /etc/resolv.conf Bei Systemen mit systemd-resolved zusätzlich: resolvectl status macOS scutil --dns Zu prüfen sind: welche DNS-Server tatsächlich eingetragen sind; welche Schnittstelle die DNS-Server bereitstellt; ob VPN oder Sicherheitssoftware eigene Resolver einbindet; ob interne DNS-Suffixe vorhanden sind; ob eine Suchliste zusätzliche Abfragen erzeugt; ob IPv4- und IPv6-Resolver unterschiedlich konfiguriert sind; ob Split-DNS oder eine namensbasierte Weiterleitung aktiv ist; ob öffentliche DNS-Server für interne Unternehmensnamen verwendet werden; ob die Reihenfolge der DNS-Server dem vorgesehenen Design entspricht. Die Datei /etc/resolv.conf kann bei dynamisch verwalteten Linux-Systemen nur auf einen lokalen Stub-Resolver verweisen. Bei systemd-resolved muss deshalb zusätzlich dessen tatsächliche Schnittstellenkonfiguration geprüft werden. 7.11.11 Lokale Namensquellen und Resolverpfad berücksichtigen Eine Anwendung muss nicht zwingend direkt den konfigurierten DNS-Server abfragen. Je nach Betriebssystem und Anwendung können vorher oder zusätzlich verwendet werden: lokale Hosts-Datei; DNS-Clientcache; anwendungseigener DNS-Cache; Browsercache; lokaler Stub-Resolver; VPN-Resolver; Name Resolution Policy Table unter Windows; mDNS; LLMNR; NetBIOS-Namensauflösung; Proxy; DNS over HTTPS; DNS over TLS; Container- oder Cluster-DNS; Sicherheits- beziehungsweise Filtersoftware. Hosts-Dateien: Betriebssystem Pfad Windows C:\Windows\System32\drivers\etc\hosts Linux /etc/hosts macOS /etc/hosts Eine erfolgreiche Anwendungssuche beweist nicht, dass DNS verwendet wurde. Umgekehrt beweist eine erfolgreiche direkte DNS-Abfrage nicht, dass die Anwendung denselben Resolverpfad benutzt. 7.11.12 Split-DNS, VPN und NRPT prüfen Bei Split-DNS kann derselbe Name abhängig vom verwendeten Netzwerk oder DNS-Server unterschiedliche Antworten liefern. Beispiel: app.example.test → interne IP über Unternehmens-DNS app.example.test → öffentliche IP über öffentlichen DNS Unter Windows können VPN-Profile über die Name Resolution Policy Table festlegen, welche Namensräume an bestimmte DNS-Server gesendet werden. Wirksame NRPT-Richtlinien anzeigen: Get-DnsClientNrptPolicy Konfigurierte NRPT-Regeln anzeigen: Get-DnsClientNrptRule Zu prüfen sind: welcher Namensraum von einer Regel erfasst wird; welcher DNS-Server für diesen Namensraum vorgesehen ist; ob die Regel nur bei aktivem VPN gilt; ob eine allgemeinere Regel eine spezifische Regel beeinflusst; ob interne und öffentliche Zone denselben Namen unterschiedlich beantworten; ob der VPN-Tunnel die benötigten DNS-Server erreicht; ob eine Anwendung die Windows-DNS-API verwendet. nslookup verwendet für solche Tests nicht zwingend denselben Windows-Resolverpfad wie Anwendungen, die die Windows-DNS-API und NRPT nutzen. Für die Prüfung von NRPT sollte deshalb zusätzlich Resolve-DnsName verwendet werden. 7.11.13 Verschlüsseltes DNS mit DoH und DoT abgrenzen DNS over HTTPS und DNS over TLS verändern den Transportweg der DNS-Abfrage. Dadurch können klassische Tests über UDP- oder TCP-Port 53 erfolgreich sein, obwohl der verschlüsselte DNS-Pfad fehlschlägt – oder umgekehrt. Windows-DNS-Clientzustand anzeigen: netsh dnsclient show state Globale Einstellungen anzeigen: netsh dnsclient show global Konfigurierte verschlüsselte DNS-Server anzeigen: netsh dnsclient show encryption Zu prüfen sind: verwendet das Betriebssystem DoH oder DoT? verwendet nur der Browser einen eigenen DoH-Resolver? stimmt die URI beziehungsweise der TLS-Hostname? ist das Zertifikat gültig und vertrauenswürdig? stimmt der Zertifikatsname mit dem DNS-Endpunkt überein? ist der verschlüsselte Port erreichbar? ist ein Fallback auf unverschlüsseltes DNS erlaubt? umgeht die Anwendung den Unternehmens-DNS-Server? kann der verschlüsselte Resolver interne Zonen auflösen? unterscheiden sich Antworten zwischen klassischem und verschlüsseltem DNS? Für die DNS-Serverrolle unterstützt Microsoft DoH ab Windows Server 2025 mit dem in der Microsoft-Bereitstellungsdokumentation genannten Sicherheitsupdate KB5094125 vom Juni 2026 oder einem späteren Update. Serverkonfiguration auf einem unterstützten System anzeigen: Get-DnsServerEncryptionProtocol DoH schützt den Transport zwischen DoH-Client und DNS-Server. Nachgelagerte Abfragen an Forwarder oder autoritative DNS-Server, Zonentransfers und dynamische Updates werden dadurch nicht automatisch verschlüsselt. DoH und DNSSEC erfüllen unterschiedliche Aufgaben: DoH verschlüsselt den Transportweg. DNSSEC schützt die Authentizität und Integrität signierter DNS-Daten. 7.11.14 Vorwärtsauflösung gezielt testen Windows PowerShell Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly AAAA-Eintrag: Resolve-DnsName ` -Name "host25.example.test" ` -Type AAAA ` -Server "192.0.2.53" ` -DnsOnly Windows Eingabeaufforderung nslookup host25.example.test 192.0.2.53 Linux und macOS dig @192.0.2.53 host25.example.test A dig @192.0.2.53 host25.example.test AAAA Entscheidend ist, den DNS-Server ausdrücklich anzugeben. Andernfalls können unterschiedliche Resolver, VPN-Regeln oder Cachezustände zu nicht vergleichbaren Ergebnissen führen. 7.11.15 Rückwärtsauflösung gezielt testen Windows PowerShell Resolve-DnsName ` -Name "192.0.2.25" ` -Type PTR ` -Server "192.0.2.53" ` -DnsOnly Windows Eingabeaufforderung nslookup 192.0.2.25 192.0.2.53 Linux und macOS dig @192.0.2.53 -x 192.0.2.25 Kompakte Ausgabe mit Antwort und Statistik: dig @192.0.2.53 -x 192.0.2.25 +noall +answer +comments +stats Direkte Abfrage des vollständigen Reverse-Namens: dig @192.0.2.53 25.2.0.192.in-addr.arpa PTR Zu dokumentieren sind: Status beziehungsweise Antwortcode; PTR-Zielname; TTL; autoritative Kennzeichnung; antwortender DNS-Server; Antwortzeit; Verhalten bei wiederholter Abfrage. 7.11.16 A-, AAAA-, CNAME-, PTR- und SRV-Probleme abgrenzen Datensatz Aufgabe Typischer Fehler A Name zu IPv4-Adresse falsche oder veraltete IPv4-Adresse AAAA Name zu IPv6-Adresse falsche oder nicht erreichbare IPv6-Adresse CNAME Alias zu anderem DNS-Namen fehlerhaftes Ziel oder lange Alias-Kette PTR IP-Adresse zu Name fehlender, falscher oder veralteter Reverse-Eintrag SRV Dienst zu Zielhost und Port falsches Ziel, falscher Port oder fehlender Zielhost CNAME prüfen: Resolve-DnsName ` -Name "alias.example.test" ` -Type CNAME ` -Server "192.0.2.53" ` -DnsOnly SRV prüfen: Resolve-DnsName ` -Name "_service._tcp.example.test" ` -Type SRV ` -Server "192.0.2.53" ` -DnsOnly Mit dig : dig @192.0.2.53 alias.example.test CNAME dig @192.0.2.53 _service._tcp.example.test SRV Bei CNAME- und SRV-Datensätzen muss zusätzlich geprüft werden, ob der zurückgegebene Zielname über A oder AAAA auflösbar und anschließend über den angegebenen Dienstport erreichbar ist. Ein erfolgreicher SRV-Lookup beweist nicht, dass der veröffentlichte Dienst erreichbar ist. 7.11.17 Antwortzeit reproduzierbar messen Ein einzelner Messwert reicht nicht aus. Mindestens folgende Fälle müssen getrennt betrachtet werden: erste Abfrage; unmittelbar wiederholte Abfrage; Abfrage eines sicher vorhandenen Namens; Abfrage eines nicht vorhandenen Namens; Vorwärtsauflösung; Rückwärtsauflösung; interner Name; externer Name; primärer DNS-Server; alternativer DNS-Server; UDP; TCP; mit und ohne VPN. Linux und macOS dig zeigt die DNS-Abfragezeit als Query time an: dig @192.0.2.53 host25.example.test A +stats TCP erzwingen: dig @192.0.2.53 host25.example.test A +tcp +stats Windows PowerShell Measure-Command { Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly } TCP erzwingen: Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ` -TcpOnly Measure-Command misst den gesamten PowerShell-Befehlsablauf und nicht ausschließlich die reine DNS-Übertragungszeit. Die Werte eignen sich deshalb vor allem zum kontrollierten Vergleich unter denselben Bedingungen. 7.11.18 Kalte und zwischengespeicherte Abfragen unterscheiden Eine erste rekursive Abfrage kann langsamer sein, weil der DNS-Server weitere Server kontaktieren muss. Eine Wiederholung kann aus einem Cache beantwortet werden. Beobachtung Mögliche Einordnung erste Abfrage langsam, Wiederholung schnell Server-, Client- oder Anwendungscache wirkt jede Abfrage langsam Netzwerk, Serverlast, Weiterleitung oder autoritativen Pfad prüfen nur nicht vorhandene Namen langsam negative Antworten, fehlerhafte Delegation oder Timeoutpfad prüfen nur externe Namen langsam Rekursion, Forwarder oder Internetpfad prüfen nur interne Namen langsam interne Zone, Delegation, AD-Replikation oder Standort prüfen nur Reverse-Lookups langsam Reverse-Zone, Delegation und PTR-Pfad prüfen autoritativer Server schnell, rekursiver Server langsam Rekursion, Cache oder Forwarder prüfen UDP langsam oder fehlerhaft, TCP erfolgreich Firewall, Fragmentierung, EDNS oder Netzwerkpfad prüfen Ein schneller Cachetreffer beweist nicht, dass der vollständige rekursive beziehungsweise autoritative Pfad funktioniert. 7.11.19 Windows-DNS-Clientcache prüfen Cacheinhalt anzeigen: ipconfig /displaydns Alternativ: Get-DnsClientCache Zu prüfen sind: wurde der betroffene Name bereits zwischengespeichert? ist die Antwort positiv oder negativ? ist ein veralteter Wert vorhanden? stimmt der Datensatztyp? ist die verbleibende TTL plausibel? wurde die Antwort durch einen früheren VPN- oder Netzwerkzustand erzeugt? Cache löschen: Clear-DnsClientCache Alternativ: ipconfig /flushdns Das Löschen des Clientcaches verändert den Ausgangszustand. Es darf erst nach Dokumentation und nur als kontrollierter Vergleich erfolgen. 7.11.20 TTL und negative Zwischenspeicherung berücksichtigen Die TTL bestimmt, wie lange ein Datensatz zwischengespeichert werden darf. Eine sehr niedrige TTL kann: die Anzahl der DNS-Abfragen erhöhen; rekursive DNS-Server stärker belasten; die Abhängigkeit von Netzwerk und autoritativen Servern erhöhen. Eine sehr hohe TTL kann: veraltete Antworten länger wirksam halten; geplante Änderungen verzögern; eine Fehlerkorrektur erst nach Ablauf des Caches sichtbar machen. Auch negative Antworten werden zwischengespeichert. Deshalb kann ein Name nach dem nachträglichen Anlegen des Datensatzes zunächst weiterhin als nicht vorhanden erscheinen. Zu prüfen sind: TTL des A-, AAAA-, CNAME-, SRV- oder PTR-Eintrags; SOA-Daten der betroffenen Zone; negative Cachezeit; Clientcache; rekursiver Servercache; anwendungseigener Cache. Caches dürfen nicht routinemäßig geleert werden, um eine falsche TTL- oder Zonenplanung dauerhaft zu umgehen. 7.11.21 DNS über UDP und TCP abgrenzen Klassische DNS-Abfragen verwenden häufig UDP-Port 53 . TCP-Port 53 wird unter anderem benötigt: wenn eine UDP-Antwort abgeschnitten wurde; bei größeren DNS-Antworten; bei bestimmten DNSSEC-Antworten; für Zonentransfers; wenn der Client TCP ausdrücklich verwendet. Windows-TCP-Test: Test-NetConnection "192.0.2.53" -Port 53 Dieser Befehl prüft ausschließlich TCP. Er beweist nicht, dass UDP-Port 53 funktioniert. Ein echter UDP-DNS-Test erfolgt durch eine normale DNS-Abfrage: Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly Vergleich über TCP: Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ` -TcpOnly Wenn UDP-Abfragen scheitern und TCP-Abfragen funktionieren, sind unter anderem Firewallregeln, Paketverlust, Fragmentierung, EDNS-Verarbeitung, MTU und zwischengeschaltete Netzwerkgeräte zu prüfen. 7.11.22 EDNS, MTU, Fragmentierung und DNSSEC prüfen EDNS ermöglicht unter anderem größere DNS-Antworten über UDP. Auf Netzwerkpfaden mit ungeeigneter MTU oder fehlerhafter Fragmentbehandlung können deshalb kleine Abfragen funktionieren, während größere Antworten ausfallen. Typische Hinweise: einfache A-Abfrage funktioniert; DNSKEY-, TXT- oder umfangreiche AAAA-Antwort schlägt fehl; UDP-Abfrage endet im Timeout; dieselbe Abfrage funktioniert über TCP; Problem tritt nur über VPN, Tunnel oder bestimmte Firewalls auf; SERVFAIL tritt nur bei DNSSEC-signierten Zonen auf. DNSSEC-Daten anfordern: Resolve-DnsName ` -Name "example.com" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly ` -DnssecOk Mit dig : dig @192.0.2.53 example.com A +dnssec Vergleich über TCP: dig @192.0.2.53 example.com A +dnssec +tcp EDNS testweise unterdrücken: dig @192.0.2.53 example.com A +noedns Zu beachten ist: +dnssec beziehungsweise -DnssecOk fordert DNSSEC-bezogene Daten an; das Vorhandensein solcher Daten beweist nicht allein eine erfolgreiche Validierung; ein SERVFAIL kann durch eine fehlerhafte DNSSEC-Vertrauenskette entstehen; ein erfolgreicher TCP-Test bei fehlerhaftem UDP-Verhalten weist auf den Transportpfad, nicht automatisch auf falsche Zonendaten hin; EDNS darf nicht dauerhaft deaktiviert werden, nur um einen fehlerhaften Netzwerkpfad zu umgehen. 7.11.23 Autoritative Antwort, Rekursion und Weiterleitung unterscheiden Ein DNS-Server kann eine Antwort liefern: aus einer lokal gehosteten autoritativen Zone; aus seinem Cache; über einen allgemeinen Forwarder; über einen bedingten Forwarder; über iterative Rekursion; über eine Stubzone; über eine richtliniengesteuerte Rekursionskonfiguration. Für eine saubere Diagnose sind mindestens drei Ebenen zu vergleichen: Abfrage über den vom Client verwendeten DNS-Server; Abfrage über einen alternativen vorgesehenen DNS-Server; Abfrage über den autoritativen DNS-Server der betroffenen Zone. Wenn der autoritative Server schnell und korrekt antwortet, der rekursive Server jedoch langsam ist, liegt die Ursache wahrscheinlich bei Rekursion, Cache, Weiterleitung oder Delegationspfad. 7.11.24 Delegation der Reverse-Zone prüfen Für eine Rückwärtsauflösung muss die DNS-Hierarchie auf den zuständigen autoritativen Server verweisen. Linux und macOS dig -x 192.0.2.25 +trace Zuständige Nameserver der Reverse-Zone prüfen: dig 2.0.192.in-addr.arpa NS Zu prüfen sind: existiert die übergeordnete Reverse-Zone? wurde der richtige Adressbereich delegiert? stimmen die NS-Einträge? lassen sich die Nameservernamen auflösen? sind die autoritativen Server erreichbar? antworten alle autoritativen Server gleich? existiert bei klassenlosen IPv4-Netzen eine korrekte RFC-2317-Delegation? stimmt die IPv6-Nibble-Delegation mit dem zugeteilten Präfix überein? verweist eine alte Delegation noch auf außer Betrieb genommene Server? Eine lokal erstellte Reverse-Zone ersetzt bei öffentlichen Adressen nicht die Delegation durch den Eigentümer beziehungsweise Provider des IP-Adressbereichs. 7.11.25 Private und öffentliche Reverse-Zonen unterscheiden Private IP-Adressen Für interne private Netze kann die Organisation die Reverse-Zonen auf ihren internen DNS-Servern verwalten. Zu prüfen sind: internes Adresskonzept; zuständige DNS-Server; AD-Integrations- und Replikationsbereich; DHCP-Aktualisierung; sichere dynamische Updates; Aging und Scavenging. Öffentliche IP-Adressen Der PTR-Eintrag einer öffentlichen IP-Adresse wird normalerweise durch den Betreiber verwaltet, dem der entsprechende Adressbereich delegiert wurde. Ein PTR-Eintrag für eine öffentliche IP-Adresse kann daher nicht allein dadurch veröffentlicht werden, dass in der normalen Forward-Zone der eigenen Domain ein Datensatz angelegt wird. Zu klären sind: welcher Provider den IP-Adressbereich kontrolliert; ob der Provider eine Reverse-DNS-Verwaltung anbietet; welcher Ziel-FQDN eingetragen werden soll; ob der Zielname vorwärts wieder auf die öffentliche IP-Adresse zeigt; ob mehrere öffentliche IP-Adressen oder NAT berücksichtigt werden müssen. 7.11.26 Vorwärts- und Rückwärtskonsistenz prüfen Beispiel für einen konsistenten Zustand: host25.example.test. A 192.0.2.25 25.2.0.192.in-addr.arpa. PTR host25.example.test. Anschließend wird der PTR-Zielname wieder vorwärts aufgelöst: host25.example.test. A 192.0.2.25 Prüfschritte: IP-Adresse rückwärts auflösen. PTR-Zielnamen dokumentieren. PTR-Zielnamen über A und AAAA auflösen. Prüfen, ob die ursprüngliche IP-Adresse in den Ergebnissen enthalten ist. Alle beteiligten autoritativen DNS-Server vergleichen. Mögliche Befunde: Befund Einordnung kein PTR vorhanden Reverse-Eintrag fehlt oder Zone ist nicht erreichbar PTR zeigt auf alten Hostnamen veralteter Datensatz PTR-Zielname existiert nicht unvollständige DNS-Konfiguration PTR-Zielname zeigt auf andere IP Vorwärts- und Rückwärtsdaten stimmen nicht überein mehrere PTR-Einträge technisch möglich, kann Anwendungen jedoch unterschiedlich beeinflussen mehrere A- oder AAAA-Adressen kann bei Clustern, Load Balancing oder Mehrfachanbindung vorgesehen sein verschiedene DNS-Server liefern verschiedene PTR-Werte Replikation, Zonentransfer oder uneinheitliche Konfiguration prüfen Eine Vorwärts-Rückwärts-Konsistenz ist nicht für jede DNS-Anwendung zwingend vorgeschrieben. Bestimmte Mail-, Sicherheits- oder Identitätsprüfungen können sie jedoch voraussetzen. 7.11.27 Windows-DNS-Serverdienst und Zonen prüfen Auf dem DNS-Server: Get-Service -Name DNS Zonen anzeigen: Get-DnsServerZone Nur Reverse-Lookup-Zonen: Get-DnsServerZone | Where-Object { $_.IsReverseLookupZone } Zustand einer bestimmten Zone: Get-DnsServerZone ` -Name "2.0.192.in-addr.arpa" Zu prüfen sind: läuft der DNS-Serverdienst? ist die Zone geladen? ist die Zone primär, sekundär, Stub- oder AD-integriert? ist die Zone angehalten? ist sie für dynamische Updates vorgesehen? auf welche Server wird sie repliziert? existieren mehrere widersprüchliche Zonen für denselben Namensraum? liegt eine veraltete sekundäre Zone vor? ist die Zone nur auf einem Teil der DNS-Server vorhanden? Ein laufender DNS-Dienst beweist nicht, dass eine bestimmte Zone korrekt geladen oder erreichbar ist. 7.11.28 PTR-Datensätze auf dem Windows-DNS-Server prüfen Alle PTR-Einträge einer Zone: Get-DnsServerResourceRecord ` -ZoneName "2.0.192.in-addr.arpa" ` -RRType PTR Bestimmten Eintrag prüfen: Get-DnsServerResourceRecord ` -ZoneName "2.0.192.in-addr.arpa" ` -Name "25" ` -RRType PTR Von einem bestimmten DNS-Server lesen: Get-DnsServerResourceRecord ` -ComputerName "dns01.example.test" ` -ZoneName "2.0.192.in-addr.arpa" ` -Name "25" ` -RRType PTR Zu vergleichen sind: Knotenname; PTR-Zielname; TTL; Zeitstempel; statischer oder dynamischer Datensatz; Ergebnis auf weiteren DNS-Servern; zugehöriger A- oder AAAA-Eintrag; aktuelle IP-Zuweisung. Ein fehlender beziehungsweise als statisch dargestellter Zeitstempel kann auf einen statisch angelegten Datensatz hinweisen. Solche Datensätze werden nicht wie dynamisch gealterte Datensätze behandelt. 7.11.29 Rekursion, Forwarder und Cache des Windows-DNS-Servers prüfen Allgemeine Forwarder: Get-DnsServerForwarder Rekursionseinstellungen: Get-DnsServerRecursion Root Hints: Get-DnsServerRootHint Cacheeinstellungen: Get-DnsServerCache Zu prüfen sind: sind die Forwarder erreichbar? antworten alle Forwarder zuverlässig? ist ihre Reihenfolge beziehungsweise Verfügbarkeit plausibel? ist Rekursion aktiviert, wenn sie benötigt wird? existiert ein bedingter Forwarder für die betroffene Zone? verweist der bedingte Forwarder auf aktuelle Server? sind Root Hints vorgesehen und verwendbar? sind Cachegrenzen und negative Cachezeit plausibel? bestehen DNS-Richtlinien oder Rekursionsbereiche? unterscheiden sich die Einstellungen zwischen DNS-Servern? Nicht erreichbare Forwarder können Verzögerungen verursachen, bevor ein weiterer Forwarder oder ein alternativer Auflösungspfad verwendet wird. 7.11.30 DNS-Serverstatistiken auswerten Aggregierte Statistiken: Get-DnsServerStatistics Statistiken einer bestimmten Zone: Get-DnsServerStatistics ` -ZoneName "2.0.192.in-addr.arpa" Die genaue Struktur der Ausgabe hängt von der Windows-Server-Version ab. Zu untersuchen sind unter anderem: empfangene Abfragen; gesendete Antworten; Rekursionsvorgänge; Timeouts; Serverfehler; Formatfehler; abgelehnte Abfragen; Cacheverhalten; dynamische Updates; Paket- und Speicherstatistiken. Statistiken dürfen nicht ohne vorherige Sicherung des Ausgangswerts zurückgesetzt werden. Das Cmdlet kann bei zonenbezogener Verwendung mit -Clear Zähler verändern. Diese Option ist deshalb keine rein lesende Diagnosemaßnahme. 7.11.31 Leistungsindikatoren überwachen Verfügbare DNS-Leistungsindikatoren anzeigen: Get-Counter -ListSet DNS Beispiel für empfangene DNS-Abfragen und gesendete Antworten: Get-Counter ` '\DNS\Total Query Received/sec', '\DNS\Total Response Sent/sec' ` -SampleInterval 2 ` -MaxSamples 10 DNS-Prozess überwachen: Get-Counter ` '\Process(dns)\% Processor Time', '\Process(dns)\Working Set' ` -SampleInterval 2 ` -MaxSamples 10 Die Namen der Leistungsindikatoren können auf lokalisierten Windows-Systemen abweichen. Deshalb sollte zuerst Get-Counter -ListSet DNS verwendet werden. Zu korrelieren sind: Abfragen pro Sekunde; Antworten pro Sekunde; CPU-Auslastung des DNS-Prozesses; Arbeitsspeicher; Netzwerkauslastung; Timeouts und Fehler; rekursive Abfragen; Antwortzeit aus Clientsicht; Zeitpunkt der Störung. Eine hohe Anzahl von Abfragen ist allein kein Fehler. Entscheidend sind Baseline, Hardware, Abfrageart, Cachetreffer, Rekursion, Fehlerquote und Antwortzeit. 7.11.32 Protokollierung kontrolliert einsetzen Windows DNS Server stellt unter anderem folgende Ereignisprotokolle bereit: Applications and Services Logs └─ Microsoft └─ Windows └─ DNS-Server ├─ Audit └─ Analytical Das Audit-Protokoll erfasst administrative und sicherheitsrelevante DNS-Vorgänge. Das analytische Protokoll kann detaillierte Abfrageinformationen liefern, ist jedoch standardmäßig nicht aktiviert. Zu beachten ist: analytische Protokollierung nur gezielt aktivieren; Start- und Endzeit dokumentieren; ausreichenden Speicherplatz sicherstellen; Datenschutz und Schutz der DNS-Abfragedaten berücksichtigen; Protokollierung nach der Diagnose wieder zurücksetzen; Serverleistung während der Aufzeichnung überwachen; keine vollständigen internen DNS-Protokolle ungeschützt weitergeben. Microsoft weist darauf hin, dass analytische DNS-Protokollierung bei sehr hohen Abfrageraten messbare Leistungseinflüsse verursachen kann. Deshalb muss sie mit den Leistungswerten des Servers korreliert werden. 7.11.33 Netzwerkaufzeichnung gezielt verwenden Wenn DNS-Abfragen weiterhin unklar bleiben, kann eine zeitlich und inhaltlich begrenzte Netzwerkaufzeichnung erforderlich sein. Zu prüfen sind: Quell- und Ziel-IP-Adresse; verwendeter Port; UDP oder TCP; DNS-Transaktions-ID; Abfragetyp; Antwortcode; Wiederholungen; abgeschnittene UDP-Antworten; anschließender TCP-Versuch; Paketverlust; ICMP-Fehlermeldungen; Verzögerung zwischen Abfrage und Antwort; Wechsel zu einem weiteren DNS-Server; EDNS- und DNSSEC-bezogene Größenprobleme; TLS-Verbindungsaufbau bei DoH oder DoT. DNS-Pakete können interne Hostnamen, Dienstnamen und andere schützenswerte Informationen enthalten. Aufzeichnungen müssen deshalb nach Sicherheits- und Datenschutzvorgaben behandelt werden. 7.11.34 Dynamische DNS-Aktualisierung prüfen Windows-Clients können ihre DNS-Namen dynamisch registrieren: Register-DnsClient Alternativ: ipconfig /registerdns Diese Befehle lösen eine dynamische Aktualisierung aus und verändern damit möglicherweise den DNS-Zustand. Vorher sind vorhandene Datensätze, Zeitstempel und Ereignisse zu dokumentieren. Zu prüfen sind: existiert die Forward-Lookup-Zone? existiert die passende Reverse-Lookup-Zone? sind dynamische Updates für beide Zonen erlaubt? werden ausschließlich sichere dynamische Updates verwendet? soll der Client oder der DHCP-Server den PTR-Eintrag registrieren? besitzt das aktualisierende Konto die erforderlichen Rechte? gehört ein vorhandener Datensatz einem anderen Aktualisierungskonto? existiert ein veralteter statischer Eintrag? wird die Schnittstelle für DNS-Registrierung verwendet? stimmen Verbindungssuffix und Zonenname? sind mehrere aktive Schnittstellen beteiligt? erscheinen Aktualisierungsfehler in den DNS-, DHCP- oder Clientprotokollen? Das wiederholte Ausführen von Register-DnsClient behebt keine fehlende Reverse-Zone, falsche Berechtigungen oder fehlerhafte DHCP-DNS-Einstellungen. 7.11.35 DHCP und PTR-Registrierung prüfen Bei dynamisch vergebenen IP-Adressen kann der DHCP-Server DNS-Einträge im Auftrag des Clients aktualisieren. Zu untersuchen sind: DHCP-Bereich und aktuelle Lease; zugeteilte IP-Adresse; Clientname und FQDN; DNS-Optionen des DHCP-Bereichs; Einstellung zur Aktualisierung von A- und PTR-Einträgen; Verhalten bei Lease-Ablauf und Adressfreigabe; verwendete DHCP-DNS-Anmeldeinformationen; Berechtigungen und Eigentümer vorhandener DNS-Datensätze; mehrere DHCP-Server; Failover-Konfiguration; AD-Replikation der DNS-Zone; DHCP-Serverereignisse zum Zeitpunkt der Aktualisierung. Mögliche Fehlerbilder: A-Eintrag wird erstellt, PTR-Eintrag jedoch nicht; neuer PTR-Eintrag wird angelegt, alter PTR bleibt bestehen; PTR zeigt auf den Namen eines früheren Lease-Nehmers; ein DHCP-Server kann den Datensatz aktualisieren, ein anderer nicht; statischer Datensatz verhindert die erwartete Aktualisierung; die Reverse-Zone existiert nur auf einem Teil der DNS-Server. 7.11.36 Aging und Scavenging berücksichtigen Aging und Scavenging können veraltete dynamische DNS-Datensätze entfernen. Die Funktion beinhaltet Löschvorgänge und muss deshalb kontrolliert geplant werden. Zu prüfen sind: ist Aging für die Zone aktiviert? ist Scavenging auf einem geeigneten DNS-Server aktiviert? wie lang sind No-Refresh- und Refresh-Intervall? wie lang ist der Scavenging-Zyklus? besitzt der Datensatz einen dynamischen Zeitstempel? ist der Datensatz statisch? wurde die Zone neu erstellt oder die Funktion nachträglich aktiviert? stimmt die Konfiguration zwischen Forward- und Reverse-Zone? können aktive Geräte ihre Datensätze rechtzeitig aktualisieren? passen DHCP-Leasezeit und DNS-Alterungskonzept zusammen? wurde ein Datensatz bereits als veraltet eingestuft? Scavenging sollte nicht spontan aktiviert oder manuell erzwungen werden, nur weil einzelne PTR-Einträge veraltet sind. Eine falsche Konfiguration kann gültige DNS-Datensätze löschen. 7.11.37 Active-Directory-integrierte DNS-Zonen prüfen Bei AD-integrierten Zonen können unterschiedliche Antworten auf Replikationsprobleme hinweisen. DNS-Test für einen Domänencontroller: dcdiag /test:DNS /v /s: Replikationsübersicht: repadmin /replsummary Replikationsdetails: repadmin /showrepl Zu prüfen sind: Replikationsbereich der Zone; vorhandene Verzeichnispartition; letzte erfolgreiche Replikation; betroffene Quell- und Ziel-Domänencontroller; DNS- und RPC-Fehler; unterschiedliche Datensatzstände; nur auf einzelnen DCs vorhandene PTR-Einträge; verzögerte Löschung veralteter Einträge; Zustand von AD DS und DNS-Serverdienst. Eine erzwungene Replikation ist keine erste Diagnosemaßnahme. Zuerst müssen Richtung, Partner, Fehlercode und Ursache bestimmt werden. 7.11.38 Systematischer Diagnoseablauf Störungsbild dokumentieren Client, Anwendung, Name oder IP-Adresse, Uhrzeit und genaue Verzögerung erfassen. Abfragerichtung bestimmen Vorwärtsauflösung, Rückwärtsauflösung oder beide unterscheiden. Umfang bestimmen Einzelner Client, Anwendung, Standort, Zone oder alle Systeme unterscheiden. Resolverpfad erfassen DNS-Server, VPN, Suchsuffixe, Hosts-Datei, NRPT, DoH, DoT und lokale Resolver prüfen. Abfrage reproduzieren Den vorgesehenen DNS-Server ausdrücklich angeben. Antwortcode dokumentieren NOERROR , NXDOMAIN , SERVFAIL , REFUSED oder Timeout unterscheiden. Antwortzeit messen Erste und wiederholte Abfrage getrennt messen. Vorwärts- und Reverse-Abfrage vergleichen A beziehungsweise AAAA und PTR unabhängig testen. Alternativen DNS-Server testen Unterschiedliche Serverantworten dokumentieren. UDP und TCP vergleichen Transportabhängige Fehler abgrenzen. DoH oder DoT abgrenzen Verschlüsselten und klassischen DNS-Pfad getrennt prüfen. Autoritativen Server bestimmen Delegation und zuständige Zone prüfen. Direkte autoritative Abfrage durchführen Rekursion und Forwarder vom Zonenzustand trennen. PTR-Datensatz prüfen Zielname, TTL, Zeitstempel und Eigentümer auswerten. Vorwärts-Rückwärts-Konsistenz prüfen PTR-Zielnamen erneut über A und AAAA auflösen. Weitere Datensatztypen prüfen CNAME- oder SRV-Abhängigkeiten berücksichtigen. Cachezustand prüfen Client-, Server- und Anwendungscache unterscheiden. Forwarder und Rekursion prüfen Besonders bei langsamen externen oder bedingt weitergeleiteten Zonen. EDNS, MTU und DNSSEC prüfen Wenn kleine Antworten funktionieren und größere Antworten ausfallen. Serverleistung prüfen Abfragerate, CPU, Speicher, Fehler und Timeouts korrelieren. Dynamische Aktualisierung prüfen Client, DHCP, Berechtigungen und Zonenrichtlinie untersuchen. Aging und Scavenging prüfen Veraltete oder unerwartet gelöschte Datensätze abgrenzen. AD-Replikation prüfen Wenn DNS-Server unterschiedliche Antworten liefern. Hypothese formulieren Erwarteten Befund und möglichen Gegenbeweis festlegen. Eine kontrollierte Maßnahme durchführen Risiko, Rückweg und Erfolgskriterium dokumentieren. Erneut unter denselben Bedingungen messen Antwort, Code und Zeit mit dem Ausgangswert vergleichen. Gesamten DNS-Pfad verifizieren Client, rekursiven Server, autoritativen Server und Anwendung prüfen. Präventionsmaßnahme dokumentieren Ursache und dauerhafte Verbesserung festhalten. 7.11.39 Befundmatrix Befund Mögliche Erklärung Nächster Nachweis nslookup zeigt Unknown , andere Abfragen funktionieren PTR des DNS-Servers fehlt DNS-Server-IP rückwärts abfragen Vorwärtsauflösung funktioniert, Reverse nicht PTR oder Reverse-Zone fehlt PTR-Abfrage und Zonenprüfung Reverse-Abfrage endet sofort mit NXDOMAIN Name oder Zone meldet Nichtvorhandensein Autorität und SOA der Antwort prüfen Reverse-Abfrage läuft in Timeout Server, Delegation oder Netzwerkpfad antwortet nicht autoritative Server und Paketpfad prüfen PTR zeigt auf alten Hostnamen veralteter statischer oder dynamischer Eintrag Lease, Zeitstempel und Datensatzeigentümer prüfen PTR-Zielname besitzt keinen A-/AAAA-Eintrag unvollständige DNS-Konfiguration Zielnamen vorwärts auflösen PTR-Zielname zeigt auf andere IP Vorwärts-Rückwärts-Abweichung vorgesehene Mehrfachadressierung prüfen erste Abfrage langsam, zweite schnell Cacheeffekt kalte und warme Messung vergleichen jede externe Abfrage langsam Forwarder oder Rekursion direkte Abfragen gegen Forwarder und Autorität nur interne Zone langsam interne Delegation oder AD-DNS autoritative interne Server vergleichen nur ein DNS-Server liefert falsche Antwort lokaler Cache, Zone oder Replikation Server direkt vergleichen UDP fehlerhaft, TCP erfolgreich Firewall, EDNS, Fragmentierung oder MTU Transportvergleich und Netzwerkaufzeichnung SERVFAIL nur bei signierter Zone DNSSEC-Validierung oder Delegation Validierungskette und Serverereignisse prüfen REFUSED Rekursion oder Richtlinie verweigert Abfrage Serverrichtlinie und Quellnetz prüfen A-Eintrag vorhanden, PTR fehlt Reverse-Zone oder Updatepfad fehlt DHCP-, Client- und Zonenupdate prüfen PTR wird nach IP-Wechsel nicht entfernt Aging, Scavenging oder DHCP-Bereinigung Leaseablauf, Zeitstempel und Zonenalterung unterschiedliche Antworten je DC AD-Replikation oder uneinheitliche Zone repadmin , dcdiag und direkte Abfragen Auflösung über IP schnell, über Namen langsam DNS oder nachgelagerte Namensprüfung direkte DNS-Zeit und Anwendungspfad vergleichen öffentliche IP besitzt keinen PTR Provider hat keinen Reverse-Eintrag gesetzt Betreiber des IP-Präfixes ermitteln neuer Datensatz bleibt zunächst unsichtbar positiver oder negativer Cache TTL und Cacheebenen prüfen nslookup und Anwendung liefern verschiedene Ergebnisse NRPT, DoH oder anwendungseigener Resolver tatsächlichen Resolverpfad bestimmen nur große Antworten schlagen fehl EDNS-, MTU- oder Fragmentierungsproblem UDP/TCP und Antwortgrößen vergleichen SRV wird gefunden, Dienst funktioniert nicht Zielhost, Port oder Dienst fehlerhaft SRV-Ziel und Dienstport prüfen CNAME wird aufgelöst, Zielname jedoch nicht fehlerhaftes Aliasziel CNAME-Kette vollständig prüfen klassisches DNS funktioniert, DoH nicht Zertifikat, HTTPS-Port oder DoH-Endpunkt DoH-Zustand und TLS-Verbindung prüfen 7.11.40 Ursachen und erforderliche Nachweise Mögliche Ursache Erforderlicher Nachweis falscher DNS-Server Clientkonfiguration und direkte Abfragen bestätigen abweichenden Resolver falsches DNS-Suffix Resolverkonfiguration zeigt unerwartete Suchdomäne Hosts-Datei überschreibt DNS lokaler Eintrag liefert abweichende Zuordnung anwendungseigener DNS-Cache Anwendung liefert trotz korrektem Systemtest alten Wert NRPT-Fehler wirksame Richtlinie leitet den Namensraum an falschen Resolver fehlerhafter Split-DNS-Pfad interne und externe Resolver liefern unbeabsichtigt verschiedene Antworten DoH- oder DoT-Fehler verschlüsselter Pfad scheitert bei funktionierendem klassischem DNS fehlende Reverse-Zone zuständiger DNS-Server besitzt oder erreicht die Zone nicht fehlender PTR-Eintrag autoritative PTR-Abfrage liefert keinen Datensatz falscher PTR-Eintrag autoritative Antwort enthält unerwarteten Zielnamen fehlerhafte Delegation übergeordnete Zone verweist auf falsche oder nicht erreichbare Server fehlerhafte RFC-2317-Konfiguration CNAME- und Zonendelegation des Teilnetzes sind unvollständig fehlerhafte IPv6-Reverse-Zone Nibble-Zone stimmt nicht mit dem delegierten Präfix überein nicht erreichbarer Forwarder direkte Abfrage zum Forwarder scheitert reproduzierbar langsamer autoritativer Server direkte autoritative Abfrage zeigt erhöhte Antwortzeit UDP-Blockierung UDP-DNS scheitert, TCP-DNS funktioniert TCP-Blockierung abgeschnittene UDP-Antwort kann nicht über TCP wiederholt werden Paketverlust Aufzeichnung zeigt Wiederholungen oder fehlende Antworten MTU- oder Fragmentierungsproblem große UDP-Antworten scheitern, TCP funktioniert DNS-Serverüberlastung erhöhte Antwortzeit korreliert mit Abfragerate und Ressourcenlast ungeeignete TTL Datensatz- und Cachewerte bestätigen zu kurze oder zu lange Speicherung negativer Cache zuvor negative Antwort bleibt bis zum Ablauf wirksam falscher CNAME Alias verweist auf fehlenden oder falschen Zielnamen falscher SRV-Eintrag Dienstziel, Port, Priorität oder Gewicht sind unzutreffend DHCP aktualisiert PTR nicht DHCP-Ereignis oder Konfiguration bestätigt fehlgeschlagene Aktualisierung fehlende Updateberechtigung DNS- oder DHCP-Protokoll zeigt Zugriffsfehler veralteter statischer PTR statischer Datensatz enthält alten Namen fehlerhaftes Scavenging Konfiguration oder Ereignisse bestätigen unerwartete Löschung AD-Replikationsproblem DNS-Server liefern unterschiedliche autoritative Daten und repadmin meldet Fehler DNSSEC-Validierungsfehler SERVFAIL und Validierungsdaten bestätigen fehlerhafte Vertrauenskette öffentlicher PTR nicht delegiert Provider beziehungsweise Präfixbetreiber bestätigt fehlende Reverse-Konfiguration 7.11.41 Kontrollierte Maßnahmen, Risiko und Rückweg Maßnahme Risiko Rückweg beziehungsweise Kontrolle vorgesehenen DNS-Server konfigurieren andere Namensräume können beeinflusst werden bisherige DNS-Werte dokumentieren falsches DNS-Suffix korrigieren Suchverhalten verändert sich ursprüngliche Suffixliste sichern fehlerhaften Hosts-Eintrag entfernen Anwendung verliert lokale Sonderzuordnung Datei und ursprünglichen Eintrag sichern NRPT-Regel korrigieren VPN-Namensauflösung kann ausfallen bisherige Regel und Zielserver sichern DoH- oder DoT-Konfiguration korrigieren Transport und Fallbackverhalten ändern sich bisherigen Verschlüsselungszustand dokumentieren fehlende Reverse-Zone anlegen falscher Adressbereich kann überschrieben werden Netz-ID und Zuständigkeit vorher bestätigen PTR-Eintrag anlegen falscher Name wird veröffentlicht IP, FQDN und Forward-Eintrag vorher prüfen veralteten PTR korrigieren bestehende Abhängigkeiten können betroffen sein alten Wert und Eigentümer dokumentieren Forwarder korrigieren externe und interne Auflösung kann beeinflusst werden bisherige Forwarderliste sichern Delegation korrigieren gesamter Reverse-Bereich kann betroffen sein bisherige NS- und CNAME-Daten sichern dynamische Updates korrigieren viele Clients können Datensätze verändern Zonenrichtlinie und Berechtigungen dokumentieren Clientregistrierung auslösen mehrere A- oder PTR-Einträge können entstehen vorhandene Einträge vorher erfassen Clientcache kontrolliert löschen ursprünglicher Cachebefund geht verloren Cacheinhalt vorher dokumentieren DNS-Servercache löschen viele Abfragen müssen erneut rekursiv aufgelöst werden nur gezielt und mit Lastkontrolle TTL ändern Cacheverhalten vieler Resolver ändert sich bisherigen Wert und Änderungszeit sichern Aging oder Scavenging anpassen gültige Datensätze können gelöscht werden Zonenexport und Änderungsplan vorsehen AD-Replikationsfehler beheben mehrere DNS- und AD-Daten können betroffen sein DC-spezifischen Wiederherstellungsplan verwenden analytische Protokollierung aktivieren Leistung und Datenschutz können betroffen sein Zeitfenster, Speicherlimit und Abschaltung festlegen Pro Diagnoseversuch sollte möglichst nur eine relevante Variable verändert werden. 7.11.42 Beispiel: Reverse-Zone und PTR-Eintrag anlegen Die folgenden Befehle sind verändernde Administrationsmaßnahmen und dürfen erst nach Prüfung von Netzbereich, Zonenverantwortung, Replikationsbereich und bestehender Konfiguration ausgeführt werden. AD-integrierte IPv4-Reverse-Zone für das Dokumentationsnetz 192.0.2.0/24 : Add-DnsServerPrimaryZone ` -NetworkID "192.0.2.0/24" ` -ReplicationScope "Forest" PTR-Eintrag für 192.0.2.25 : Add-DnsServerResourceRecordPtr ` -Name "25" ` -ZoneName "2.0.192.in-addr.arpa" ` -PtrDomainName "host25.example.test." Danach kontrollieren: Get-DnsServerResourceRecord ` -ZoneName "2.0.192.in-addr.arpa" ` -Name "25" ` -RRType PTR Resolve-DnsName ` -Name "192.0.2.25" ` -Type PTR ` -Server "192.0.2.53" ` -DnsOnly Zusätzlich muss der PTR-Zielname vorwärts geprüft werden: Resolve-DnsName ` -Name "host25.example.test" ` -Type A ` -Server "192.0.2.53" ` -DnsOnly Die Beispieladressen und Namen dienen ausschließlich der Dokumentation und müssen durch die tatsächlich autorisierten Werte ersetzt werden. 7.11.43 Verifikation Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen: Client verwendet die vorgesehenen DNS-Server; richtige Netzwerkschnittstelle und VPN-Regel sind aktiv; DNS-Suffixe und Suchliste sind korrekt; NRPT-Regeln wirken wie vorgesehen; verwendeter DNS-Transport ist bestimmt; Vorwärtsauflösung liefert den erwarteten A- beziehungsweise AAAA-Eintrag; Rückwärtsauflösung liefert den erwarteten PTR-Eintrag; PTR-Zielname lässt sich vorwärts auflösen; ursprüngliche IP-Adresse ist in der Vorwärtsantwort enthalten, sofern vorgesehen; CNAME- und SRV-Ziele sind auflösbar; alle autoritativen DNS-Server liefern denselben Datensatz; rekursive DNS-Server liefern konsistente Antworten; erste und wiederholte Antwortzeit sind plausibel; UDP- und TCP-Auflösung funktionieren; DoH oder DoT funktioniert, sofern vorgesehen; negative Cacheeinträge sind abgelaufen oder kontrolliert entfernt; Forwarder und bedingte Forwarder antworten; Reverse-Zone ist korrekt delegiert; AD-integrierte Zone repliziert fehlerfrei; dynamische Aktualisierung funktioniert, sofern vorgesehen; DHCP erzeugt oder entfernt PTR-Einträge korrekt; Aging und Scavenging löschen keine aktiven Datensätze; DNSSEC-validierte Zonen verursachen keine neuen Fehler; keine neuen DNS-, DHCP- oder Replikationsfehler entstehen; betroffene Anwendung verwendet die korrigierte Auflösung; temporäre Diagnoseprotokollierung wurde zurückgenommen; Ursache, Maßnahme und Prävention wurden dokumentiert. Eine einzelne erfolgreiche Cacheabfrage ist keine ausreichende Verifikation des vollständigen DNS-Pfads. 7.11.44 Präventionsmaßnahmen Forward- und Reverse-Zonen gemeinsam planen; Zuständigkeiten für private und öffentliche Reverse-Zonen dokumentieren; PTR-Einträge für wichtige Server und Infrastrukturkomponenten pflegen; DNS-Server selbst mit korrekten PTR-Einträgen versehen; Vorwärts- und Rückwärtskonsistenz regelmäßig prüfen; DNS-Server redundant bereitstellen; autoritative und rekursive Rollen dokumentieren; Forwarder und bedingte Forwarder überwachen; Reverse-Delegationen regelmäßig kontrollieren; klassenlose IPv4-Delegationen eindeutig dokumentieren; IPv6-Reverse-Zonen anhand der delegierten Präfixe planen; DNS-Antwortzeiten und Fehlerquoten als Baseline erfassen; Abfrageraten, CPU, Speicher und Netzwerk überwachen; UDP- und TCP-Port 53 in Firewallkonzepten berücksichtigen; DoH-, DoT-, DNSSEC- und EDNS-Verhalten bei Netzwerkänderungen testen; MTU und Fragmentierung auf VPN- und Tunnelpfaden berücksichtigen; TTL-Werte an Änderungs- und Lastanforderungen anpassen; negative Cachezeiten berücksichtigen; DHCP- und DNS-Aktualisierungsverantwortung eindeutig festlegen; abgesicherte Aktualisierungsverfahren verwenden; Aging und Scavenging zuerst in kontrolliertem Umfang testen; AD-Replikation überwachen; Zonenänderungen protokollieren; veraltete statische Einträge regelmäßig prüfen; VPN-, Split-DNS-, NRPT- und DoH-Konfigurationen dokumentieren; Anwendungen mit eigenem DNS-Verhalten erfassen; Runbooks für langsame DNS-Abfragen und fehlerhafte PTR-Einträge testen. 7.11.45 Typische Fehler bei der Diagnose Unknown in nslookup sofort als vollständigen DNS-Ausfall bewerten. Vorwärts- und Rückwärtsauflösung gleichsetzen. Einen vorhandenen A-Eintrag als Beweis für einen PTR-Eintrag betrachten. Einen fehlenden PTR-Eintrag automatisch als Verbindungsursache einstufen. Die Antwortzeit nicht messen. Nur eine einzelne Abfrage durchführen. Cachetreffer und vollständige Rekursion nicht unterscheiden. Den verwendeten DNS-Server nicht ausdrücklich angeben. Anwendungsergebnis und direkte DNS-Abfrage gleichsetzen. Hosts-Datei, VPN, NRPT, DoH oder Anwendungscache ignorieren. nslookup als vollständigen Test einer NRPT-Regel verwenden. Test-NetConnection -Port 53 als UDP-DNS-Test verwenden. Nur UDP oder nur TCP prüfen. NXDOMAIN , SERVFAIL und Timeout gleich behandeln. Eine negative Antwort mit einer ausgebliebenen Antwort verwechseln. DNS-Caches vor der Dokumentation löschen. Den DNS-Servercache routinemäßig leeren. Forwarder ändern, ohne die ursprüngliche Konfiguration zu sichern. Nur einen autoritativen DNS-Server prüfen. Die Reverse-Delegation nicht untersuchen. Bei öffentlichen IP-Adressen selbst eine nicht delegierte Reverse-Zone veröffentlichen wollen. IPv4-Oktette falsch anordnen. IPv6-Blöcke statt einzelner Nibbles umkehren. RFC-2317-Delegationen bei kleineren IPv4-Netzen ignorieren. PTR-Zielnamen nicht wieder vorwärts auflösen. Mehrere PTR- oder A-Einträge ohne Kenntnis des Systemdesigns löschen. CNAME-Ziele nicht bis zum endgültigen A- oder AAAA-Eintrag verfolgen. Einen erfolgreichen SRV-Lookup mit einem erreichbaren Dienst gleichsetzen. Große DNS-Antworten und Fragmentierung nicht berücksichtigen. DNSSEC bei SERVFAIL nicht prüfen. DoH und DNSSEC gleichsetzen. Dynamische Registrierung wiederholt auslösen, ohne Berechtigungen zu prüfen. Scavenging spontan aktivieren. Veraltete statische Einträge mit dynamischen Einträgen gleichsetzen. AD-Replikationsprobleme durch manuelle Datensatzänderungen verdecken. Analytische DNS-Protokollierung unbegrenzt eingeschaltet lassen. DNS-Protokolle mit internen Namen ungeschützt weitergeben. Nach der Änderung nur den Cache und nicht den vollständigen DNS-Pfad testen. 7.11.46 Checkliste betroffenes System und Anwendung dokumentiert genauer Fehlerzeitpunkt erfasst Vorwärts- oder Rückwärtsauflösung bestimmt Umfang der Störung bestimmt verwendete Netzwerkschnittstelle geprüft VPN-Zustand dokumentiert konfigurierte DNS-Server erfasst DNS-Suffixe und Suchliste geprüft Hosts-Datei berücksichtigt NRPT geprüft Split-DNS berücksichtigt DoH, DoT und Anwendungscache berücksichtigt betroffener Name oder IP-Adresse dokumentiert Abfragetyp bestimmt DNS-Server bei Test ausdrücklich angegeben vollständige Antwort dokumentiert Antwortcode ausgewertet Timeout von DNS-Fehlercode unterschieden erste Antwortzeit gemessen wiederholte Antwortzeit gemessen positiver Cache geprüft negativer Cache geprüft TTL dokumentiert Vorwärtsauflösung getestet IPv4-Rückwärtsauflösung getestet IPv6-Rückwärtsauflösung bei Bedarf getestet PTR-Zielname dokumentiert PTR-Zielname vorwärts aufgelöst Vorwärts-Rückwärts-Konsistenz geprüft CNAME-Kette bei Bedarf geprüft SRV-Ziel und Dienstport bei Bedarf geprüft primärer DNS-Server getestet alternativer DNS-Server getestet autoritativer DNS-Server bestimmt direkte autoritative Abfrage durchgeführt Reverse-Delegation geprüft RFC-2317-Konfiguration bei Teilnetzen berücksichtigt öffentliche oder private IP-Adresse unterschieden UDP-DNS getestet TCP-DNS getestet größere DNS-Antwort getestet EDNS und MTU berücksichtigt DNSSEC bei SERVFAIL berücksichtigt verschlüsselter DNS-Pfad bei Bedarf getestet Forwarder geprüft bedingte Forwarder geprüft Rekursion geprüft DNS-Serverdienst geprüft Reverse-Zone auf dem Server geprüft PTR-Datensatz direkt geprüft Zeitstempel und statischer Zustand geprüft Serverstatistiken ausgewertet Abfragerate und Serverlast korreliert DNS-Ereignisse ausgewertet dynamische Aktualisierung geprüft DHCP-Aktualisierung geprüft Berechtigungen und Datensatzeigentümer geprüft Aging und Scavenging geprüft AD-Replikation bei unterschiedlichen Antworten geprüft Hypothese und Gegenbeweis formuliert Risiko und Rückweg dokumentiert nur eine kontrollierte Maßnahme durchgeführt Antwortcode nach der Maßnahme geprüft Antwortzeit nach der Maßnahme geprüft vollständiger DNS-Pfad verifiziert Anwendung erneut getestet temporäre Diagnoseänderungen zurückgenommen Ursache und Präventionsmaßnahme dokumentiert 7.11.47 Schnellreferenz Aufgabe Befehl Windows-Netzwerk- und DNS-Konfiguration ipconfig /all Windows-DNS-Serveradressen Get-DnsClientServerAddress Windows-DNS-Clientzustand Get-DnsClient Linux-Resolverzustand resolvectl status macOS-Resolverzustand scutil --dns wirksame NRPT-Richtlinie Get-DnsClientNrptPolicy konfigurierte NRPT-Regeln Get-DnsClientNrptRule DoH-/DoT-Clientzustand netsh dnsclient show state verschlüsselte DNS-Server netsh dnsclient show encryption Vorwärtsauflösung IPv4 Resolve-DnsName -Type A -Server -DnsOnly Vorwärtsauflösung IPv6 Resolve-DnsName -Type AAAA -Server -DnsOnly Rückwärtsauflösung Resolve-DnsName -Type PTR -Server -DnsOnly Rückwärtsauflösung mit dig dig @ -x CNAME prüfen Resolve-DnsName -Type CNAME -Server -DnsOnly SRV prüfen Resolve-DnsName -Type SRV -Server -DnsOnly TCP-DNS-Abfrage Resolve-DnsName -Server -TcpOnly -DnsOnly TCP-Port 53 prüfen Test-NetConnection -Port 53 DNSSEC-Daten anfordern Resolve-DnsName -Server -DnssecOk Clientcache anzeigen Get-DnsClientCache Clientcache löschen Clear-DnsClientCache DNS-Serverdienst Get-Service DNS DNS-Zonen Get-DnsServerZone PTR-Einträge Get-DnsServerResourceRecord -ZoneName -RRType PTR Forwarder Get-DnsServerForwarder Rekursion Get-DnsServerRecursion Cacheeinstellungen Get-DnsServerCache Serverstatistiken Get-DnsServerStatistics Leistungsindikatoren Get-Counter -ListSet DNS DoH-Serverkonfiguration Get-DnsServerEncryptionProtocol Clientregistrierung Register-DnsClient AD-DNS-Test dcdiag /test:DNS /v AD-Replikation repadmin /replsummary Ändernde Befehle, die nicht als erste Diagnose verwendet werden dürfen: Clear-DnsClientCache Clear-DnsServerCache Register-DnsClient ipconfig /flushdns ipconfig /registerdns Add-DnsServerPrimaryZone Add-DnsServerResourceRecordPtr Set-DnsServerForwarder Set-DnsServerRecursion Set-DnsServerCache Set-DnsServerZoneAging Start-DnsServerScavenging Set-DnsServerEncryptionProtocol Remove-DnsServerResourceRecord 7.11.48 Quellen Offizielle Microsoft-Dokumentation Microsoft Learn – Guidance for troubleshooting DNS Microsoft Learn – Troubleshoot DNS servers Microsoft Learn – Troubleshoot DNS client name resolution issues Microsoft Learn – DNS queries and lookups Microsoft Learn – DNS architecture Microsoft Learn – Manage DNS zones Microsoft Learn – Manage DNS resource records Microsoft Learn – Dynamic DNS Update in Windows and Windows Server Microsoft Learn – DNS scavenging setup Microsoft Learn – Troubleshoot DNS scavenging issues Microsoft Learn – Forwarders and conditional forwarders resolution timeouts Microsoft Learn – Enable DNS logging and diagnostics Microsoft Learn – DNS encryption using DNS over HTTPS Microsoft Learn – Enable DNS over HTTPS in DNS Server Microsoft Learn – Troubleshoot DNS over HTTPS in DNS Server Microsoft Learn – Secure DNS Client over HTTPS Microsoft Learn – netsh dnsclient Microsoft Learn – Resolve-DnsName Microsoft Learn – DnsClient PowerShell module Microsoft Learn – Clear-DnsClientCache Microsoft Learn – Register-DnsClient Microsoft Learn – Get-DnsServerZone Microsoft Learn – Get-DnsServerResourceRecord Microsoft Learn – Add-DnsServerPrimaryZone Microsoft Learn – Add-DnsServerResourceRecordPtr Microsoft Learn – Get-DnsServerStatistics Microsoft Learn – Get-DnsServerCache Microsoft Learn – Clear-DnsServerCache Microsoft Learn – Set-DnsServerEncryptionProtocol Microsoft Learn – DnsServer PowerShell module Microsoft Learn – Verify that SRV DNS records have been created Microsoft Learn – Dcdiag Microsoft Learn – Diagnose Active Directory replication failures Standards RFC 1034 – Domain Names: Concepts and Facilities RFC 1035 – Domain Names: Implementation and Specification RFC 2308 – Negative Caching of DNS Queries RFC 2317 – Classless IN-ADDR.ARPA Delegation RFC 3596 – DNS Extensions to Support IPv6 RFC 7858 – Specification for DNS over Transport Layer Security RFC 8484 – DNS Queries over HTTPS RFC 8499 – DNS Terminology Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.