DNS-Filter-Verhalten "Fail Open" vs. "Fail Closed": Was passiert bei einem Filterausfall?

Beim DNS-Filtering bezeichnet die Entscheidung zwischen Fail-Open und Fail-Closed das Verhalten eines Netzwerks, wenn sein gefilterter Resolver nicht mehr antwortet. Bei Fail-Open wird auf einen ungefilterten Resolver zurückgegriffen, sodass das Surfen ohne Schutz fortgesetzt werden kann. Fail-Closed leitet Anfragen nirgendwo anders hin weiter - gemäß der Steuerung SC-24 der Richtlinie NIST SP 800-53 (Fail in a known state) -, sodass nichts ungefiltert aufgelöst wird.

Was bedeutet Fail-Open vs. Fail-Closed beim DNS-Filtering?

DNS-Filtering setzt direkt beim ersten Schritt jeder Verbindung an. Ein Telefon fordert einen Resolver auf, einen Domänennamen in eine IP-Adresse umzuwandeln, bevor eine Sitzung eröffnet wird (RFC 1035). Ein schützender DNS-Resolver gleicht diesen Namen mit Threat Intelligence und Ihrer Inhaltsrichtlinie ab. Anschließend gibt er die tatsächliche Adresse, die Adresse einer Sperrseite oder eine Ablehnung zurück.

Diese Platzierung ist der Grund, warum DNS-Filtering funktioniert. Die Überprüfung findet statt, bevor ein einziges Paket das Ziel erreicht. Es kann einen Phishing-Link oder einen Malware-Callback stoppen, den eine Firewall lediglich als zugelassenen Datenverkehr auf Port 443 sehen würde. Das UK National Cyber Security Centre betreibt nach demselben Prinzip einen Schutz-DNS-Dienst für den öffentlichen Sektor.

Diese Platzierung ist jedoch auch die Schwachstelle. Wenn jede Abfrage vom gefilterten Resolver abhängt, benötigen Sie einen Plan für den Fall, dass dieser nicht erreichbar ist. Es gibt nur zwei Pläne:

• Fail-Open: Das Netzwerk oder Gerät sendet die Anfrage an einen anderen Resolver, der keine Richtlinie anwendet. Das Surfen wird fortgesetzt, aber Schutz, Protokollierung und Inhaltsregeln stoppen, bis der Filter wieder verfügbar ist.
• Fail-Closed: Es existiert kein ungefilterter Pfad. Neue Abfragen warten auf die Antwort eines gefilterten Resolvers, und nichts wird ohne eine Richtlinienentscheidung aufgelöst.

Die Wahl ist eine Abwägung zwischen Verfügbarkeit und Absicherung. Fail-Open bevorzugt den Besucher, der möchte, dass eine Seite sofort lädt. Fail-Closed bevorzugt Ihr Sicherheitsteam, Ihre Jugendschutzbeauftragten und Ihre Auditoren, die nachweisen müssen, dass das Netzwerk in jeder Minute des Jahres gefiltert wurde.

NIST SP 800-53 Rev. 5 drückt dieselbe Idee in zwei Steuerungen aus. SC-24 steht für „Fail in a known state“ und SC-7(18) für „Fail secure“ (NIST SP 800-53 Rev. 5).

Wie funktioniert das Ausfallverhalten von Filtern beim Resolver?

Ihre Konfiguration bestimmt das Ausfallverhalten des Filters, nicht der Filter selbst. Drei Stellen legen dies fest: DHCP, jeder lokale DNS-Forwarder und das Gerät selbst.

Die DHCP-DNS-Felder

DHCP ist das Protokoll, das jedem Gerät beim Beitritt seine IP-Adresse und Netzwerkeinstellungen zuweist. Die meisten Gäste- und Mitarbeiternetzwerke nutzen es, um jedem Gerät zwei oder mehr DNS-Serveradressen zu übergeben. Wenn alle auf gefilterte Resolver verweisen, ist das Design Fail-Closed. Wenn die zweite Adresse auf einen ISP oder einen öffentlichen Resolver verweist, ist das Design Fail-Open - unabhängig davon, was der Filter-Anbieter verspricht.

Der lokale Forwarder

Viele Firewalls und Gateways betreiben einen DNS Forwarder. Geräte fragen das Gateway ab, und das Gateway leitet die Anfrage an vorgelagerte Resolver weiter. Hier befindet sich das Fallback in der Upstream Liste des Forwarders. Ein Forwarder, der einen öffentlichen Resolver unterhalb des Filters auflistet, verhält sich im Fehlerfall offen (Fail Open), selbst wenn DHCP sauber aussieht.

Das eigene Verhalten des Geräts

Die Auswahl des Resolvers variiert je nach Betriebssystem. Einige Geräte behandeln den zweiten Server als striktes Standby. Andere fragen ihn ab, sobald der erste langsam ist, oder senden Anfragen an beide. Bei einem Fail Open Design können daher ungefilterte Antworten durchsickern, obwohl der Filter vollkommen funktionsfähig ist.

Wie Fail Closed aussieht

Bei einem Fail Closed Design verweist jede DNS-Adresse, die ein Gerät oder Forwarder nutzen kann, auf einen filternden Resolver mit derselben Richtlinie. Wenn einer nicht mehr antwortet, versucht es das Gerät über den nächsten. Die Abfrage schlägt nur fehl, wenn jeder filternde Resolver unerreichbar ist. Das Gerät erhält dann anstelle einer ungefilterten Antwort eine Zeitüberschreitung oder SERVFAIL, die standardmäßige DNS-Antwort für "Serverfehler".

Richtig umgesetzt ist Fail Closed nicht anfällig. Die Ausfallsicherheit entsteht durch redundante Filter-Resolver, nicht durch ein ungefiltertes Hintertürchen.

Fail Open, Fail Closed, Fail Secure: Welche Begriffe werden verwechselt?

Vier verwandte Begriffe tauchen in Anbieterdokumenten, Audit-Ergebnissen und Change-Tickets auf. Sie beschreiben unterschiedliche Dinge, und eine Verwechslung führt zu einer falschen Architektur.

Fail closed ist nicht Default Deny

Default Deny ist eine Richtlinienentscheidung bezüglich unkategorisierter Domains. Sie greift, solange der Filter ordnungsgemäß funktioniert. Bei Fail closed geht es darum, was passiert, wenn der Filter nicht erreichbar ist. Sie können Fail closed mit einer toleranten Richtlinie oder Fail open mit einer strengen Richtlinie betreiben.

Serve-stale liegt dazwischen

RFC 8767 erlaubt es einem Resolver, aus einem abgelaufenen Cache zu antworten, wenn er die Upstream-Server nicht erreichen kann. Dadurch bleiben beliebte Namen bei kurzen Ausfällen funktionsfähig. Es gibt die letzte Entscheidung wieder; eine Domain, die in der Zwischenzeit bösartig geworden ist, wird daher nicht erfasst.

Bypass ist kein Ausfall

Ein Gerät, das DNS over HTTPS (DoH, RFC 8484) oder DNS over TLS (DoT, RFC 7858) zu einem öffentlichen Resolver nutzt, gelangt nie an Ihren Filter. Fail-closed-Einstellungen bewirken hier nichts. Bypass verhindern Sie durch Egress-Regeln.

Wo begegnet Ihnen ein Ausfall der DNS-Filterung in der Praxis?

Ein Ausfall der DNS-Filterung ist nur dann von Bedeutung, wenn die Internetverbindung steht, der Filter aber nicht erreichbar ist. Wenn die gesamte Anbindung ausfällt, verhalten sich beide Modi gleich. In der Praxis entsteht die Lücke durch ganz normale Betriebserlebnisse:

• Eine Firewall-Änderung, die den ausgehenden Port 53 zu den Adressen des Filters blockiert;
• Ein lokaler Forwarder, der abstürzt oder die Weiterleitung nach oben einstellt;
• Eine Routing-Änderung in einem Filial-WAN, die den DNS-Verkehr in die falsche Richtung leitet;
• Ein Dienstleister bearbeitet einen DHCP-Bereich und fügt einen öffentlichen Resolver "zur Ausfallsicherheit" hinzu;
• Ein Vorfall beim Filtering-Anbieter selbst.

Jedes dieser Szenarien sieht in einem Fail-Closed-Netzwerk harmlos aus. In einem Fail-Open-Netzwerk entfernt jedes davon stillschweigend den Schutz.

Hospitality-Gastnetzwerke

Hotels und Gastronomiebetriebe wenden Inhaltsrichtlinien an, damit das Gäste-WiFi für Familien geeignet und vor Malware geschützt bleibt. Ein Fail-Open-Gästenetzwerk hebt diese Richtlinie auf, ohne jemanden zu benachrichtigen. Für große Gastronomie- und Hotelbetreiber birgt ein Richtlinienausfall im öffentlichen WiFi sowohl Marken- als auch Sicherheitsrisiken.

Gesundheitswesen

Shield blockiert wöchentlich rund 241.000 Bedrohungen im St George's Healthcare NHS Trust. Nach unserer Berechnung entspricht das durchschnittlich etwa 1.400 pro Stunde. Ein einstündiges Fail-Open-Fenster würde dazu führen, dass diese Abfragen auf Geräten von Patienten, Besuchern und Mitarbeitern ungeprüft aufgelöst werden.

Transportknotenpunkte

Flughäfen verzeichnen Tausende von Passagiergeräten in öffentlichen Netzwerken, von denen viele unverwaltet sind. In einem Terminal bedeutet eine Fail-Open-Lücke ein ungefiltertes öffentliches Netzwerk bei Spitzenauslastung.

Mitarbeiter- und Unternehmensnetzwerke

Mitarbeiternetzwerke erhöhen die Anforderungen an die Verfügbarkeit. Business-Apps müssen weiterhin funktionieren, daher benötigt Fail Closed eine echte Redundanz im Hintergrund. Interne Namen werden in der Regel auf internen DNS-Servern aufgelöst, die externe Anfragen dann an den Filter weiterleiten. Stellen Sie sicher, dass diese Weiterleitungsebene ebenfalls keinen ungefilterten Upstream hat.

Wo liegen die Grenzen und Sonderfälle von Fail-Closed-DNS?

Fail Closed ist der richtige Standard für die meisten Gäste- und Mitarbeiter-WiFi-Netzwerke. Dennoch gibt es Grenzen, die Sie kennen sollten, bevor Sie Ihr System darauf auslegen.

Fail Closed mit nur einem Resolver ist ein Ausfallplan

Wenn das Netzwerk eine einzelne Filtering-Adresse auflistet, bedeutet Fail Closed, dass jeder Ausfall dieser Adresse das gesamte DNS lahmlegt. Redundanz über mehrere Filtering-Resolver hinweg macht Fail Closed erst praktikabel. Fragen Sie Ihren Anbieter, wie viele Resolver-Adressen Sie konfigurieren können, und testen Sie jede einzelne.

Der Cache hält einige Namen aktiv

Jede DNS-Antwort enthält eine TTL (Time to Live), also die Anzahl der Sekunden, die ein Gerät oder Resolver sie zwischenspeichern darf. Während eines kurzen Ausfalls funktionieren zwischengespeicherte Namen weiterhin, während neue Namen fehlschlagen. Besucher bemerken dies als "einige Websites funktionieren, andere nicht", was Ihren Helpdesk irreführen kann.

Captive Portals benötigen DNS vor der Anmeldung

Ein Captive Portal ist die Begrüßungsseite, die ein Gast vor dem Verbinden sieht. Das Gerät muss das Portal und alle Walled-Garden-Domains auflösen, bevor es sich authentifiziert. Wenn das Netzwerk vor der Anmeldung einen ungefilterten Resolver verwendet, wird das Portal zur Lücke. Wenn es ohne Redundanz auf Fail Closed schaltet, können sich Gäste überhaupt nicht anmelden.

Ein Fehler sieht anders aus als eine Blockierung

Eine blockierte Domain sollte eine Sperrseite oder eine deutliche Verweigerung zurückgeben. Eine fehlgeschlagene Abfrage gibt ein Timeout oder SERVFAIL zurück. RFC 8914 Extended DNS Errors fügt Codes hinzu, die diese voneinander unterscheiden, wie z. B. Blocked (15) und Filtered (17) im Vergleich zu No Reachable Authority (22). Informieren Sie Ihren Helpdesk über beides, damit dieser eine Richtliniensperre von einem Ausfall unterscheiden kann.

DNS kann nicht über den Namen hinausschauen

Fail-Closed garantiert eine Richtlinienentscheidung bei jeder Abfrage, keine vollständige Abdeckung. Verbindungen zu reinen IP-Adressen umgehen DNS vollständig. Verbindungen, die bereits vor dem Ausfall geöffnet waren, bleiben bestehen. DNS sieht außerdem nur die Domain, niemals den Pfad, was unter Warum DNS-Filterung keine vollständigen URLs sehen kann erklärt wird.

Wo sich diese Grenzen in einen breiteren Stack einfügen, erfahren Sie unter Ist DNS-Filterung ausreichend? und in der Übersicht Grenzen der DNS-Filterung.

Wie bezieht sich Fail-Closed-DNS auf Purple Shield?

Purple Shield ist schützendes DNS und Content-Filterung für jedes Netzwerk. Shield arbeitet nach dem Prinzip Fail-Closed, sodass ein Ausfall ein Netzwerk niemals ungefiltert lässt. Jede Abfrage erhält eine Richtlinienentscheidung oder keine Antwort, aber niemals eine ungeprüfte.

Sie können Shield standalone auf jedem WiFi Netzwerk oder zusammen mit Purple Access ausführen. Sie legen eine Richtlinie pro Netzwerk und pro VLAN (Virtual LAN, ein logisch getrenntes Netzwerk auf gemeinsamer Hardware) fest. Gast-, Mitarbeiter- und Back-Office-Netzwerke an einem Standort können jeweils unterschiedliche Regeln enthalten. Shield benötigt keine neue Hardware und sitzt als Cloud-Overlay auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks und Fortinet.

DNSFilter und Cisco Umbrella filtern ebenfalls bei der DNS-Auflösung, sodass das Platzierungsargument für alle drei gilt. Die Frage, die Sie jedem Anbieter stellen sollten, ist, wo der Fallback liegt. Fragen Sie, wie sich deren Roaming-Agenten verhalten, wenn Resolver nicht erreichbar sind, und wie viele Filter-Adressen Sie konfigurieren können. Überprüfen Sie dann, ob Ihre eigenen DHCP- und Forwarder-Einstellungen nicht erneut einen ungefilterten Pfad einführen.

Shield läuft über die gesamte Präsenz von Purple von über 80.000 Standorten in 90 Ländern. Lesen Sie Wie Shield funktioniert für Details zur Bereitstellung. Der Enterprise WiFi Security Guide zeigt, wo DNS-Filterung neben Identität und Segmentierung eingeordnet ist.

Dieses Konzept greift im Wartungsfenster, nicht in der Broschüre. Die Firewall-Regel, die DHCP-Änderung oder der "ausfallsichere" öffentliche Sekundär-Server entscheiden darüber, ob Ihr Netzwerk gefiltert bleibt. Überprüfen Sie diese drei Einstellungen in diesem Quartal. Lesen Sie als Nächstes DNS over TLS und Filterung: was Port 853 ändert, da ein Fail-Closed-Resolver nur Geräte schützt, die ihn auch tatsächlich nutzen.

Häufig gestellte Fragen

Bedeutet Fail-Closed-DNS, dass ein Ausfall mein WiFi offline nimmt?

Nein, nicht, wenn der Filter auf redundanten Resolvern läuft. Fail-Closed stoppt neue Abfragen nur dann, wenn alle gefilterten Resolver gleichzeitig unerreichbar sind. Geräte versuchen es zuerst über die nächste gefilterte Adresse erneut. Zwischengespeicherte Antworten sorgen dafür, dass vor kurzem besuchte Websites bei kurzen Unterbrechungen weiterhin aufgelöst werden. Planen Sie die Redundanz vor dem Go-Live und testen Sie diese, indem Sie nacheinander jeweils einen Resolver von einem Test-VLAN aus blockieren.

Funktionierte Shield mit den Access Points und Firewalls, die ich bereits besitze?

Ja. Shield filtert bei der DNS-Auflösung, benötigt daher keine neue Hardware und läuft eigenständig in jedem WiFi-Netzwerk. Purple funktioniert mit Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme und Fortinet. Sie weisen das DNS für jedes Netzwerk oder VLAN auf Shield zu, entfernen ungefilterte Fallbacks und wenden eine Richtlinie pro Netzwerk an. Die Schritte finden Sie auf der Produktseite.

Wie wird Shield preislich gestaltet?

Purple erstellt ein Angebot für Shield passend für Ihre Infrastruktur, anstatt einen Listenpreis in diesem Leitfaden zu veröffentlichen. Shield ist ein Sicherheits-Add-on, das Sie eigenständig in jedem WiFi-Netzwerk oder zusammen mit Purple Access ausführen können. Das Angebot spiegelt daher Ihre Netzwerke und Standorte wider, nicht neue Hardware. Fordern Sie ein Angebot mit Angabe Ihrer Standortanzahl, Ihrer Netzwerk- und VLAN-Anzahl sowie der Information an, ob Sie bereits Purple nutzen.

Wie wechsle ich von DNSFilter oder Cisco Umbrella ohne Filterlücke?

Stellen Sie ein Netzwerk oder VLAN nach dem anderen um. Weisen Sie das DHCP-DNS eines Test-VLAN auf Shield zu, bestätigen Sie Blockierungen sowie Protokolle und stellen Sie dann die Live-Netzwerke innerhalb eines Wartungsfensters um. Entfernen Sie die alten Resolver-Adressen vollständig, anstatt sie als sekundäres DNS zu belassen. Überprüfen Sie auch Roaming-Agents auf Geräten von Mitarbeitern, da deren Fallback-Einstellungen außerhalb Ihres DHCP-Bereichs liegen.

Schreibt eine Vorschrift Fail-Closed-DNS-Filterung vor?

Keine Regulierung nennt Fail-Closed-DNS explizit, aber Kontrollframeworks erwarten, dass Sicherheitskontrollen in einem bekannten, sicheren Zustand fehlschlagen. NIST SP 800-53 Rev. 5 Control SC-24 behandelt das Fehlschlagen in einem bekannten Zustand. SC-7(18) behandelt den Schutz von Grenzen, der im Fehlerfall sicher bleibt. Eine Fail-Closed-Filterung liefert Ihnen den Nachweis, dass die Richtlinie zu jedem Zeitpunkt angewendet wurde - was bei Anfragen von Auditoren oder Jugendschutzbeauftragten hilft.

Wie teste ich das Verhalten meines aktuellen Filters im Fehlerfall?

Blockieren Sie ausgehendes DNS zu Ihren gefilterten Resolvern von einem einzelnen Test-VLAN aus und beobachten Sie das Verhalten des Geräts. Wenn Websites weiterhin geladen werden und der Filter nichts protokolliert, schlägt das Netzwerk open fehl. Überprüfen Sie die DHCP-DNS-Felder, Forwarder-Upstream-Listen und alle fest codierten Geräteeinstellungen. Wiederholen Sie den Vorgang, wobei jeweils ein gefilterter Resolver blockiert wird, um zu bestätigen, dass die Redundanz funktioniert.

Reicht DNS-Filtering alleine aus oder benötige ich ein Secure Web Gateway?

DNS-Filtering deckt den Bedrohungsschutz und Richtlinien für Inhaltsfilterung für die meisten Gast- und Standortnetzwerke ab, bietet jedoch keine vollständige URL-Prüfung oder Schutz vor Datenverlust (Data Loss Prevention). Es erkennt Domainnamen, aber keine Pfade oder Dateiinhalte. Wenn Sie diese Kontrollen benötigen, ergänzen Sie verwaltete Geräte um ein Secure Web Gateway. Unter DNS filtering vs secure web gateway erfahren Sie, wo die Grenze verläuft.