Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Von Bedeutung
DNS over HTTPS (DoH) für DNS Server unter Windows Server befindet sich derzeit in der VORSCHAU. Diese Informationen beziehen sich auf eine Vorabversion des Produkts, an der vor der Veröffentlichung noch wesentliche Änderungen vorgenommen werden können. Microsoft übernimmt keine Gewährleistungen, ausgedrückt oder impliziert, in Bezug auf die hier bereitgestellten Informationen.
Können Ihre Clients keine Verbindung mit Ihrem DNS-Server mit DoH herstellen, oder schlagen verschlüsselte DNS-Abfragen ohne klaren Grund fehl? Dieser Artikel hilft Ihnen, allgemeine DNS-über HTTPS-Probleme (DoH) auf Windows DNS Server zu identifizieren und zu beheben. Unabhängig davon, ob Sie mit Zertifikatbindungsfehlern, Portkonflikten oder Leistungsproblemen zu tun haben, finden Sie schrittweise Anleitungen zum ordnungsgemäßen Funktionieren von DoH.
Beginnen Sie mit der Prüfliste zur Problembehandlung, um Ihr Problem schnell zu ermitteln, und folgen Sie dann den symptomspezifischen Abschnitten für detaillierte Lösungsschritte. Dieser Artikel bezieht sich auf Windows Server 2025 und höhere Versionen mit aktivierter DoH-Vorschaufunktion.
Voraussetzungen
Bevor Sie DoH-Probleme beheben, stellen Sie sicher, dass Sie folgendes haben:
Windows Server 2025 mit dem Sicherheitsupdate 2026-02 (KB5075899)) oder höher installiert.
Die Aktivierung von DNS über HTTPS im DNS-Serverdienst erfolgt anhand der Anweisungen, die nach Anforderung des Zugangs über DoH auf Windows DNS Server: Public Preview Registration bereitgestellt werden.
Administrativer oder gleichwertiger Zugriff auf den Windows Server, auf dem der DNS-Serverdienst gehostet wird.
DoH-Zertifikate müssen die folgenden Anforderungen erfüllen:
Erweiterte Schlüsselverwendungs-Erweiterung: Muss den Objektbezeichner für die Serverauthentifizierung (1.3.6.1.5.5.7.3.1) enthalten.
Alternativer Antragsteller- oder Antragstellername: Ein signiertes Zertifikat mit einem alternativen Antragstellernamen (Subject Alternative Name, SAN) mit dem vollqualifizierten Domänennamen oder der IP-Adresse, das Ihrer konfigurierten DoH-URI-Vorlage entspricht
Privater Schlüssel: Muss im Speicher des lokalen Computers vorhanden sein, ordnungsgemäß mit dem Zertifikat verknüpft und darf keinen starken Schutz vor privatem Schlüssel aktiviert haben.
Vertrauenskette: Muss von einer Zertifizierungsstelle ausgestellt werden, der die DNS-Clients vertrauen
Checkliste zur Problembehandlung
Führen Sie diese Checkliste durch, um Ihr DoH-Problem zu identifizieren. Jede Überprüfung enthält Links zu detaillierten Lösungsschritten.
1. Überprüfen des DoH-Status
✅ DoH ist aktiviert: Get-DnsServerEncryptionProtocol zeigt EnableDoh : True
✅ DER DNS-Dienst wird ausgeführt: Get-Service DNS zeigt Running
✅ Konfigurierter Port hört: netstat -an | findstr :<port> zeigt LISTENING an. Der Standardport ist 443.
Informationen zum Beheben von Dienstkonfigurationsproblemen finden Sie unter Symptom: DoH nicht konfiguriert oder ausgeführt.
2. Überprüfen der DoH-Initialisierung
✅ Ereignis-ID 822 wird im DNS Server-Ereignisprotokoll nach dem Neustart des Diensts angezeigt
✅ Keine Fehlerereignisse (823, 824, 825, 826) im Ereignisprotokoll
✅ Das Zertifikat ist an Ihren konfigurierten Port gebunden: netsh http show sslcert
Informationen zum Beheben von Initialisierungsfehlern finden Sie unter Symptom: DoH kann nicht initialisiert werden.
3. Überprüfen der Clientkonnektivität
✅ Clients können den DNS-Server auf dem konfigurierten DoH-Port erreichen (Test mit einem Browser), standardmäßig 443
✅ Die Firewall erlaubt eingehenden TCP-Datenverkehr auf dem konfigurierten DoH-Port
✅ Clients vertrauen dem Serverzertifikat (keine Zertifikatwarnungen)
Informationen zum Beheben von Konnektivitätsproblemen finden Sie unter Symptom: Clients können keine Verbindung mit DoH herstellen.
4. Überprüfen der Abfrageverarbeitung
✅ Die Ereignis-ID 597 (empfangene Abfragen) wird im Analytischen Protokoll angezeigt.
✅ Ereignis-ID 598 (gesendete Antworten) wird im Analytischen Protokoll angezeigt
✅ Keine Ereignis-ID 599 (Antwortfehler) oder Ereignis-ID 600 (Abfragen abgelehnt)
Informationen zum Beheben von Abfrageverarbeitungsproblemen finden Sie unter Symptom: DoH-Abfragen schlagen fehl oder timeout.
Tipp
Wenn die Ereignis-ID 597 nicht angezeigt wird, beheben Sie zuerst die Clientkonnektivität. Siehe Symptom: Clients können keine Verbindung mit DoH herstellen.
5. Überprüfen der Leistung
✅ DoH-Anforderungen verworfen/sek. Zähler = 0
✅ Gesendete DoH-Antworten ≈ Empfangene DoH-Anforderungen/Sek.
✅ Die Latenz der Abfrage ist akzeptabel.
Informationen zum Beheben von Leistungsproblemen finden Sie unter Symptom: DoH-Leistungsprobleme.
Symptom: DoH nicht konfiguriert oder aktiviert
Sie versuchen, DoH zu verwenden, aber Clients verwenden weiterhin unverschlüsseltes DNS, oder Sie können nicht überprüfen, ob DoH auf dem Server aktiviert ist.
Häufige Ursachen:
DoH nicht auf dem Server aktiviert
DNS-Dienst wurde beendet.
Konfigurationsfehler in den DoH-Einstellungen
Hinweise zur Diagnose:
Führen Sie den folgenden Befehl aus, um die DoH-Konfiguration zu überprüfen:
Get-DnsServerEncryptionProtocol
Wenn DoH ordnungsgemäß konfiguriert ist, sollten Sie Folgendes sehen:
EnableDoh : True
UriTemplate : https://dns.contoso.com:443/dns-query
Führen Sie den folgenden Befehl aus, um den DNS-Dienststatus zu überprüfen:
Get-Service DNS
Die Ausgabe sollte anzeigen Status: Running.
Führen Sie den folgenden Befehl aus, um zu überprüfen, ob der konfigurierte Port aktiv ist. Ersetzen Sie 443 mit Ihrem konfigurierten Port, falls dieser abweicht:
netstat -an | findstr :443
Tcp-Einträge sollten im LISTENING Status angezeigt werden.
Ausführliche Überwachungsverfahren finden Sie unter Überwachen von DNS über HTTPS.
Lösung:
Wenn EnableDohFalse ist, führen Sie den folgenden Befehl aus, um DoH zu aktivieren:
Set-DnsServerEncryptionProtocol -EnableDoh $true -UriTemplate "https://dns.contoso.com:443/dns-query"
Ersetzen Sie dns.contoso.com durch den FQDN Ihres DNS-Servers, der seinem Zertifikats-SAN entspricht.
Führen Sie den folgenden Befehl aus, um den DNS-Serverdienst neu zu starten:
Restart-Service -Name DNS
Wenn DoH noch nicht konfiguriert wurde, lesen Sie die Aktivierung von DNS über HTTPS auf Windows DNS Server , um vollständige Einrichtungsanweisungen einschließlich Zertifikatanforderungen zu erhalten.
Symptom: DoH kann nicht initialisiert werden
Sie aktivieren DoH, aber der Dienst initialisiert nicht ordnungsgemäß. Clients können keine Verbindung mit DoH herstellen.
Häufige Ursachen:
Probleme bei der Zertifikatbindung (Ereignis-ID 823).
Portkonflikte (Ereignis-ID 825, 826).
Ungültige URI-Vorlagenkonfiguration.
Hinweise zur Diagnose:
Überprüfen Sie die Windows-Ereignisanzeige auf DNS-Serverereignisse. Wechseln Sie zu "Anwendungen und Dienste>DNS Server".
Vollständige Ereignisdetails finden Sie unter Überwachen von DNS über HTTPS – Serverereignisse.
Überprüfen Sie diese spezifischen Ereignisse.
Ereignis-ID 823 (DNS_EVENT_HTTP_SERVER_INIT_FAILED): Fehler bei der HTTP-Serverinitialisierung, in der Regel aufgrund von Zertifikatbindungsproblemen oder Portkonflikten.
Ereignis-ID 824 (DNS_EVENT_HTTP_SERVER_SESSION_FAILED): Fehler bei der Erstellung von HTTP-Serversitzungen, in der Regel aufgrund von Ressourceneinschränkungen.
Ereignis-ID 825 (DNS_EVENT_HTTP_CREATE_URL_FAILED): Fehler bei der URL-Registrierung aufgrund ungültiger URI-Format- oder Portkonflikte.
Suchen Sie nach der Ereignis-ID 822 (DNS_EVENT_HTTP_URL_REGISTERED), die eine erfolgreiche Initialisierung angibt. Wenn dieses Ereignis nach dem Neustart des Diensts fehlt, ist die Initialisierung fehlgeschlagen.
Lösung:
Probleme bei der Zertifikatbindung
Wenn die Ereignis-ID 823 angezeigt wird, führen Sie den folgenden Befehl aus, um die Zertifikatbindung zu überprüfen:
netsh http show sslcert
Suchen Sie nach einem Eintrag, der Ihrer IP-Adresse und Ihrem Port entspricht (z. B 0.0.0.0:443. ). Bestätigen Sie, dass der Fingerabdruck des DNS-Serverzertifikats angezeigt wird.
Wenn das Zertifikat nicht gebunden ist oder einen falschen Fingerabdruck anzeigt, lesen Sie "Binden des Zertifikats für Schritte zum Binden des richtigen Zertifikats".
Stellen Sie sicher, dass das Zertifikat diese Anforderungen erfüllt:
Gültiges SSL/TLS-Zertifikat im
LocalMachine\My storeSubject Alternative Name (SAN) stimmt mit dem FQDN in Ihrer DoH-URI überein.
Privater Schlüssel ist installiert.
Nicht abgelaufen
Ausführliche Informationen zum Einrichten von Zertifikaten finden Sie unter Aktivieren von DNS über HTTPS auf Windows DNS Server.
Portkonflikte
Wenn die Ereignis-ID 825 oder 826 angezeigt wird, verwendet ein anderer Dienst möglicherweise Port 443. Führen Sie den folgenden Befehl aus, um zu überprüfen, was der Port verwendet:
netstat -ano | findstr :443
Wenn ein anderer Prozess Port 443 verwendet, führen Sie eine der folgenden Aktionen aus:
- Beenden des in Konflikt stehenden Diensts oder
- Führen Sie den folgenden Befehl aus, um DoH für die Verwendung eines anderen Ports zu konfigurieren:
Set-DnsServerEncryptionProtocol -EnableDoh $true -UriTemplate "https://dns.contoso.com:8443/dns-query"
Binden Sie dann Ihr Zertifikat an den neuen Port, und aktualisieren Sie Firewallregeln entsprechend.
Konfigurationsfehler
Überprüfen Sie, ob Die URI-Vorlage ordnungsgemäß formatiert ist:
Beginnt mit
https://Enthält den FQDN, der Ihrem Zertifikats-SAN entspricht.
Enthält den Pfad
/dns-queryBeispiel:
https://dns.contoso.com:443/dns-query
Führen Sie den folgenden Befehl aus, um die aktuelle Konfiguration der URI-Vorlagen zu überprüfen:
Get-DnsServerEncryptionProtocol | Select-Object UriTemplate
Wenn die URI-Vorlage falsch oder fehlt, führen Sie den folgenden Befehl aus, um sie neu zu konfigurieren:
Set-DnsServerEncryptionProtocol -EnableDoh $true -UriTemplate "https://dns.contoso.com:443/dns-query"
Ersetzen Sie dns.contoso.com durch den FQDN Ihres DNS-Servers. Stellen Sie sicher, dass der FQDN genau dem Subject Alternative Name (SAN) in Ihrem Zertifikat entspricht.
Führen Sie nach dem Beheben von Problemen den folgenden Befehl aus, um den DNS-Dienst neu zu starten. Überprüfen Sie, ob die Ereignis-ID 822 erfolgreich initialisiert wurde.
Restart-Service -Name DNS
Symptom: Clients können keine Verbindung mit DoH herstellen
Sie konfigurieren und starten DoH auf dem Server, clients können jedoch keine Verbindung herstellen oder erhalten Zertifikatfehler.
Häufige Ursachen:
Netzwerk oder Firewall blockieren den konfigurierten DoH-Port, der standardmäßig 443 ist.
Probleme mit der Zertifikatsvertrauenswürdigkeit.
Client, der falsche URI oder Konfiguration verwendet.
Hinweise zur Diagnose:
Testen Sie die Konnektivität von einem Clientcomputer, indem Sie einen Webbrowser öffnen und zu Ihrem DoH-URI wechseln (z.B. https://dns.contoso.com/dns-query). Sie sollten eines der folgenden Ergebnisse sehen:
Eine leere Seite oder eine minimale Antwort zeigt an, dass der Server auf Anfragen hört und die Netzwerkkonnektivität funktioniert.
Ein Zertifikatfehler weist auf Probleme mit der Zertifikatvertrauensstellung hin, bestätigt jedoch, dass Netzwerkkonnektivität und Firewallregeln korrekt sind.
Ein Verbindungstimeout gibt Netzwerk- oder Firewallprobleme an, die den Zugriff auf den DNS-Server mithilfe von DoH verhindern.
Führen Sie den folgenden Befehl aus, um Firewallregeln auf dem DNS-Server zu überprüfen:
Get-NetFirewallRule | Where-Object {$_.DisplayName -like "*DNS*" -or $_.DisplayName -like "*443*"} | Format-Table DisplayName, Enabled, Direction, Action
Überprüfen Sie die Clientzertifikatvertrauensstellung, indem Sie die Zertifikatdetails im Browser überprüfen. Überprüfen Sie, ob die Zertifikatkette gültig und vertrauenswürdig ist.
Lösung:
Netzwerkkonnektivität
Überprüfen Sie zunächst die Netzwerkkonnektivität vom Client zum DNS-Server über HTTPS. Führen Sie den folgenden Befehl aus, und ersetzen Sie den Port, wenn Sie einen nicht standardmäßigen Port konfiguriert haben:
Test-NetConnection -ComputerName dns.contoso.com -Port 443
Wenn TcpTestSucceededFalse zurückliefert, überprüfen Sie die Netzwerk-Routing- und Firewall-Regeln zwischen Client und Server.
Führen Sie den folgenden Befehl aus, um eine neue Windows-Firewallregel auf dem Server zu erstellen, um eingehende Verbindungen zuzulassen. Ersetzen Sie 443 mit Ihrem konfigurierten Port, falls dieser abweicht:
New-NetFirewallRule -DisplayName "DNS over HTTPS" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow
Wenn Sie eine Hardwarefirewall oder eine Netzwerksicherheitsgruppe verwenden, stellen Sie sicher, dass eingehender TCP-Datenverkehr über Ihren konfigurierten DoH-Port zum DNS-Server zugelassen wird.
Zertifikatsvertrauen
Wenn Sie eine private Zertifizierungsstelle (CA) verwenden:
Stellen Sie sicher, dass Ihre DNS-Clients dieser Zertifizierungsstelle vertrauen.
Installieren Sie das Stammzertifizierungsstellenzertifikat auf Clientcomputern.
Überprüfen Sie, ob die Zertifikatkette auf dem Server abgeschlossen ist.
Alternativ können Sie ein Zertifikat verwenden, das von einer öffentlich vertrauenswürdigen Zertifizierungsstelle signiert ist, die Clients bereits vertrauen.
Führen Sie den folgenden Befehl aus, um die Netzwerkkonnektivität mit dem DoH-Port des DNS-Servers von einem Client zu testen. Ersetzen Sie 443 mit Ihrem konfigurierten Port, falls dieser abweicht:
Test-NetConnection -ComputerName dns.contoso.com -Port 443
Um zu überprüfen, ob das Zertifikat vom Client als vertrauenswürdig eingestuft wird, öffnen Sie einen Webbrowser, und wechseln Sie zu https://dns.contoso.com/dns-query. Wenn im Browser eine Zertifikatwarnung angezeigt wird, vertraut der Client der Zertifikatkette nicht.
Anleitungen zur Zertifikatbereitstellung finden Sie unter Aktivieren von DNS über HTTPS auf Windows DNS Server.
Clientkonfiguration
Überprüfen Sie, ob die DoH-Konfiguration des Clients exakt mit dem URI Ihres Servers übereinstimmt:
Windows 11: Einstellungen > für Netzwerk und Internet > [Verbindung] > DNS-Einstellungen
Die DoH-Vorlage muss übereinstimmen:
https://dns.contoso.com:443/dns-queryWenn Sie einen nicht standardmäßigen Port verwenden, stellen Sie sicher, dass Clients sie angeben.
Wenn Sie Clients konfigurieren, aber weiterhin unverschlüsseltes DNS verwenden, überprüfen Sie, ob die DNS-Server-IP-Adresse in den Clientnetzwerkeinstellungen Ihrem DNS-Server entspricht, wobei DoH aktiviert ist.
Symptom: DoH-Abfragen schlagen fehl oder timeout
Clients stellen eine Verbindung mit dem DNS-Server her, abfragen schlagen jedoch fehl oder empfangen keine Antworten.
Häufige Ursachen:
Probleme bei der Upstream-DNS-Auflösung (Ereignis-ID 599)
Clientprotokollinkompatibilität (Ereignis-ID 600)
Client-DoH-Konfigurationsprobleme
DNS-Serverkonfigurationsprobleme
Hinweise zur Diagnose:
Aktivieren Sie die analytische Protokollierung, um detaillierte Ereignisse pro Abfrage zu erfassen:
Öffnen Sie die Ereignisanzeige, und wechseln Sie zu Den Anwendungs- und Dienstprotokollen>von Microsoft>Windows>DNS-Server.
Klicken Sie mit der rechten Maustaste auf "Analyse" , und wählen Sie "Protokoll aktivieren" aus.
Ausführliche Analyseprotokollierungsverfahren finden Sie unter Überwachen von DNS über HTTPS – Analytische Ereignisse.
Überprüfen Sie die folgenden wichtigen Ereignisse:
Ereignis-ID 597: Empfangene DoH-Abfrage – bestätigt, dass verschlüsselte DNS-Abfragen den Server erreichen
Ereignis-ID 598: Gesendete DoH-Antwort – bestätigt erfolgreiche Antworten
Ereignis-ID 599: DoH-Antwortfehler – gibt an, dass der Server versucht hat, die Antwort zu beantworten, aber nicht möglich (wahrscheinliches Problem bei der Upstreamauflösung)
Ereignis-ID 600: DoH-Abfrage abgelehnt – Server legt bestimmte DoH-Anforderungen aktiv ab
Ereignis-ID 601: DoH-Kanalfehler – kann in einigen Fehlerfällen 600 oder 599 begleiten
Suchen Sie nach Mustern:
Mehrere Ereignis-ID 597-Einträge, aber keine Ereignis-ID 598-Einträge deuten darauf hin, dass der Server Abfragen nicht auflösen kann.
Ereignis-ID 600-Einträge geben möglicherweise http-Versionsinkompatibilität oder falsch formatierte Anforderungen an.
Ereignis-ID 599 mit
SERVFAIL RCODEweist auf Probleme mit vorgelagerten Weiterleitungen hin.
Lösung:
Upstream-DNS-Probleme (Ereignis-ID 599)
Wenn ereignis-ID 599 mit SERVFAIL oder ähnlichen Fehlern angezeigt wird, überprüfen Sie die Upstream-DNS-Konfiguration auf dem DNS-Server. Führen Sie den folgenden Befehl aus:
Get-DnsServerForwarder
Führen Sie den folgenden Befehl aus, um die Verbindung zu Forwardern zu testen.
Test-NetConnection -ComputerName <forwarder-ip> -Port 53
Wenn Weiterleitungen nicht erreichbar oder falsch konfiguriert sind, probieren Sie alternative Weiterleitungen mit dem folgenden Befehl aus:
Set-DnsServerForwarder -IPAddress <new-forwarder-ip>
Führen Sie den folgenden Befehl aus, um die Auflösung manuell zu testen:
Resolve-DnsName -Name microsoft.com -Server localhost
Informationen zur herkömmlichen DNS-Problembehandlung finden Sie unter Problembehandlung für DNS-Server.
Abfrageverweigerung (Ereignis-ID 600)
Ereignis-ID 600 gibt abgelehnte Abfragen an. Häufige Ursachen sind:
HTTP-Anforderungsinkompatibilität: Der DNS-Server lehnt die Anforderung aufgrund nicht unterstützter oder ungültiger HTTP-Anforderungsmerkmale ab.
Falsch formatierte Anforderungen: Die Abfrage entspricht nicht RFC 8484.
DNS-Richtlinieneinschränkungen: Eine DNS-Richtlinie kann Abfragen ablegen.
Serverseitige Anforderungen sind nicht erfüllt: DoH ist nicht auf der empfangenden Schnittstelle aktiviert, oder es gibt ein URI-Vorlagen-Mismatch oder eine serverseitige Überprüfung, Konfiguration oder Richtlinienüberprüfung.
Überprüfen Sie die Ereignisdetails für den Ablehnungsgrund. Wenn Clients inkompatible HTTP-Versionen verwenden, aktualisieren Sie die Clientsoftware, oder verwenden Sie andere DoH-Clientanwendungen.
Führen Sie den folgenden Befehl aus, um zu überprüfen, ob keine DNS-Richtlinien stören:
Get-DnsServerQueryResolutionPolicy
Client-DoH-Konfiguration
Wenn Abfragen von bestimmten Clients fehlschlagen, aber von anderen funktionieren, überprüfen Sie die DoH-Konfiguration des Clients. Häufige Probleme sind beispielweise:
- Falsche DoH-URI-Vorlage
- DNS-Server-IP-Adresse, die nicht mit dem für DoH verwendeten DNS-Server übereinstimmen
- Client nicht für die Verwendung von DoH konfiguriert
Anleitungen zur Clientkonfiguration finden Sie unter Secure DNS Client over HTTPS (DoH).For client configuration guidance, see Secure DNS Client over HTTPS (DoH).
Serverkonfiguration
Wenn Abfragen aus anderen Gründen als denen, die weiter oben in diesem Artikel aufgeführt sind, fehlschlagen, überprüfen Sie die allgemeine DNS-Serverkonfiguration:
Stellen Sie sicher, dass Root-Hinweise ordnungsgemäß konfiguriert sind.
Überprüfen Sie das Laden von Zonen für autoritative Zonen.
Überprüfen Sie die Rekursionseinstellungen, wenn der Server rekursive Auflösungen ausführen soll.
Umfassende DNS-Problembehandlung finden Sie unter Problembehandlung für DNS-Server.
Um übermäßige Ereignisgenerierung zu vermeiden, deaktivieren Sie das Analytische Protokoll, wenn die Problembehandlung abgeschlossen ist.
Symptom: DoH-Leistungsprobleme
DoH funktioniert, sie sehen jedoch eine hohe Latenz, verworfene Abfragen oder eine schlechte Leistung im Vergleich zu unverschlüsselten DNS.
Häufige Ursachen:
Serverkapazitätsbeschränkungen
Overhead beim TLS-Handshake
Netzwerküberlastung oder hohe CPU-Auslastung
Hinweise zur Diagnose:
Aktivieren Sie die Überwachung für die folgenden Leistungsindikatoren mithilfe von Monitor DNS over HTTPS – Überwachen der Leistung:
- Empfangene DoH-Anforderungen/sek.
- Gesendete DoH-Antworten/Sek.
- DoH-Anforderungen verworfen/sek.
Wichtige Indikatoren für Leistungsprobleme:
DoH-Anforderungen verworfen/sek > 0: Der Server verwirft Abfragen.
Empfangene Anforderungen pro Sekunde viel höher als gesendete Antworten pro Sekunde: Viele Anfragen erhalten keine Antworten.
Hohe oder spontan ansteigende CPU-Auslastung während der DoH-Abfrageverarbeitung.
Überwachen Sie auch Systemressourcen:
CPU-Auslastung
Speicherauslastung
Netzwerkdurchsatz
Wenn nur bestimmte Abfragen langsam sind, liegt das Problem möglicherweise außerhalb von DoH. Langsame Rekursion zu Upstream-Servern für spezifische Domains. Um doH-Overhead von allgemeinen DNS-Verzögerungen zu isolieren, vergleichen Sie DoH und unverschlüsselte DNS-Leistung für dieselben Abfragen. Wenn beide langsam sind, liegt das Problem wahrscheinlich an der upstream-Auflösung, als dass es DoH-spezifisch ist.
Lösung:
Verworfene Abfragen
Wenn DoH Requests Dropped/sec größer als 0 ist, führen Sie die folgenden Schritte aus:
Korrelieren Sie die Ereignis-ID 600 in DNS-Server-Protokollen, um die Ursache von Ausfällen zu identifizieren.
Überprüfen Sie, ob der Server ressourcengeschränkt ist.
Get-Counter '\Processor(_Total)\% Processor Time' Get-Counter '\Memory\Available MBytes'Wenn CPU oder Arbeitsspeicher konsistent hoch ist, sollten Sie Folgendes in Betracht ziehen:
- Skalieren des Servers mit mehr CPU- oder RAM-Ressourcen
- Hinzufügen zusätzlicher DNS-Server zum Verteilen der Last.
- Implementieren des DNS-Lastenausgleichs.
Hohe Latenz
Die Latenz der Abfrage kann durch den TLS-Handshake-Overhead im Vergleich zu unverschlüsseltem DNS erhöht werden. So diagnostizieren Sie Latenzprobleme:
Vergleich der DoH-Abfragezeiten mit unverschlüsselten DNS-Baselines für dieselben Abfragen.
Verwenden Sie clientseitige Tools, um die End-to-End-DoH-Abfragezeit zu messen.
Wenn sowohl DoH als auch unverschlüsseltes DNS für dieselben Abfragen langsam sind, liegt das Problem an der Upstream-Auflösung und nicht DoH-spezifisch.
So verringern Sie die doH-spezifische Latenz:
Überprüfen Sie die Server-CPU-Kapazität: TLS-Vorgänge sind CPU-intensiv. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die CPU während des DoH-Datenverkehrs ein Engpass ist:
Get-Counter '\Processor(_Total)\% Processor Time' -SampleInterval 1 -MaxSamples 30Wenn die CPU konsistent 70-80% während des DoH-Datenverkehrs überschreitet, sollten Sie Serverressourcen aktualisieren oder die Last verteilen.
Überprüfen Sie die Länge der Zertifikatkette: Kürzere Zertifikatketten werden schneller überprüft. Stellen Sie sicher, dass Zwischenzertifikate ordnungsgemäß konfiguriert sind, um zusätzliche Nachschlagevorgänge zu vermeiden.
Überprüfen Sie Netzwerkpfade: Hohe Netzwerklatenz zwischen Clients und dem DNS-Server wirkt sich direkt auf die Abfragezeit aus. Verwenden
Test-NetConnectionOdertracerouteum Netzwerkengpässe zu finden.
Ressourceneinschränkungen
Wenn der Server nicht bereitgestellt wird:
Überwachen der Basisressourcenauslastung während normaler Vorgänge.
Identifizieren Sie Spitzenauslastungszeiten, und korrelieren Sie sie mit dem Abfragevolumen.
Erwägen:
- Vertikale Skalierung (größere VM oder physischer Server).
- Horizontale Skalierung (mehrere DNS-Server hinter einem Lastenausgleich).
- Optimieren von DNS-Zonenkonfigurationen zur Verringerung des Zonenübertragungsaufwands.
Führen Sie den folgenden Befehl aus, um langfristige Trends zu überwachen und die Kapazität zu planen:
Get-Counter '\DNS-over-HTTPS\DoH Requests Received/sec' -Continuous
Anleitungen zur Kapazitätsplanung finden Sie unter Überwachen von DNS über HTTPS – Überwachen der Leistung.
Erweiterte Diagnose
Wenn die grundlegende Problembehandlung das Problem nicht behebt, verwenden Sie diese erweiterten Techniken, um detaillierte Diagnoseinformationen zu sammeln.
Aktivieren der analytischen Protokollierung
Das analytische Protokoll des DNS-Servers erfasst detaillierte Ereignisse pro Abfrage, einschließlich DoH-spezifischer Vorgänge. Wenn Sie das Protokoll aktivieren, zeichnet es Ereignis-IDs 597-600 für jede DoH-Abfrage, Antwort, Fehler und Ablehnung auf.
Schrittweise Anleitungen zum Aktivieren und Verwenden der analytischen Protokollierung finden Sie unter Überwachen von DNS über HTTPS – Analytische Ereignisse.
Von Bedeutung
Deaktivieren Sie die analytische Protokollierung nach Abschluss, da sie eine große Anzahl von Ereignissen auf ausgelasteten Servern generiert.
Detaillierte Ereignisanalyse
Wenn Sie DoH-Ereignisse überprüfen, untersuchen Sie diese Ereignisfelder auf Diagnosehinweise:
QNAME: Der abgefragte Domänenname. Dieses Feld hilft Ihnen zu ermitteln, ob Probleme domänenspezifisch sind.
QTYPE: Der DNS-Eintragstyp, z. B. AAAA, MX und andere.
RCODE: Der Antwortcode, z. B. NOERROR, SERVFAIL, NXDOMAIN und andere.
Grund: Für die Ereignis-ID 600 gibt dieses Feld den Ablehnungsgrund an.
Client-IP: Die Quelle der Abfrage. Dieses Feld hilft Ihnen, problematische Clients zu identifizieren.
Korrelieren von Ereignissen im Laufe der Zeit:
Suchen Sie nach Mustern. Treten Fehler zu bestimmten Zeiten auf?
Überprüfen Sie, ob mehrere Clients dasselbe Problem haben.
Ermitteln Sie, ob Fehler mit hohen Ladezeiten korrelieren.
Querverweis mit anderen Protokollen:
Systemprotokoll für Schannel TLS-Fehler.
DNS Server-Betriebsprotokoll für Zonen- und Weiterleitungsprobleme.
Anwendungsprotokoll für Fehler auf Dienstebene.
Leistungsanalyse
Für eine umfassende Leistungsanalyse:
Richten Sie die Basismetriken während normaler Vorgänge ein.
Vergleich der aktuellen Leistung mit der Basislinie.
Identifizieren Sie Abweichungen und korrelieren Sie mit Ereignissen oder Konfigurationsänderungen.
Leistungsindikatoren, die im Laufe der Zeit überwacht werden sollen:
Get-Counter -Counter @(
'\DNS-over-HTTPS\DoH Requests Received/sec',
'\DNS-over-HTTPS\DoH Responses Sent/sec',
'\DNS-over-HTTPS\DoH Requests Dropped/sec',
'\Processor(_Total)\% Processor Time',
'\Memory\Available MBytes'
) -SampleInterval 5 -MaxSamples 60
Mit diesem Befehl werden Zähler alle 5 Sekunden für 5 Minuten erfasst und trendbezogene Daten geliefert.
Trends analysieren:
Verschlechtert sich die Leistung im Laufe der Zeit?
Zeigen bestimmte Tageszeiten Probleme an?
Korreliert die Leistung mit dem Abfragevolume?
Verwenden Sie diese Daten für Folgendes:
Planen Sie Kapazitätserweiterungen.
Identifizieren von Konfigurationsengpässen.
Optimieren Sie die DNS-Servereinstellungen.
Umfassende Anleitungen zur Leistungsüberwachung finden Sie unter Überwachen von DNS über HTTPS.