DNS über HTTPS erklärt: Datenschutz vs. Filterung von öffentlichem WiFi
DNS über HTTPS verschlüsselt Abfragen innerhalb des Port 443 Datenverkehrs. Erfahren Sie, was verborgen wird, warum es die WiFi Filterung umgehen kann und wie Netzwerke die Kontrolle behalten.
Published 26. Oktober 2026
DNS over HTTPS übermittelt DNS-Abfragen innerhalb des normalen HTTPS-Verkehrs über Port 443, verschlüsselt zwischen dem Gerät und dem Resolver, und wurde 2018 zu einem IETF-Standard.
Sie haben die Inhaltsfilterung für Ihr Gäste-WiFi aktiviert, aber der Browser eines Gastes öffnet trotzdem eine Kategorie, die Sie eigentlich blockiert hatten. Die Firewall läuft, die Netzwerkeinstellungen sehen richtig aus und ein anderes Gerät erhält die erwartete Sperrseite. Der Unterschied liegt möglicherweise darin, welchen Resolver der Browser fragt, und nicht daran, ob Ihr Filter funktioniert.
Für Standortbetreiber und IT-Leiter ist das das zentrale Problem bei DoH. Es schützt eine Abfrage während der Übertragung, aber die Zielauswahl des Browsers kann diese Abfrage auch außerhalb der Filterrichtlinien Ihres Netzwerks verlagern.
Inhaltsverzeichnis
- Was DNS over HTTPS in einfachen Worten bedeutet
- Wie eine DoH-Abfrage vom Gerät zum Resolver gelangt
- Wer Ihre Abfragen sehen kann, wenn DoH aktiviert ist
- Warum DoH die DNS-Filterung in geteilten WiFi-Netzwerken schwächt
- Was DoH an Geschwindigkeit kostet und was Filterung weiterhin leistet
- DoH auf gängigen Geräten prüfen und ändern
- Wählen und staffeln Sie Ihre DoH-Steuerungsmechanismen
Was DNS over HTTPS in einfachen Worten bedeutet
DNS over HTTPS, meist als DoH abgekürzt, überträgt DNS-Anfragen und -Antworten über eine verschlüsselte Webverbindung. Ein DNS-Resolver ist der Dienst, den ein Gerät anfragt, um einen Domainnamen in eine Netzwerkadresse zu übersetzen.
Stellen Sie sich DNS wie ein Telefonbuch vor. Vor dem Aufbau einer Verbindung benötigt eine Anwendung eine Adresse, selbst wenn sie möglicherweise bereits eine nutzbare Antwort im Cache gespeichert hat. Herkömmliches DNS sendet diese Anfrage üblicherweise in lesbarer Form.
Eine Postkarte ist ein nützlicher Vergleich: Jeder, der sie in der Hand hält, kann die Nachricht lesen. DoH steckt die Anfrage in einen verschlossenen Umschlag und transportiert sie im selben Lieferwagen, der auch für den gewöhnlichen sicheren Webverkehr genutzt wird.
Vergleichen Sie den Transport, nicht nur die Verschlüsselung
DNS over TLS, oder DoT, versiegelt den Umschlag ebenfalls, nutzt jedoch einen separat gekennzeichneten Zustelleingang. Dadurch sind entsprechende Datenströme für einen Netzwerkbetreiber anhand des Ziel-Ports leichter zu identifizieren.
RFC 8484 der IETF, veröffentlicht im Oktober 2018, definiert den HTTPS-Austausch von DoH, typischerweise über Port 443, im Gegensatz zu herkömmlichem DNS über Port 53.
Herkömmliches DNS, DNS over TLS und DNS over HTTPS im Vergleich
| Funktion | Traditionelles DNS | DNS over TLS (DoT) | DNS over HTTPS (DoH) |
|---|---|---|---|
| Transport | UDP oder TCP | TLS | HTTPS |
| Üblicher Port | 53 | 853 | 443 |
| Für lokales Netzwerk lesbar | Ja | Nein | Nein |
| Leicht am Port zu erkennen | Ja | Ja | Nein, teilt sich Port 443 mit Web-Traffic |
| Leicht am Port zu blockieren | Ja | Ja | Nein, nicht selektiv über den Port allein |
| Definiert in | Ursprünglichen DNS-Spezifikationen | DNS over TLS-Spezifikation | RFC 8484 |
Das Blockieren eines dedizierten DNS-Ports ist einfach. Das Blockieren des Ports, der von sicheren Websites verwendet wird, würde auch den legitimen Webverkehr stoppen. Daher benötigt DoH selektivere Kontrollen.
Verschlüsselung entscheidet nicht darüber, was gefiltert wird. Ein Resolver kann eine eingehende DoH-Anfrage entschlüsseln, eine Inhalts- oder Sicherheitsrichtlinie anwenden und seine Antwort sicher zurückgeben. Die wichtigen Fragen sind, wer diesen Resolver betreibt und dessen Richtlinie er folgt.
Halten Sie diesen Vergleich bei der Überprüfung von Kontrollen griffbereit. Eine Regel, die herkömmliches DNS oder DoT verarbeitet, deckt DoH nicht automatisch ab.
Wie eine DoH-Abfrage vom Gerät zum Resolver gelangt
Ein Kurier benötigt eine Adresse, bevor er ein Paket zustellen kann. Ähnlich benötigt ein Browser eine Zieladresse, bevor er eine Verbindung zu einer Hotelbuchungsseite herstellen kann - es sei denn, er hat diese Antwort bereits im Cache gespeichert.
Dieses Diagramm verfolgt die Abfrage vom Browser zum Resolver und zurück.
Verfolgen Sie die Anfrage und die Antwort
Der Browser benötigt eine Adresse. Er prüft, ob er bereits eine verwendbare Antwort für die Buchungsseite hat. Ein Cache Treffer kann eine neue Abfrage vollständig vermeiden, sodass das lokale Netzwerk für diese Aktion keinen DNS Austausch sieht.
Er erstellt eine DNS Frage. Wenn eine neue Antwort benötigt wird, bereitet der Browser eine Anfrage vor, die den Domainnamen enthält. Zu diesem Zeitpunkt befindet sich die Frage noch im Gerät und wird nicht über das WiFi übertragen.
Er wählt den DoH Resolver aus. Der Browser bereitet eine HTTPS Anfrage für seinen konfigurierten Resolver vor. Das lokale Netzwerk kann die Zieladresse und die Verbindungs-Metadaten beobachten, aber es kann die Domain innerhalb der verschlüsselten DNS Nachricht nicht direkt lesen.
Er stellt eine sichere Verbindung her oder nutzt diese erneut. Bei Bedarf schließt das Gerät einen TLS Handshake ab, bevor es die geschützte Anfrage sendet. Bei einer dauerhaften HTTP Verbindung können nachfolgende Abfragen diese Verbindung wiederverwenden; das Netzwerk sieht verschlüsselten Datenverkehr, einschließlich Zeitstempel und Größe.
Der Resolver liefert die Antwort zurück. Der Resolver verarbeitet die Frage und fügt die DNS Antwort in eine verschlüsselte HTTP Antwort ein. Das Netzwerk kann den Datenverkehr sehen, der vom Resolver zurückkommt, nicht aber den lesbaren Inhalt der Antwort.
Der Browser verbindet sich mit der Website. Er verwendet die zurückgegebene Adresse, um die Website-Verbindung zu starten. Das lokale Netzwerk kann dieses neue Ziel beobachten, was unabhängig vom Lesen der vorherigen DNS Frage erfolgt.
Weitere Details zu Caching und Auflösung finden Sie in der Erklärung was ein DNS-Lookup macht, die den Prozess der Adressfindung von der eigentlichen Website-Verbindung trennt.
Identifizieren Sie den Filterpunkt
Bei einer neuen Verbindung, die eine DNS-Auflösung erfordert, erfolgt die Abfrage, bevor der Seiteninhalt geladen wird. Das gibt einem genehmigten Resolver die Möglichkeit, ein blockiertes Ziel abzulehnen, bevor der Browser eine Verbindung herstellt.
Ein unabhängig konfigurierter Browser kann diese Entscheidung an einen anderen Ort senden. Der Resolver des Standorts erhält dann keine Anfrage zur Auswertung.
Das begleitende Video bietet eine weitere Möglichkeit, den Prozess zu verfolgen.
Wer Ihre Abfragen sehen kann, wenn DoH aktiviert ist
DoH verbirgt das Surfverhalten nicht vor jedem. Es schützt den DNS-Austausch vor gewöhnlichen Beobachtern zwischen dem Gerät und dem gewählten Resolver. Dieser Resolver muss die Anfrage jedoch lesen, um sie zu beantworten.
Dieser Unterschied ist in einem geteilten WiFi wichtig. Ein Gast wünscht sich berechtigterweise Schutz vor lokalem Abfangen, während ein Krankenhaus oder eine Schule sicherstellen muss, dass Sicherheits- und Bedrohungskontrollen weiterhin greifen.
DoH ändert, wem Sie bei DNS-Aktivitäten vertrauen; es nimmt nicht die Notwendigkeit, jemandem zu vertrauen.
Trennen Sie die DNS-Sichtbarkeit von der Browsing-Sichtbarkeit
Die Tabelle beschreibt die gewöhnliche DoH-Nutzung ohne zusätzliches Privacy-Relay, VPN oder Abfangelement. Das Lesen einer DNS-Nachricht und das Ableiten eines Ziels aus anderen Netzwerkaktivitäten sind unterschiedliche Funktionen.
Wer DNS Abfragen sehen kann, wenn DoH verwendet wird
| Beobachter | Sieht Domänennamen | Sieht, dass DoH verwendet wird | Warum das wichtig ist |
|---|---|---|---|
| Andere Geräte im selben WiFi | Nein, nicht aus der verschlüsselten Abfrage | Selten durch normalen Peer-Zugriff | Das passive Mitlesen der DNS-Nachricht wird blockiert |
| Veranstaltungsort- oder ISP-Netzwerk | Nein, nicht innerhalb des DoH-Austauschs | Oft, durch Datenverkehr zu einer bekannten Resolver-Adresse | Lokale DNS-Kontrollen können keine Abfragen auswerten, die woanders hin gesendet werden |
| Besuchte Websites | Nur die Website, mit der Sie sich verbinden | Nicht allein aus der Verbindung zur Website | Eine Website erhält keine Ihrer nicht verwandten DNS-Abfragen |
| Betreiber des DoH-Resolvers | Ja, jede Abfrage, die er erhält | Ja | Eine direkte Verbindung legt diese Abfragen zusammen mit Ihrer Quelladresse offen |
| Browser- oder OS-Anbieter | Nur, wenn er den Resolver betreibt oder relevante Telemetrie erhält | Die Software kennt ihren konfigurierten Modus; Anbieterberichte erfordern Telemetrie | Softwarekonfiguration ist nicht dasselbe wie automatische Anbietersichtbarkeit |
Der Resolver sieht nicht zwingend jede Abfrage, die das Gerät tätigt. Eine andere Anwendung nutzt möglicherweise einen anderen Resolver, und zwischengespeicherte Antworten erfordern keine neue Anfrage. Er sieht nur die Anfragen, die direkt an ihn gesendet werden.
Ebenso erhält der Browser-Anbieter nicht automatisch den DNS-Verlauf, nur weil er den Browser bereitstellt. Resolver-Betrieb, Software-Einstellungen und Telemetrie-Erfassung sind getrennte Aufgaben.
Machen Sie die Vertrauensentscheidung explizit
Für verwaltete Firefox-Installationen bietet Mozillas Dokumentation zur Richtlinie für DNS-over-HTTPS Steuerungen für die Resolver-Konfiguration und die Möglichkeit, festzulegen, ob Benutzer diese ändern können. Das ist ein praktischer Weg, das Verhalten des Browsers mit den DNS-Governance-Vorgaben einer Organisation abzustimmen.
Ein Standort oder ISP kann weiterhin Zieladressen, Verbindungszeiten und Datenvolumen beobachten. Auch andere Protokoll-Metadaten können dabei helfen, eine Website zu identifizieren. Daher ist eine verschlüsselte DNS-Anfrage kein Versprechen für anonymes Surfen.
Nutzen Sie eine kurze Vertrauensbewertung, bevor Sie einen Resolver genehmigen:
- Nennen Sie den Betreiber. Stellen Sie fest, welche Organisation die Anfragen erhält, anstatt sich auf die Standardbezeichnung eines Browsers zu verlassen.
- Lesen Sie die Aufbewahrungsbestimmungen. Überprüfen Sie, welche Such- und Verbindungsinformationen wie lange und zu welchem Zweck gespeichert werden.
- Prüfen Sie Zuständigkeit und Zugriff. Verstehen Sie, wo der Betreiber Informationen verarbeitet und wer Zugriff darauf erhalten kann.
- Stimmen Sie Sichtbarkeit und Verantwortung aufeinander ab. Entscheiden Sie, welche Sicherheitsereignisse Ihr IT-Team untersuchen muss und welche Browsing-Details nicht aufbewahrt werden sollten.
Die nützliche Frage ist nicht, ob Datenschutz oder Steuerbarkeit abstrakt gesehen wichtiger sind. Es geht darum, ob der von Ihnen gewählte DNS-Pfad den Benutzern eine angemessene Vertraulichkeit bietet und der Organisation gleichzeitig ermöglicht, ihre festgelegten Aufgaben zu erfüllen.
Warum DoH die DNS-Filterung in geteilten WiFi-Netzwerken schwächt
Ein Hotel gibt seinen Gästen eine Rezeptionsnummer für Empfehlungen zu lokalen Diensten. Die meisten Gäste rufen an der Rezeption an, aber ein anderer Gast nutzt stattdessen eine Branchenbuch-App. Die Rezeption kann ihre eigenen Empfehlungen steuern, nicht jedoch die Antworten dieser App.
Netzwerk-DNS funktioniert ähnlich. Ihr Netzwerk stellt einen Resolver bereit, aber ein Browser mit eigener DoH-Konfiguration fragt stattdessen möglicherweise einen externen Dienst ab.
Die Abbildung zeigt diese Ausweichroute um den DNS-Dienst des Netzwerks herum.
Bypass betrifft die Route
Das Problem ist nicht, dass eine verschlüsselte Abfrage niemals gefiltert werden kann. Es liegt darin, dass Ihr Filter keine Richtlinie auf eine Abfrage anwenden kann, die er nie erhält.
In einem Gäste-WiFi einer Familienattraktion könnte dies bedeuten, dass eine Sperre für Inhalte für Erwachsene für einen bestimmten Browser nicht gilt. In einem Mitarbeiter-Netzwerk könnte eine bösartige Anwendung eine Command-and-Control-Domain über einen nicht genehmigten Resolver auflösen.
Die Konsequenzen hängen davon ab, welche Kontrollen sich auf DNS stützen:
- Netzwerkspezifische Richtlinien. Regeln, die einer SSID oder einem VLAN zugewiesen sind, gelten nicht für Anfragen, die außerhalb des genehmigten Resolver-Pfads gesendet werden.
- Sucheinschränkungen. Die DNS-basierte Erzwingung von Safe Search kann umgangen werden, obwohl Einschränkungen auf Konto- oder Endpunktebene weiterhin gelten können.
- Bedrohungsblockierung. Ein DNS-Filter kann eine nicht gesehene Abfrage nicht verweigern, selbst wenn seine Bedrohungsliste die angeforderte Domäne enthält.
Eine Messstudie zur Bereitstellung von verschlüsseltem DNS berichtet von einer Firefox-Telemetrie, bei der im Jahr 2025 etwa 13,91 % von 9,54 Billionen Desktop-Handshakes DoH nutzten. Sie beschreibt auch einen Messdatensatz, in dem DoH etwa 6,4-mal häufiger vorkam als DoT.
Diese Beobachtungen geben keinen Aufschluss über den Anteil der Geräte, die den Filter Ihres Standorts umgehen. Browser-Standards, regionale Bereitstellungen, Resolver-Kompatibilität und Administrator-Richtlinien beeinflussen alle, ob DoH aktiv ist.
Testen Sie die Abdeckung, anstatt sie vorauszusetzen
Eine erfolgreiche Blockierung auf dem Laptop eines Mitarbeiters beweist keine gleichwertige Abdeckung auf dem privaten Smartphone eines Gastes. Die Geräte verwenden möglicherweise unterschiedliche Browser, DNS-Einstellungen oder Tunnel.
Betrachten Sie Ihren WiFi-Inhaltsfilter als eine Steuerung mit einem definierten Datenpfad. Testen Sie diesen Pfad mit den Geräten und Anwendungen, die Ihre Besucher mitbringen.
Eine Filterung, die sich nur auf den vom Netzwerk bereitgestellten Resolver stützt, bietet standardmäßig keine vollständige Abdeckung mehr. Sie erfordert unterstützende Kontrollen und eine ehrliche Berücksichtigung dessen, was außerhalb der Richtlinie verbleibt.
Was DoH an Geschwindigkeit kostet und was Filterung weiterhin leistet
Verschlüsselung sorgt für zusätzlichen Aufwand, aber die praktische Frage ist, ob Nutzer eine langsamere Sitzung bemerken. Der Ersteinrichtungsaufwand einer Verbindung und wiederholte Abfragen verursachen unterschiedliche Kosten. Daher kann das Testen einer einzelnen, neuen Anfrage ein irreführendes Bild vermitteln.
Ein empirischer Vergleich von DNS-Transporten zeigte in seiner verzögerungsfreien lokalen Baseline UDP- und TLS-Antworten unter 1 Millisekunde, während HTTP/2 durchgehend unter 10 Millisekunden blieb; die folgenden Ergebnisse geben den experimentellen Kontext der Studie wieder, anstatt die Leistung am Standort vorherzusagen.
DNS-Abfrage-Latenz nach Protokoll in der zitierten Studie
| Protokoll | Gemeldetes Ergebnis | Kontext |
|---|---|---|
| UDP | Unter 1 ms | Verzögerungsfreie lokale Baseline |
| TLS | Unter 1 ms | Verzögerungsfreie lokale Baseline |
| HTTP/2 | Konstant unter 10 ms | Wiederverwendung von Verbindungen und Multiplexing helfen, den Overhead zu reduzieren |
| HTTP/1.1 | Schwankt erheblich | Auf Pipelining-Begrenzungen zurückzuführen |
| Öffentliches DoH gegenüber herkömmlichem DNS | Langsamer pro Name | Kein signifikanter Anstieg der Gesamtladezeit der Seite beobachtet |
Messen Sie die Sitzung, nicht nur den Handshake
Dauerhafte Verbindungen ermöglichen es einem Client, den Einrichtungsaufwand auf spätere Abfragen zu verteilen. Multiplexing erlaubt es ihm, mehrere Austauschvorgänge abzuwickeln, ohne für jede Anfrage eine separate sichere Verbindung aufzubauen.
DNS-Filterung kann eine Domain vor dem Aufbau einer neuen Verbindung nach wie vor ablehnen, vorausgesetzt, die Anfrage erreicht den gefilterten Resolver. Werbe- und Tracker-Blocker können nachfolgende Anfragen reduzieren, aber Verschlüsselung allein entfernt keine Werbung und beschleunigt auch keine Seite.
Verfolgen Sie die betrieblichen Signale, die reale Probleme aufdecken:
- Handshake-Fehler. Achten Sie auf Verbindungsaufbaufehler und erneute Versuche.
- Cache-Hit-Raten. Trennen Sie zwischengespeicherte Antworten von neuer Auflösung.
- Resolver-Antwortzeit. Messen Sie das Verhalten während hoch frequentierter Gast-Sitzungen.
- Fallback-Verhalten. Überprüfen Sie, ob Fehler dazu führen, dass Geräte die Auflösung einstellen oder unbemerkt auf einen anderen Pfad wechseln.
Praktische Regel: Testen Sie das Surfen, die Richtliniendurchsetzung und die Wiederherstellung nach Fehlern gemeinsam und nicht als getrennte Abnahmeprüfungen.
Ein nahegelegener, ausfallsicherer Resolver-Endpunkt ist ein besserer Ausgangspunkt, als eine Protokollauswahl allein auf der Grundlage von Latenzannahmen zu treffen. Bestätigen Sie das Ergebnis in Ihrem Netzwerk unter realistischer Last.
DoH auf gängigen Geräten prüfen und ändern
Eine Browser-Einstellung kann erklären, warum sich Geräte im selben WiFi unterschiedlich verhalten. Menübezeichnungen ändern sich zwischen den Versionen. Nutzen Sie daher die Einstellungssuche, falls der unten angegebene Pfad nicht sichtbar ist.
Überprüfen Sie den Browser und das Betriebssystem
- Chrome: Öffnen Sie Einstellungen, Datenschutz und Sicherheit, Sicherheit und dann Sicheres DNS verwenden. Überprüfen Sie, ob der aktuelle Anbieter verwendet oder ein anderer Dienst angegeben wird.
- Firefox: Öffnen Sie Einstellungen, Datenschutz & Sicherheit und dann DNS über HTTPS. Überprüfen Sie den Schutzmodus, einschließlich Deaktiviert, Standard-Schutz oder Maximaler Schutz, sowie den ausgewählten Resolver.
- Edge: Öffnen Sie Einstellungen, Datenschutz, Suche und Dienste, Sicherheit und dann Sicheres DNS verwenden. Verwaltete Richtlinien können die Einstellung sperren.
- Android: Öffnen Sie Einstellungen, Netzwerk & Internet und dann Privates DNS. Diese Einstellung verwendet DoT anstelle von DoH; sicheres DNS auf Browser-Ebene erfordert eine separate Prüfung.
- iOS und macOS: Überprüfen Sie installierte Konfigurationsprofile, Geräteverwaltungseinstellungen und DNS-bezogene Apps. Ein verschlüsseltes DNS-Profil kann unabhängig vom Browser funktionieren.
Überprüfen Sie den effektiven Pfad
Ein System-VPN kann DNS-Anfragen unabhängig von den Browsereinstellungen durch seinen eigenen Tunnel leiten. Prüfen Sie auch, ob eine App einen separaten verschlüsselten DNS-Dienst bereitstellt.
Bestätigen Sie, welcher Resolver eine neue Testabfrage aus dem tatsächlichen Browser oder der App erhält. Nutzen Sie die Browserdiagnose oder einen Test zur Resolver-Identifizierung zusammen mit den Protokollen der zugelassenen Resolver, anstatt sich nur auf die Einstellungsanzeige zu verlassen.
Wählen und staffeln Sie Ihre DoH-Steuerungen
Staffeln Sie Steuerungen nach Gerätebesitz und Richtlinienbedarf. Verwaltete Laptops von Mitarbeitern können einer erzwungenen Konfiguration folgen; persönliche Gast-Smartphones in der Regel nicht. Wenn Sie auf beide Gruppen dieselben Einschränkungen anwenden, entstehen entweder vermeidbare Lücken oder unnötige Störungen.
Sie können externes DoH zulassen und eine geringere lokale DNS-Sichtbarkeit akzeptieren, es einschränken und Kompatibilitätsrisiken eingehen oder Richtlinien für verwaltete Geräte mit selektiven Steuerungen für das Gästenetzwerk kombinieren. Der mehrschichtige Ansatz gibt Ihnen eine klarere Aussage darüber, was geschützt ist und was nicht.
Ordnen Sie jede Steuerung ihrem tatsächlichen Umfang zu
Netzwerksteuerungen sind nützlich, machen aber nicht jeden verschlüsselten Resolver identifizierbar. Ein privater Resolver, eine sich ändernde Adresse oder ein VPN-Tunnel können Annahmen entkräften, die auf einer Liste bekannter Dienste basieren.
Kontrollen für DoH in geteilten und verwalteten Netzwerken
| Steuerung | Was verhindert wird | Wo es angewendet wird | Kompromiss / Nachteil |
|---|---|---|---|
| Ausgehenden Port 853 blockieren | DNS over TLS auf Standardport | Firewall oder Gateway | Hat keine Auswirkung auf DoH über normales HTTPS |
| Port 53 auf den Netzwerk Resolver erzwingen | Umgehung von unverschlüsseltem DNS | Gateway Durchsetzung, unterstützt durch DHCP Konfiguration | Ignoriert DoH vollständig; DHCP alleine erzwingt keine Konformität |
| Bekannte öffentliche DoH Resolver Adressen blockieren | Verbindungen zu aufgelisteten Resolvern | Firewall oder fähiges Gateway | Listen veralten, neue Resolver entstehen, einige Apps funktionieren nicht mehr |
| Browser DoH durch verwaltete Richtlinien deaktivieren | Umgehung auf Browser-Ebene in abgedeckten Browsern | Verwaltete Laptops und Mitarbeitergeräte | Erreicht keine persönlichen Smartphones im Gäste WiFi |
| Netzwerk Resolver über MDM durchsetzen | Nicht genehmigte DNS Änderungen, die durch die Geräterichtlinie abgedeckt sind | Registrierte Mitarbeiter und Unternehmensgeräte | Benötigt Registrierung und Plattform-Unterstützung; Gäste bleiben außen vor |
| DoH akzeptieren und am Endpunkt filtern | Nichts auf Netzwerkseite | Nur verwaltete Endpunkte | Gästedienste bleiben außerhalb der Endpunkprichtlinie |
Das Blockieren der Adresse eines Resolvers kann auch nicht verwandte Dienste blockieren, die unter derselben Adresse gehostet werden. Vermeiden Sie es, die Kategorie für verschlüsseltes DNS einer Firewall als dauerhaftes, vollständiges Inventar zu betrachten.
Wenn Sie Kontrolle über die Domainauflösung hinaus benötigen, evaluieren Sie ein Secure Web Gateway zusammen mit Endpunkt- und Netzwerkrichtlinien. Überprüfen Sie die Bereitstellungsanforderungen sorgfältig, insbesondere wenn sich die Geräte nicht im Besitz der Organisation befinden.
Erstellen Sie eine überprüfbare Betriebsrichtlinie
Beginnen Sie mit dem Dienst, den Sie bereitstellen müssen. Ein Verwaltungsspezifisches Mitarbeiternetzwerk, ein öffentlicher Bibliothekszugang und ein Veranstaltungsort für Kinderaktivitäten benötigen korrekterweise unterschiedliche Einschränkungen und unterschiedliche Erklärungen für die Nutzer.
Verwenden Sie diese Bereitstellungs-Checkliste:
- Listen Sie die erforderlichen Richtlinien auf. Identifizieren Sie die SSIDs, VLANs und Gerätegruppen, die Inhaltskontrollen oder Bedrohungsfilterung benötigen, und weisen Sie jedem Element einen Verantwortlichen zu.
- Trennen Sie verwaltete Geräte von Gast-BYOD. Erfassen Sie, wo Browser-Richtlinien oder MDM durchgesetzt werden können und wo nur Netzwerkkontrollen verfügbar sind.
- Schließen Sie gewöhnliche DNS-Bypass-Routen. Wo Ihre Richtlinie es erfordert, blockieren Sie ausgehendes DoT und beschränken Sie traditionelles DNS auf den genehmigten Resolver. Abdecken Sie beide unterstützten Netzwerkadressfamilien.
- Wenden Sie die Richtlinie für verwaltete Browser an. Konfigurieren Sie den genehmigten DNS-Pfad und verhindern Sie nicht unterstützte Benutzer-Overrides auf Geräten der Mitarbeiter.
- Halten Sie Resolver-Einschränkungen für Gastnetzwerke aufrecht. Überprüfen Sie blockierte Resolver-Adressen regelmäßig, testen Sie Ausnahmen und entfernen Sie Regeln, die inakzeptable Kollateralsperren verursachen.
- Veröffentlichen Sie einen verständlichen Hinweistext für Gäste. Erklären Sie, welche Kategorien gefiltert werden, welche Netzwerk-Informationen erfasst werden und welche Einschränkungen für die Nutzung von verschlüsseltem DNS oder VPN bestehen.
- Testen Sie ein reales Gerät in jedem Netzwerk. Überprüfen Sie zulässige Websites, blockierte Kategorien, genehmigte Sicherheits-Testziele, Resolver-Fehler und das VPN-Verhalten.
Vor dem Start: Eine Sperrseite beweist, dass eine bestimmte Anfrage gefiltert wurde, nicht jedoch, dass jede Anwendung auf dem Gerät demselben Pfad folgt.
Machen Sie verschlüsseltes DNS zum Bestandteil von Abnahmetests
Um Shield zu nutzen, leiten Sie das DNS des Netzwerks auf Shield um. Wir beantworten jede DNS-Abfrage in dem von uns geschützten Netzwerk auf jedem Gerät, ohne dass auf dem Gerät etwas ausgeschaltet werden kann; externe Resolver- und Tunnelpfade müssen daher in das Schutzkonzept des Netzwerks einbezogen werden.
Bevor Sie Purple Shield testen, zeigt Ihnen unser Experte, wie Ihr Netzwerk mit VPNs und verschlüsseltem DNS umgeht. Nutzen Sie dieses Gespräch, um festzulegen, welche Anfragen den geschützten DNS-Pfad erreichen, welche Kontrollen diesen durchsetzen und was passiert, wenn ein Gerät einen anderen Weg versucht.
Legen Sie Akzeptanzkriterien fest, bevor Sie den Gastzugang ändern. Ein zugelassener Resolver, ein dokumentierter Ausnahmeprozess und wiederholbare Gerätetests bieten ein solideres Fundament als die Annahme, dass ein aktivierter Filter alles erfasst.
Purple Shield bietet schützendes DNS, Inhaltsfilterung, Bedrohungsabwehr und Werbeblockierung, ohne dass Agenten auf Gastgeräten installiert werden müssen. Besuchen Sie Purple Shield, um ein Gespräch vor dem Testumfang über Ihre SSIDs, Filterrichtlinien und den Umgang Ihres Netzwerks mit verschlüsseltem DNS und VPNs zu vereinbaren.