Sophos DNS Protection: Netzwerk planen und einrichten

Sophos DNS Protection kann entweder einen zentralen DNS-Resolver im Standort schützen oder kompatible Geräte per Secure DNS direkt anbinden. Die wichtigste Entscheidung ist deshalb nicht der Hersteller der Firewall, sondern wo DNS aufgelöst wird, wie interne Zonen erhalten bleiben und woran Sophos den Standort erkennt.

Schnellweg: Für ein verwaltetes Standortnetz bleibt der vorhandene lokale Resolver normalerweise der DNS-Server der Clients. Er leitet nur öffentliche Anfragen an die beiden in Sophos Fusion (ehemals Sophos Central) angezeigten DNS-Protection-IP-Adressen weiter. Interne Zonen gehen weiterhin an die autoritativen internen DNS-Server. Secure DNS eignet sich für verwaltete Einzelgeräte und mobile Benutzer. Beide Wege zuerst mit einer kleinen Pilotgruppe testen und nie einen ungeschützten öffentlichen Resolver als dritten Fallback eintragen.

Zielbild und Verantwortungsgrenze

Der Netzwerkpfad besteht aus vier getrennten Rollen:

Der Client sendet die Anfrage an den per DHCP, VPN, MDM oder lokal vorgegebenen Resolver.
Ein lokaler Resolver entscheidet zwischen internen Zonen und öffentlichen Namen.
Firewall, Router und NAT bestimmen die öffentliche Source-IP und den tatsächlichen Egress.
DNS Protection ordnet die Anfrage einer Location zu, wendet deren Policy an und liefert die Antwort.

Bei Secure DNS sendet das Gerät die Anfrage stattdessen per DNS over HTTPS (DoH) an DNS Protection. Dieser Pfad umgeht den lokalen DNS-Forwarder. Eine Port-53-Umleitung, lokaler Cache und Conditional Forwarding wirken dort nicht.

Dieser Artikel beschreibt die herstellerneutrale Architektur und die Anforderungen an Drittanbieter-Firewalls. Die gerätespezifische Konfiguration steht in Sophos DNS Protection mit Sophos Firewall einrichten.

Voraussetzungen, Lizenz und Rollen

Vor der Netzwerkänderung müssen die vorgesehene Location und der berechtigte Sophos-Fusion-Zugang vorhanden sein. Den Lizenzanspruch vorab prüfen: Standalone DNS Protection gilt mit Xstream Protection, Endpoint DNS Protection setzt dagegen Workspace Protection und Secure DNS voraus. Diese beiden Bereitstellungsmodelle verwenden unterschiedliche Datenpfade und dürfen nicht als austauschbar behandelt werden.

Die Location muss vor der Gerätebereitstellung angelegt werden. Danach verteilt die für die jeweilige Plattform verantwortliche Person die Tenant-Werte anhand der passenden Geräteanleitung und konfiguriert je nach Ziel Windows, macOS oder Windows Server. Verwaltete Windows-Geräte werden an die Person übergeben, die für die Endpoint DNS Protection Policy verantwortlich ist, statt manuelle Profile zu pflegen. Installation, Erneuerung und Entfernung des Vertrauens gehören in den separaten Prozess für das DNS Protection Root Certificate, nicht in diesen Einrichtungsablauf.

Traditional DNS oder Secure DNS wählen

Local resolver oder Firewall forwarder

Diesen Weg wählen, wenn ein Standort bereits einen Router, eine Firewall, Windows DNS oder einen anderen Local resolver verwendet. Der lokale Resolver beziehungsweise Firewall forwarder sendet öffentliche Anfragen per Traditional DNS over IPv4 an Sophos. DNS Protection erkennt die Location an der öffentlichen IPv4-Source-Adresse beziehungsweise am in der Location hinterlegten FQDN.

Vorteile sind zentrale Caches, ein einheitlicher Pfad für viele Gerätetypen und Conditional Forwarding für interne Zonen. Die Grenze: Hinter derselben öffentlichen Source-IP sieht DNS Protection den Standort, aber nicht automatisch jeden Benutzer oder jedes Gerät. Eine wechselnde, geteilte oder falsche Egress-Adresse kann die Zuordnung verhindern.

Manual device DNS oder Secure DNS

Manual device DNS trägt die beiden DNS-Protection-IP-Adressen direkt am Gerät ein. Secure DNS verwendet dagegen DoH über HTTPS und passt zu verwalteten Geräten, Roaming-Clients und Netzen, in denen der lokale Resolver nicht verändert werden kann. Es schützt den Gerätepfad auch ausserhalb des Büros. Interne Namen, VPN-Split-DNS und Anwendungen mit eigenem Resolver müssen jedoch ausdrücklich berücksichtigt werden. Eine manuelle Gerätekonfiguration ist nicht dasselbe wie die verwaltete Workspace-Bereitstellung über eine Endpoint Policy.

Für diesen Pfad die vorgesehene Location öffnen oder anlegen, Secure DNS aktivieren und Save wählen. Sophos Fusion erzeugt danach die standortspezifische DNS over HTTPS URL. Die vollständige URL beziehungsweise das erzeugte Profil der für Windows, macOS oder MDM verantwortlichen Person übergeben. Für Sophos Endpoint erhält die für die Endpoint Policy verantwortliche Person Location und Pilotgruppe, damit sie diese Location in der Policy auswählt. Keine URL selbst zusammensetzen oder aus einer anderen Location übernehmen.

Bewährte Auswahl

Standort mit Active Directory oder internen Zonen: lokaler Resolver mit Conditional Forwarding; nur öffentliche Anfragen an DNS Protection.
Einfaches Netz ohne interne Zonen: DHCP kann die zwei DNS-Protection-Adressen direkt verteilen, sofern die Location die öffentliche Egress-IP kennt.
Verwaltete mobile Geräte: Secure DNS, ergänzt um definierte interne Ausnahmen und VPN-Tests.
Gemischte Umgebung: Standortpfad und Secure DNS parallel betreiben, aber für jede Geräteklasse dokumentieren, welcher Pfad massgeblich ist. Doppeltes Abfangen erschwert die Fehlersuche.

Bestandsaufnahme und Netzwerkfreigaben

Vor der Änderung diese Werte erfassen:

die zwei DNS-Protection-IP-Adressen aus My Products > DNS Protection > Installers im eigenen Tenant;
alle öffentlichen IPv4-Egress-Adressen, die Normalbetrieb, WAN-Failover, SD-WAN, VPN oder zentrale Proxys tatsächlich verwenden;
interne Forward- und Reverse-Zonen, ihre autoritativen Resolver und Suchsuffixe;
DHCP-, VPN- und statisch konfigurierte DNS-Werte pro Netz;
Geräte oder Anwendungen mit eigenem DoH, DoT, VPN oder fest eingetragenem Resolver;
bisherigen Resolver, TTL der DHCP-Optionen, zuständige Personen, Wartungsfenster und Rückweg.

Auf Installers neben IP addresses auf Copy klicken und immer beide angezeigten Adressen übernehmen. Der Download Certificate gehört zum separaten Zertifikatsprozess; für sichtbare HTTPS-Blockseiten muss dieses DNS Protection Root Certificate auf den Geräten vertrauenswürdig sein. Es darf nicht mit einer CA für die HTTPS-Inspection der Firewall verwechselt werden.

Für Traditional DNS müssen beide Tenant-Adressen über UDP 53 und TCP 53 erreichbar sein: im Forwarder-Modus von den freigegebenen lokalen Resolvern, im Direct-Client-Modus nur von den freigegebenen Client- oder Pilotsubnetzen. UDP ist der Normalfall; TCP wird unter anderem für grössere oder abgeschnittene Antworten benötigt. DNS Protection ist ein IPv4-basierter Resolver, kann aber AAAA-Records und damit IPv6-Ziele auflösen. Kein separater ungeschützter IPv6-Resolver darf den geplanten Pfad umgehen.

Für Secure DNS benötigen die Geräte ausgehend TCP 443 zu den von Sophos bereitgestellten DoH-Zielen. HTTPS-Blockseiten benötigen ebenfalls TCP 443 und Erreichbarkeit von blockpage.dnsprotection.sophos.com. Eine TLS-Inspection darf die Verbindung nicht unbemerkt brechen; die konkrete Ausnahme muss eng auf den dokumentierten Sophos-Zielpfad begrenzt werden.

Die Port-53-Regel auf die im Tenant angezeigten Adressen als Ziele begrenzen und die Quellen nach Design trennen: im Forwarder-Modus die vorgesehenen lokalen Resolver, im Direct-Client-Modus die freigegebenen Client- oder Pilotsubnetze. Keine eingehende WAN-Freigabe ist erforderlich. Ein vorgeschalteter DNS-Proxy, Provider-DNS-Redirect oder transparentes Captive Portal kann Antworten verändern und muss im Pilot erkannt werden.

Location, Egress und Redundanz planen

Traditional DNS funktioniert erst, wenn die sichtbare öffentliche Source-IP der Anfrage zu einer Location in Sophos Fusion passt. Private RFC-1918-Adressen gehören nicht in diese Zuordnung. Bei dynamischem Egress kann ein stabiler DDNS-FQDN verwendet werden; er muss öffentlich auf die aktuelle Adresse zeigen. Bei CGNAT oder einer mit anderen Kunden geteilten IP ist eine eindeutige Zuordnung nicht gewährleistet und eine eigene öffentliche IP der saubere Ausweg.

Für Multi-WAN jede mögliche Egress-Adresse inventarisieren und in der passenden Location hinterlegen. Dann kontrolliert umschalten und beide Pfade testen. Policy Routing darf DNS nicht über einen unbekannten Ausgang senden. Überlappen öffentliche IPs zwischen Tenants, hat laut Sophos die zuerst angelegte Zuordnung Vorrang.

Sophos stellt zwei Resolveradressen bereit. Beide als gleichwertiges Primär-/Sekundärpaar konfigurieren. Ein dritter öffentlicher Resolver ist keine Redundanz, sondern ein Bypass: Resolver wählen Ersatzserver nicht immer erst bei einem vollständigen Ausfall und können parallel den schnellsten verwenden. Echte Ausfallsicherheit umfasst zusätzlich zwei lokale Resolver, redundante DHCP-/VPN-Verteilung und einen geprüften WAN-Failover-Pfad.

Herstellerneutraler Einrichtungsablauf

In Sophos Fusion unter My Products > DNS Protection > Network setup den passenden Zweig für Local resolver, Firewall forwarder, Windows DNS, Manual device DNS oder Secure DNS bestimmen. Danach die vorgesehene Location und Verbindungsmethode bestätigen. Bei Traditional DNS müssen alle produktiven öffentlichen Egress-Adressen bekannt sein.
Für Traditional DNS unter My Products > DNS Protection > Installers beide Resolveradressen aus dem eigenen Tenant kopieren. Keine Beispielwerte oder Adressen eines anderen Tenants verwenden.
Für Secure DNS die Location anlegen oder bearbeiten, Secure DNS aktivieren, Save wählen und die erzeugte standortspezifische DNS over HTTPS URL kopieren. Genau diese URL beziehungsweise das erzeugte Profil der für Windows, macOS oder MDM verantwortlichen Person übergeben. Die für die Sophos Endpoint Policy verantwortliche Person erhält Location und Pilotgruppe, damit sie diese Location in der Endpoint Policy auswählt.
Im Forwarder-Modus beide Sophos-Adressen als einzige Forwarder für öffentliche Anfragen auf dem lokalen Resolver oder der Drittanbieter-Firewall eintragen: eine als Primary DNS server, die andere als Secondary DNS server. Conditional Forwarder oder Stub-Zonen für interne Forward- und Reverse-Zonen erhalten. Bietet das Produkt einen dritten DNS-Server an, dort keinen fremden öffentlichen Resolver ergänzen, weil ein Wechsel darauf den Schutz umgeht.
Die Egress-Firewall-Regel nach Design trennen: im Forwarder-Modus UDP/TCP 53 nur von autorisierten lokalen Resolvern zu beiden Sophos-Adressen erlauben; im Direct-Client-Modus nur von freigegebenen Pilot- oder Client-Subnetzen zu beiden Adressen. Port 53 gemäss dokumentiertem Bypass-Design für alle anderen Quellen sperren.
Für Secure DNS TCP 443 nur von freigegebenen Geräten zum erzeugten DoH-Ziel und zum erforderlichen Blockseitenziel erlauben. Ausnahmen von der TLS-Inspection eng begrenzen.
Im Forwarder-Modus DHCP- und VPN-Scopes des Piloten auf den lokalen Resolver umstellen. Im Direct-Client-Modus beide Sophos-Adressen an das freigegebene Pilotsubnetz verteilen. Statische Geräte separat inventarisieren.
Die erzeugte Secure-DNS-URL beziehungsweise das Profil durch die für Windows, macOS oder MDM verantwortliche Person nur an die Pilotgruppe verteilen lassen. Für Sophos Endpoint wählt die für die Policy verantwortliche Person die übergebene Location in der Endpoint Policy aus und weist diese Policy der übergebenen Pilotgruppe zu. Location, Policy, Gruppe und Entfernungsmethode dokumentieren.
Cache und bestehende Leases nur im Pilot kontrolliert erneuern. Ein globales Cache-Flushing erzeugt unnötige Last und erschwert den Vergleich.
Erst nach erfolgreicher Validierung alternative DNS-Pfade einschränken.

Grenzen des Umgehungsschutzes

Klassisches DNS lässt sich begrenzen, indem ausgehendes UDP/TCP 53 im Forwarder-Modus nur für autorisierte lokale Resolver oder im Direct-Client-Modus nur für freigegebene Client- oder Pilotsubnetze erlaubt wird. Eine Umleitung fremder Port-53-Ziele auf den eigenen Resolver kann bei schlecht verwaltbaren Geräten helfen, muss aber interne DNS-Server, VPNs, Gastnetze und Geräte mit fest erwarteten Resolvern ausnehmen. Blockieren ist transparenter als Umleiten, sofern die Clients administrierbar sind.

Diese Kontrolle erfasst kein DoH auf TCP 443, kein DoT auf TCP 853 und keine Namensauflösung innerhalb eines fremden VPN-Tunnels. Nicht pauschal TCP 443 sperren. Browser-, Betriebssystem-, MDM- und Endpoint-Richtlinien müssen nicht genehmigtes Secure DNS kontrollieren; bekannte DoT-Nutzung kann gezielt behandelt werden. Apple Private Relay und ähnliche Privacy-Dienste sind ebenfalls eine eigene Designentscheidung.

Wenn nur iPhone-Geräte trotz funktionierender Auflösung auf anderen Geräten keinen Internetzugriff erhalten, Limit IP Address Tracking für das betroffene Netz testweise ausschalten und erneut prüfen. Diese Änderung bewusst auf Pilotgeräten vornehmen, weil sie eine Datenschutzfunktion des Geräts betrifft.

Umgehungsschutz endet an der administrativen Grenze. In einem BYOD- oder Gastnetz ist eine dokumentierte, weniger strikte Policy oft belastbarer als der Versuch, jeden verschlüsselten Resolver ohne Geräteverwaltung zu erzwingen.

Pilot, Validierung und Abnahme

Mit einem repräsentativen VLAN oder wenigen Geräten beginnen. Mindestens öffentliche Namen, interne FQDNs, Reverse-Lookups, VPN, Gastzugang, WAN-Failover und eine harmlose Testblockierung prüfen.

Vor der Änderung ein Beobachtungsfenster und eindeutige Rückbaukriterien festlegen. Den Pilot zurückrollen, wenn interne oder VPN-Auflösung ausfällt, die falsche Location oder Policy erscheint, DoH/TLS dauerhaft instabil ist oder ein benötigtes Geschäftsziel gestört wird; solange ein Auslöser offen ist, nicht erweitern.

nslookup example.com <resolver-ip>
nslookup internal-host.corp.example <resolver-ip>

Mit installiertem dig:

dig @<resolver-ip> example.com A
dig @<resolver-ip> example.com AAAA
dig @<resolver-ip> internal-host.corp.example
dig +tcp @<resolver-ip> example.com

<resolver-ip> durch den lokalen Resolver oder bei direkter Nutzung durch eine Tenant-Adresse ersetzen. corp.example ist eine Dokumentationszone und muss durch die eigene interne Zone ersetzt werden. Der TCP-Test bestätigt, dass nicht nur UDP funktioniert.

Danach die unter Installers > Check your configuration kopierte Test-URL im Browser öffnen. Die Welcome-Meldung bestätigt den DNS-Protection-Pfad, aber nicht allein die richtige Policy. Zusätzlich eine ungefährliche Testdomain gezielt blockieren und in Sophos Fusion prüfen, ob Anfrage, Location und Policy wie erwartet erscheinen. Reporting ist nicht zwingend in Echtzeit; daher nicht unmittelbar nach einer einzelnen Anfrage einen Fehler ableiten.

Abnahme bedeutet:

beide Sophos-Resolver funktionieren einzeln über UDP und TCP;
interne Forward- und Reverse-Zonen bleiben intern;
der erwartete Egress wird der richtigen Location zugeordnet;
Blockierung und erlaubte Geschäftsziele funktionieren;
WAN-Failover, VPN und IPv6-fähige Clients erzeugen keinen Nebenpfad;
nicht autorisiertes Port-53-DNS ist gemäss Design blockiert oder umgeleitet;
manuelle Secure-DNS-Piloten für Windows, macOS und MDM verwenden exakt die erzeugte URL beziehungsweise das Profil, während Sophos-Endpoint-Piloten einer Policy mit der vorgesehenen Location zugewiesen sind; beide erscheinen unter der vorgesehenen Location und Policy und bestehen Tests im Büro, beim Roaming, über VPN, für interne Domains sowie beim Entfernen;
Monitoring und ein getesteter Rückweg sind dokumentiert.

Betrieb und regelmässige Prüfung

Nach dem Pilot in Wellen nach Standort oder VLAN ausrollen. Pro Welle DNS-Fehler, Helpdesk-Meldungen, blockierte Geschäftsdomains und Egress-Zuordnung beobachten. Statische Server und OT-/IoT-Geräte zuletzt und in einem eigenen Wartungsfenster umstellen.

Nach Änderungen an WAN, NAT, DHCP, VPN, IPv6 oder lokalen Resolvern den DNS-Pfad erneut prüfen. Dasselbe gilt bei einem Wechsel des Providers oder einer neuen öffentlichen Egress-Adresse. Regelmässig kontrollieren, ob weiterhin beide Tenant-Resolver eingetragen sind, interne Zonen lokal aufgelöst werden und kein zusätzlicher DNS-Server den Schutz umgeht. Produktmeldungen unter My Environment > Alerts und den Zustand unter My Products > DNS Protection in den Betriebsprozess aufnehmen.

Sicherer Rückweg oder Ausserbetriebnahme

Für den Rückweg zuerst neue Regeln zur DNS-Blockierung oder -Umleitung deaktivieren. Danach den zur Bereitstellung passenden Zweig ausführen:

Forwarder-Modus: Die dokumentierten bisherigen Forwarder am lokalen Resolver aktiv wiederherstellen. Anschliessend die interne und öffentliche Auflösung prüfen.
Direct-Client-Modus: Die dokumentierten früheren DNS-Werte in DHCP, VPN und statischen Clients wiederherstellen. Die Leases auf Testgeräten erneuern und danach die interne und öffentliche Auflösung prüfen.
Secure DNS: Die für Windows, macOS oder MDM verantwortliche Person entfernt das Pilotprofil; die für die Sophos Endpoint Policy verantwortliche Person entfernt dagegen die Zuweisung der Pilotgruppe. Danach den vorherigen DNS-Zustand wiederherstellen und prüfen, dass der DoH-Pfad nicht mehr genutzt wird.

Conditional Forwarder und Sophos-Fusion-Location zunächst bestehen lassen, sofern nicht die Location selbst den Vorfall verursacht hat.

Troubleshooting nach Symptom

Öffentliche Namen lösen gar nicht auf

Zuerst explizit beide Sophos-Adressen über UDP und TCP testen. Danach Egress-Regel, NAT, Route und sichtbare öffentliche Source-IP prüfen. Ist die Source-IP keiner Location zugeordnet oder kollidiert sie mit einem anderen Tenant, kann DNS Protection Anfragen ablehnen. Bei DDNS zusätzlich die öffentliche Auflösung des FQDN kontrollieren.

Interne Namen oder Active Directory fallen aus

Prüfen, welchen Resolver der Client tatsächlich verwendet. Danach Conditional Forwarder, autoritative Zielserver, Reverse-Zonen, Suchsuffixe und VPN-Split-DNS kontrollieren. Ein direkt verteilter DNS-Protection-Resolver kennt keine privaten Zonen.

Nur grosse Antworten oder einzelne Domains scheitern

TCP 53 testen. Funktioniert UDP, aber dig +tcp nicht, fehlt meist die TCP-Freigabe oder ein Zwischenprodukt verwirft die Verbindung. Bei einer erlaubten, trotzdem blockierten Domain auch CNAME-Ziel und Sicherheitsklassifizierung prüfen.

Sophos Fusion zeigt keine oder die falsche Location

Tatsächlichen Egress statt nur die konfigurierte WAN-Adresse ermitteln. SD-WAN, zentrale NAT-Gateways, Proxys und Failover können die Source-IP ändern. Anschliessend ausreichend Zeit für Reports lassen und prüfen, ob der Test wirklich den geplanten Resolver statt Browser-DoH oder VPN verwendet hat.

Bei einer per FQDN definierten Location zusätzlich die öffentliche Auflösung prüfen. Für einen Cloudflare-DNS-Eintrag muss Proxy status: DNS only gelten; ein proxied Eintrag liefert nicht die tatsächliche öffentliche Egress-Adresse. Eine private oder IPv6-Adresse ist keine gültige Location-Adresse. Ist derselbe öffentliche Wert bereits einem anderen Kunden zugeordnet oder ist der FQDN ungültig, die Zuordnung bereinigen, bevor der Rollout weitergeht.

Blockseite fehlt, DNS-Blockierung funktioniert aber

Das ist kein Beweis für eine erlaubte Domain. Erreichbarkeit von blockpage.dnsprotection.sophos.com, Vertrauen in das DNS Protection Root Certificate, Pharming Protection, Webproxy beziehungsweise Webfilter und TLS-Inspection prüfen. Falls die Firewall den Blockseitenpfad entschlüsselt, die eng begrenzte Aktion Do not decrypt für den dokumentierten Sophos-Zielpfad verwenden. Zertifikatsinstallation und -entfernung immer über den verantwortlichen Plattformprozess steuern.

Eine erlaubte Domain bleibt blockiert

Zuerst den CNAME-Zielnamen und dessen Kategorie prüfen: Eine erlaubte Ausgangsdomain kann weiterhin auf einen wegen Kategorie oder Threat Score blockierten Namen zeigen. Nach einer Policy-Änderung ausserdem die DNS-TTL und lokale Caches abwarten beziehungsweise kontrolliert erneuern. Den Rollout nicht durch pauschale breite Ausnahmen beschleunigen.

Die Umgehungssperre wirkt nicht

Protokolle nach ausgehendem UDP/TCP 53, TCP 853 und bekannten Secure-DNS-Verbindungen durchsuchen. Danach Browser, Betriebssystem, VPN und lokale Sicherheitssoftware prüfen. Ein Port-53-Filter kann verschlüsseltes DNS auf 443 nicht nachweisen oder verhindern.

DNS wird aufgelöst, aber Policy und Reports fehlen

Zuerst mit ipconfig, nslookup oder unter Linux und macOS mit dig prüfen, welche Resolver das Gerät tatsächlich verwendet. Danach einen Standard- oder Extended-Test auf https://www.dnsleaktest.com/ ausführen. Bei Nutzung von DNS Protection enthalten alle Werte in der Spalte Hostname das Muster gw-<nummer>.<region>.dnsprotection.sophos.com; als ISP erscheint Amazon oder eine entsprechende Bezeichnung. Andere Resolver weisen auf ein DNS-Leak oder eine Umleitung durch den ISP hin.

Wenn https://dns.access.sophos.com statt der Welcome-Seite einen Browserfehler zeigt, gleichzeitig im Dashboard No queries received from locations erscheint oder eine Sophos Firewall DNS Protection: Connectivity Error meldet, zuerst den abweichenden Resolverpfad beseitigen. Dazu Router-DNS, DHCP und DHCPv6, statische DNS-Einträge, Provider-Umleitung und parallele IPv6-Resolver kontrollieren. Erst danach Policy oder Reporting untersuchen; dieser Prüfweg gilt für den Netzwerkpfad, nicht ungeprüft für Endpoint DoH.