Protective DNS erklärt: Funktionsweise und Relevanz

Ein Gast in einer Hotellobby tippt auf einen Link und die Seite beginnt zu laden. Bevor der Browser eine Verbindung zur Website herstellen kann, muss das Gerät des Gastes herausfinden, wo diese Seite im Internet gehostet wird. Dieser unauffällige Lookup ist eine Gelegenheit zu prüfen, ob das Ziel zugelassen werden sollte.

Schützendes DNS ergänzt diesen Routineschritt um eine Sicherheitsentscheidung. Es kann Organisationen dabei helfen, Personen und Geräte in gemeinsam genutzten Netzwerken zu schützen. Dies funktioniert jedoch nur, wenn deren Datenverkehr den verwalteten Resolver nutzt. Das Verständnis dieses Unterschieds erleichtert die Planung von Leistung, Ausnahmen, Umgehungsrouten und Datenschutz.

Inhaltsverzeichnis

• Warum jeder Website-Besuch mit einer DNS-Abfrage beginnt
• Was Protective DNS auf der Namensauflösungsebene bewirkt
  • Verschlüsselung und Authentizität sind nicht dasselbe wie eine Sicherheitsentscheidung
• Wie Richtliniendurchsetzung in einem Netzwerk funktioniert
  • Identität anwenden, ohne Richtlinien zu vervielfachen
  • Bypass-Routen gezielt schließen
• Performance-Auswirkungen und messbare Gewinne bei der Ladezeit
  • Testen Sie die Abfrage, nicht nur den Eindruck
  • Bedingungen einbeziehen, die Überraschungen aufdecken
• Praxisnahe Anwendungsfälle in Veranstaltungsorten und Unternehmen
• Den richtigen Ansatz für Ihr Netzwerk wählen
• Den Wert von Protective DNS jenseits von Blockierungszahlen messen
  • Erstellen Sie eine Scorecard basierend auf Ergebnissen und Ausnahmen
  • DNS-Protokolle als sensible Betriebsdaten behandeln
• Nächste Schritte zur Planung Ihres Protective DNS-Rollouts

Warum jeder Website-Besuch mit einer DNS-Abfrage beginnt

Ein Website-Name lässt sich leicht merken. Computer benötigen jedoch eine Netzwerkadresse, um eine Verbindung herzustellen. Das Domain Name System (DNS) übernimmt diese Übersetzung - ähnlich wie ein Telefonbuch, das einen Namen in eine wählbare Nummer umwandelt.

Wenn der Gast auf den Link tippt, fragt der Browser einen DNS-Resolver nach der Adresse, die mit dem Namen der Website verknüpft ist. Der Resolver sucht nach der Antwort und sendet sie zurück. Der Browser kann dann versuchen, eine Verbindung zum Ziel herzustellen. DNS überträgt nicht die Seite selbst, hilft dem Gerät aber dabei, den Ort für die Anfrage zu finden.

Abläufe dieser Art schaffen einen nützlichen Sicherheits-Kontrollpunkt. Wenn der Resolver eine angeforderte Domain als bekannte Bedrohung erkennt, kann er eine nutzbare Antwort verweigern, bevor der Browser eine Verbindung aufbaut. Ein schützender DNS-Dienst wendet Sicherheitsrichtlinien bereits in dieser Lookup-Phase an, anstatt auf eine heruntergeladene Datei oder eine verdächtige Aktion auf dem Endgerät zu warten.

Der praktische Unterschied: DNS hilft einem Gerät, ein Ziel zu finden. Protective DNS ergänzt eine Entscheidung darüber, ob die Abfrage erfolgreich sein sollte.

Dies ist besonders an Orten wichtig, an denen viele Personen und Geräte dieselbe Netzwerkinfrastruktur nutzen. In einem Hotel nutzen möglicherweise Smartphones von Gästen, Laptops von Mitarbeitern, Zahlungsterminals und vernetzte Gebäudetechnik unterschiedliche Teile desselben Gesamtnetzwerks. Ein Büro, ein Wohnkomplex oder ein öffentlicher Veranstaltungsort stehen vor einer ähnlichen Herausforderung, auch wenn sich Benutzer und Geräte unterscheiden.

Protective DNS kann einen gemeinsamen Kontrollpunkt für diese Abfragen bieten, ist jedoch kein vollständiges Sicherheitsprogramm. Es schützt kein Gerät, das den verwalteten Resolver umgeht, und es ersetzt weder den Endpunktschutz noch Zugriffssteuerungen oder ein sorgfältiges Netzwerkdesign. Die nützlichen Fragen sind, wie der Resolver seine Entscheidung trifft, wie eine Organisation Geräte auf dem vorgesehenen Pfad hält und welche Nachweise zeigen, dass der Dienst hilft, ohne Störungen zu verursachen.

Was Schutz-DNS auf der Stufe der Namensauflösung leistet

Protective DNS ist ein richtliniendurchsetzender rekursiver Resolver. Ein rekursiver Resolver verarbeitet Anfragen im Namen eines Geräts, während Protective DNS Regeln anwendet, um zu entscheiden, ob ein angefordertes Ziel eine normale DNS-Antwort erhalten soll. Es ist nicht einfach nur schnelleres oder verschlüsseltes DNS.

Verfolgen Sie eine Abfrage von Anfang bis Ende:

1. Das Gerät fordert einen Domänennamen an. Ein Browser, eine App oder ein anderer Prozess benötigt eine Adresse, bevor eine Verbindung zu einem benannten Ziel versucht werden kann.
2. Der Resolver prüft die Anfrage. Er gleicht die Domäne mit konfigurierten Richtlinien und Bedrohungsinformationen ab. Leistungsfähigere Implementierungen können auch eine aufgelöste IP-Adresse prüfen, was bei der Bewertung der Infrastruktur hinter einem Namen hilft.
3. Der Resolver liefert ein Ergebnis. Erlaubt die Richtlinie die Anfrage, liefert der Resolver eine Antwort. Tut sie das nicht, kann der Dienst die Auflösung blockieren, eine leere Antwort zurückgeben oder den Client auf eine Warnseite umleiten. Das genaue Verhalten hängt vom Produkt und der Richtlinie ab.

Einige Implementierungen suchen nach algorithmisch generierten Domains (DGAs), die Malware nutzen kann, um Command-and-Control-Infrastrukturen zu finden. Ungewöhnliche Muster in den Zeichen einer Domain, einschließlich hoher Entropie, können als Signal für eine weitere Richtlinienauswertung dienen. Diese Art der Analyse kann Threat-Intelligence-Feeds ergänzen, jedoch müssen Organisationen weiterhin überprüfen, wie ihr gewählter Dienst mit Erkennungen und Ausnahmen umgeht.

Verschlüsselung und Authentizität sind nicht dasselbe wie eine Sicherheitsentscheidung

DNSSEC hilft dabei, die Integrität und Authentizität signierter DNS-Daten zu überprüfen. DNS over HTTPS (DoH) und DNS over TLS (DoT) schützen DNS-Abfragen während der Übertragung. Diese Eigenschaften sind wichtig, entscheiden aber für sich genommen nicht darüber, ob eine existierende Domain bösartig ist. Schützendes DNS trifft diese Richtlinienentscheidung direkt am Resolver.

Für Teams, die Kontrollen für den Webzugriff und Cloud-Dienste überprüfen, kann diese Unterscheidung neben umfassenderen Leitfäden zur Sicherung von Microsoft 365-Geschäftsumgebungen stehen. Der Kernpunkt ist, verschlüsselten Transport oder authentifizierte Daten nicht als Ersatz für eine Entscheidung über das Zielrisiko zu behandeln.

Wie die Richtliniendurchsetzung in einem Netzwerk funktioniert

Ein Resolver kann für eine einzelne Anfrage eine fundierte Entscheidung treffen und dennoch am Schutz eines Netzwerks scheitern, wenn Geräte das DNS um ihn herumleiten können. Bei einer unternehmensweiten Bereitstellung geht es daher um zwei zusammenhängende Dinge: konsistente Richtlinien und einen zuverlässigen Pfad zum Resolver.

Ein zentralisiertes Design leitet DNS-Anfragen von mehreren Standorten an einen verwalteten Dienst weiter. Das erleichtert die Anwendung gemeinsamer Regeln und die Überprüfung von Aktivitäten über verschiedene Standorte hinweg. Es macht die Verfügbarkeit zudem zu einer Sicherheitsanforderung. Wenn der Resolver nicht erreichbar ist, können der normale Webzugriff und vom DNS abhängige Dienste ausfallen, selbst wenn der Rest des Netzwerks funktioniert.

Der Protective DNS-Dienst der US-Regierung wurde im September 2022 für Behörden der zivilen exekutiven Bundesebene verfügbar. Bis August 2024 hatten sich mehr als 104 Behörden angeschlossen, die täglich durchschnittlich 1,6 Milliarden gesicherte DNS-Anfragen generierten; das Programm meldete eine Resolver-Betriebszeit von 99,999 % (CISAs Protective DNS-Factsheet). Die praktische Erkenntnis daraus ist, dass Filterqualität und Dienstverfügbarkeit gemeinsam bewertet werden müssen.

Identitäten anwenden, ohne Richtlinien zu vervielfachen

Mitarbeiter, Gäste, Bewohner und verbundene Geräte benötigen nicht zwangsläufig dieselben Regeln. Ein Netzwerk kann unterschiedliche Richtlinien basierend auf der Identität oder dem Netzwerksegment zuweisen, z. B. für ein Mitarbeiternetzwerk, Gäste-WiFi und ein isoliertes Netzwerk für Gebäude-Hardware. Das Ziel besteht darin, die Richtlinie an den Benutzer oder das Gerät anzupassen und gleichzeitig den Verwaltungsaufwand überschaubar zu halten.

Zugriffskontrollen helfen dabei, diese Trennung zu etablieren, während die Überwachung des Netzwerkverkehrs Teams dabei unterstützen kann, ungewöhnliche Netzwerkaktivitäten zu untersuchen. Eine verwandte Übersicht dazu, wie sich Netzwerkzugriffskontrolle in eine verwaltete Umgebung einfügt, finden Sie unter diesen Netzwerkzugriffskontroll-Lösungen.

Bypass-Routen gezielt schließen

Wenn ein Gerät normales DNS direkt an einen externen Resolver senden kann, sieht der Protective Service die Anfrage möglicherweise nie. DoH und DoT stellen eine weitere Herausforderung dar: Verschlüsselung kann Abfragen bei der Übertragung schützen, aber ein nicht verwalteter Resolver kann sie auch außerhalb der Richtlinien und der Einsehbarkeit der Organisation verlagern.

Wo eine Durchsetzung erforderlich ist, sollten Teams direkte DNS-Pfade und unautorisierte verschlüsselte DNS-Ziele identifizieren und dann entscheiden, wie Netzwerk-, Endpunkt- und Browser-Steuerungen damit umgehen. Testen Sie auch die Ausnahmen. Captive Portals, mobile Geräte, IPv6 und Anwendungen mit eigenen Resolver-Einstellungen können sich anders verhalten als ein verwalteter Laptop in einem Unternehmensnetzwerk. Die Richtlinie funktioniert nur auf den Pfaden, die die Organisation steuern kann.

Leistungsauswirkungen und messbare Gewinne bei der Seitenladezeit

Ein Protective DNS-Dienst muss das Surfen nicht spürbar verlangsamen. Die Auswirkung hängt weniger vom eigentlichen Filtervorgang ab als von praktischen Designentscheidungen: wo der Resolver platziert ist, wie er Antworten zwischenspeichert, wie er Verbindungen aufrechterhält und ob Geräte ihn umgehen.

Verschlüsseltes DNS kann die Einrichtungszeit verlängern, wenn eine Verbindung TCP, TLS oder HTTP aufbauen muss, bevor eine Anfrage gesendet wird. Die Wiederverwendung einer dauerhaften Sitzung vermeidet das Wiederholen eines Großteils dieser Einrichtung. TLS 1.3, 0-RTT, HTTP/2-Multiplexing und QUIC können laut unabhängigen Messungen der Leistung von verschlüsseltem DNS ebenfalls den Verbindungs-Overhead reduzieren. Unter normalen Netzwerktrends kann die reine Lookup-Latenz vernachlässigbar sein, was jedoch nicht für jeden Client oder Netzwerkpfad garantiert werden kann.

Testen Sie die Abfrage, nicht nur den Eindruck

Ein nahegelegener, hochverfügbarer Resolver und ein standardkonformes Caching tragen dazu bei, dass gewöhnliche Abfragen zügig beantwortet werden. Ein einzelner durchschnittlicher Latenzwert kann jedoch langsame Ladezeiten für eine Teilmenge von Benutzern verbergen - oder Fälle, in denen der Resolver eine Antwort abrufen muss, die noch nicht im Cache gespeichert ist.

Messen Sie p50-, p90- und p99-Lookup-Latenz separat für kalte und warme Caches. Der Median zeigt einen typischen Lookup; die höheren Perzentile offenbaren langsamere Fälle, die Benutzer möglicherweise stärker betreffen. Halten Sie die Lookup-Geschwindigkeit getrennt von der gesamten Ladezeit der Seite, da DNS nur ein Teil der Reise eines Browsers ist.

Berücksichtigen Sie die Bedingungen, die Überraschungen aufdecken

Testen Sie über diejenigen Netzwerke und Geräte, die von Personen tatsächlich genutzt werden - einschließlich mobiler Clients, IPv6 und Captive Portals. Überprüfen Sie Anwendungen und Browser, die möglicherweise ihren eigenen DoH- oder DoT-Dienst auswählen, da diese sowohl die Route als auch die Sichtbarkeit von DNS-Anfragen verändern können.

In verteilten Messungen wurde beobachtet, dass DoQ (DNS over QUIC) nahezu die Leistung von Klartext erreicht und einige Seitenladezeiten im Vergleich zu DoH verbessert. Betrachten Sie solche Ergebnisse als Anlass, Transportoptionen in Ihrer eigenen Umgebung zu testen, nicht als Versprechen eines bestimmten Resultats. Das praktische Ziel ist ein nahegelegener Resolver, effektives Caching, wiederverwendbare verschlüsselte Sitzungen und ein Design, das keine unverwalteten Pfade offen lässt.

Praxisnahe Anwendungsfälle in Standorten und Unternehmen

Eine landesweite Bereitstellung zeigt, was Schutz-DNS leisten kann, wenn viele Organisationen eine verwaltete Sicherheitsebene gemeinsam nutzen. Im Vereinigten Königreich stieg die Zahl der Organisationen, die den Protective Domain Name System-Dienst nutzen, im Jahr 2022 von 944 auf 1.173, was einem Anstieg von 24 % entspricht. Im Laufe dieses Jahres verarbeitete der Dienst ca. 0,55 Billionen DNS-Anfragen und blockierte 11 Milliarden Anfragen im Zusammenhang mit bösartigen Zielen, was etwa 2 % aller Anfragen entspricht (UK NCSC PDNS-Zusammenfassung).

Diese Größenordnung verdeutlicht den Wert einer Entscheidung, bevor ein Verbindungsversuch unternommen wird. Es beweist nicht, dass jede blockierte Anfrage zu einem Vorfall geworden wäre oder dass DNS allein jeden Weg zu einer Bedrohung gestoppt hat. Für einen Betreiber mehrerer Standorte ist der nützliche Vergleich, ob der Dienst Richtlinien konsistent anwenden, umsetzbare Telemetrie liefern und das Volumen sowie Ausnahmen dieser Umgebung bewältigen kann.

Überlegen Sie, wie derselbe Kontrollpunkt zu verschiedenen Standorten passt:

• Hotels und Wohnimmobilien: Trennen Sie den Gäste- oder Bewohnerzugang von Personal- und Gebäude-Geräten. Ein Captive Portal, ein älteres Gerät oder der von einem Bewohner bevorzugte verschlüsselte Resolver können Ausnahmen darstellen, die eingeplant werden müssen.
• Flughäfen und Stadien: Wenden Sie eine gemeinsame Grundlinie für den öffentlichen Zugang mit hoher Fluktuation an, während Sie Betriebs- und Personalnetzwerke getrennt halten. Achten Sie auf unverwaltete Geräte und Konnektivitätsanforderungen, die eine dokumentierte Ausnahme erfordern.
• Gesundheitswesen und Bildung: Beschränken Sie den Zugriff auf schädliche Ziele, ohne legitime Dienste zu blockieren, die für Pflege, Unterricht oder Verwaltung genutzt werden. Bieten Sie einen klaren Überprüfungspfad, wenn eine Richtlinie etwas blockiert, das für die Arbeit benötigt wird.
• Einzelhandel und Einkaufszentren: Unterscheiden Sie Besucherverkehr von Kassen, Personalgeräten und anderen betrieblichen Geräten. Einzelhandelsteams, die den Gästezugang planen, finden möglicherweise auch diese Retail-WiFi-Lösungen nützlich, wenn sie darüber nachdenken, wie Zugang und Richtlinien zusammenpassen.

Eine kurze Einführung in das Thema kann Teams auch dabei helfen, sich darüber abzustimmen, was die DNS-Schicht leistet und was nicht:

In jedem Kontext ist DNS-Filterung eine teilweise Kontrolle und keine Garantie dafür, dass jede Bedrohung gestoppt wird. Ein Benutzer kann Infrastruktur über einen anderen Resolver oder eine direkte IP-Adresse erreichen, und eine Anwendung kann Protokolle nutzen, die nicht auf dem DNS-Pfad der Organisation basieren. Die Bereitstellung erfordert daher neben der eigentlichen Richtlinie auch Ausnahmenbehandlung und Überwachung.

Wahl des richtigen Ansatzes für Ihr Netzwerk

Protective DNS arbeitet auf der Resolver-Ebene. Endpoint-Agents, Browsereinstellungen und Netzwerkkontrollen agieren an unterschiedlichen Stellen, weshalb Teams in der Regel eine Kombination statt eines einzelnen Ersatzes wählen. Der richtige Mix hängt davon ab, wer das Gerät verwaltet, welchen Datenverkehr das Netzwerk sehen kann und wie Ausnahmen gehandhabt werden sollen.

Steuerung	Optimaler Einsatz	Sichtbarkeit	Typische Einschränkung
Protective DNS	Gemeinsam genutzte Netzwerke, verwaltete Umgebungen und Durchsetzung von DNS-Richtlinien	DNS-Anfragen, die den Resolver passieren	Nicht verwaltete Resolver und Pfade außerhalb des DNS können die Steuerung umgehen
Endpoint-Agent	Verwaltete Laptops und Mobilgeräte, die Schutz außerhalb des Netzwerks benötigen	Aktivitäten, die für den installierten Agenten sichtbar sind	Abdeckung hängt von Installation, Status und Verwaltung des Agenten ab
Browser-Richtlinie	Verwaltete Browser, bei denen Resolver- und Browsing-Einstellungen steuerbar sind	Browser-Konfiguration und ausgewählte Browser-Aktivitäten	Deckt nicht jede App oder nicht verwaltete Browser ab
Netzwerk-Steuerungen	Segmentierte Netzwerke und Datenverkehr über verwaltete Infrastruktur	Netzwerkflüsse innerhalb der Abdeckung der Steuerung	Verschlüsselter oder externer Datenverkehr kann die Überprüfung einschränken
Identitäts- und Zugriffssteuerungen	Mitarbeiter, Gäste, Bewohner und Gerätegruppen mit unterschiedlichen Zugriffsanforderungen	Verbindungs- und Zugriffsentscheidungen gekoppelt an Identität oder Segment	Eine erlaubte Verbindung bewertet nicht automatisch jedes Ziel selbst

Für verwaltete Laptops können Endpunkt- und Browserkontrollen die Resolver-Richtlinie ergänzen, insbesondere wenn Mitarbeiter außerhalb des Büros arbeiten. Gast-WiFi und BYOD sind mit Agenten schwerer zu verwalten. Das macht netzwerkseitige Kontrollen praktischer, vorausgesetzt, die Organisation kann den DNS-Verkehr auf ihren gewählten Dienst leiten. IoT- und Privatgeräte erfordern oft eine Segmentierung und eine Richtlinie, die den eingeschränkten Geräteverwaltungsoptionen Rechnung trägt.

Für Teams, die Netzwerkidentitäten, Filterungen und benutzerseitige Prüfungen vergleichen, können kostenlose DNS- und E-Mail-Prüfungen von mailX eine relevante Ressource neben einer umfassenderen Überprüfung der Zugriffssteuerungen sein. Wenn Zahlungsumgebungen Teil der Infrastruktur sind, sollten Sie auch berücksichtigen, wie sich das WiFi-Design und die PCI-Compliance-Anforderungen auf die Netzwerktrennung und -verwaltung auswirken.

Purple Access kombiniert offene, sichere und xPSK-Netzwerkoptionen auf bestehenden Access Points mit Captive Portal-Onboarding und identitätsbasierter Netzwerkzuweisung. Purple Shield ergänzt dies um Schutz-DNS und Inhaltsfilterung mit steuerbaren Richtlinien. Diese Funktionen können neben Endpunkt- und Browser-Kontrollen eingesetzt werden, ersetzen jedoch nicht die Notwendigkeit, Resolver-Durchsetzung, Ausnahmen und Überwachung zu definieren. Wählen Sie Tools entsprechend den Pfaden und Geräten aus, die Sie schützen müssen, und überprüfen Sie anschließend, ob deren Richtlinien zusammenarbeiten.

Messung des Werts von Schutz-DNS über reine Blockierzahlen hinaus

Die Gesamtzahl blockierter Anfragen zeigt Ihnen, dass der Resolver aktiv war. Für sich genommen zeigt sie jedoch nicht, ob die richtigen Anfragen abgefangen wurden, produktive Arbeit gestört wurde oder Datenverkehr über eine andere Route unbemerkt geblieben ist. Zählen Sie die Entscheidung, aber messen Sie die Kontrollwirkung.

Der DNS-Workshop der European Internet Industry Association meldete 2,3 Millionen Missbrauchsberichte über 780.000 eindeutige Domains in den vergangenen sechs Monaten, wobei die monatlichen Berichte von 220.000 auf 380.000 stiegen (Workshop-Bericht). Diese Zahlen zeigen das Ausmaß des gemeldeten Missbrauchs. Sie belegen jedoch nicht, wie viele Vorfälle ein Resolver verhindert hat, ob eine Blockierung korrekt war oder ob der betroffene Datenverkehr sein Ziel über ein VPN, einen alternativen Resolver, eine fest codierte IP-Adresse oder ein verschlüsseltes Anwendungsprotokoll erreicht hat.

Erstellen Sie eine Scorecard rund um Ergebnisse und Ausnahmen

Eine nützliche Überprüfung kombiniert Sicherheit, Dienstqualität und operative Reaktion. Nachverfolgen lässt sich, ob der Resolver bekannte schädliche Domains erkannt hat, wie schnell Teams Anfragen zu fälschlicherweise blockierten Inhalten (False Positives) bearbeiten und ob Richtlinienänderungen die vorgesehenen Standorte umgehend erreichen. Kombinieren Sie diese Maßnahmen mit der Resolver-Verfügbarkeit sowie der mittleren und maximalen Lookup-Latenz.

Messen Sie auch Bypass-Versuche. Eine geringe Anzahl blockierter Anfragen kann bedeuten, dass in der Umgebung wenig schädliche Aktivität stattfindet, oder dass die Geräte den geschützten Resolver nicht nutzen. Korrelieren Sie relevante Ereignisse mit der Netzwerkidentität, wie z. B. einer SSID, einem VLAN, einem Standort oder einer Benutzergruppe, damit Ermittler sehen können, wo eine Richtlinie gilt und wo sich eine Ausnahme verbergen könnte. Vergleichen Sie die DNS-Aktivität mit Endpunkt- oder Vorfallsdaten, anstatt zu behaupten, dass jede blockierte Abfrage einen verhinderten Vorfall darstellt.

Behandeln Sie DNS-Protokolle als sensible Betriebsdaten

DNS-Protokolle können das Surfverhalten offenlegen, was im Gesundheitswesen, im Bildungswesen, im Gastgewerbe und in Wohnbereichen besondere Sorgfalt erfordert. Legen Sie Aufbewahrungsfristen fest, beschränken Sie den Zugriff nach Rollen und trennen Sie Sicherheitstelemetrie von Gäste-Marketingdaten. Entscheiden Sie, wer ein Sicherheitsereignis untersuchen darf und welche Daten benötigt werden, bevor Sie Protokolle im großen Maßstab erfassen.

Nächste Schritte für die Planung Ihres Protective-DNS-Rollouts

Beginnen Sie mit dem Pfad, nicht mit dem Dashboard. Kartieren Sie, welche Geräte den verwalteten Resolver nutzen, identifizieren Sie, wo direktes DNS oder unautorisiertes verschlüsseltes DNS diesen umgehen könnte, und entscheiden Sie, wie die Durchsetzung für Geräte erfolgt, die nicht von der Organisation verwaltet werden. Richten Sie zudem einen Ausnahme-Prozess für legitime Dienste ein, die durch eine Richtlinie blockiert werden.

Vereinbaren Sie vor der Einführung, wie das Team sowohl die Sicherheit als auch die Servicequalität bewerten wird:

• Resolver-Nutzung bestätigen: Überprüfen Sie verwaltete Geräte, Gästenetzwerke und weniger vorhersehbare Geräte wie IoT.
• Netzwerkpfad testen: Wo eine Durchsetzung erforderlich ist, prüfen Sie direktes DNS und unautorisierte verschlüsselte DNS-Routen.
• Leistung messen: Vergleichen Sie die Abfrage-Latenzzeiten von Cold- und Warm-Caches, einschließlich langsamerer Perzentile.
• Bewertungsmatrix definieren: Verfolgen Sie den Umgang mit Fehlalarmen, Verfügbarkeit, Richtlinienverteilung, Umgehungsversuche und Incident-Ergebnisse.
• Datenschutzregeln festlegen: Bestimmen Sie Grenzen für Protokollzugriff und Aufbewahrung, bevor die umfassende Datenerfassung beginnt.

Bringen Sie bei einer Bereitstellung an mehreren Standorten Netzwerk- und Sicherheitsteams zusammen, um Identitäten, Netzwerksegmente, Resolver-Routen und die für jeden Standort erforderlichen Ausnahmen zu erfassen. Purple bietet von Netzwerkingenieuren geleitete Design-Sessions an, um Bereitstellungspläne zu gestalten und zu validieren. Protective DNS kann schädliche Ziele über den verwalteten Abfragepfad schwerer erreichbar machen, ersetzt jedoch weder Endpunktsicherheit noch Netzwerktrennung oder Datenschutz-Governance.

---

Purple Access unterstützt offene, sichere und xPSK WiFi-Netzwerke mit identitätsgesteuerter Netzwerkzuweisung und Onboarding von Gästen oder BYOD-Geräten auf bestehenden Access Points. Um zu planen, wie diese Zugangskontrollen zusammen mit Protective DNS an Ihren Standorten funktionieren können, besuchen Sie Purple Access.