Sophos DNS Protection Locations sicher verwalten

Eine Location sagt Sophos DNS Protection, zu welchem Standort, Netzwerk oder Gerätesatz eine DNS-Anfrage gehört. Erst diese Zuordnung macht standortbezogene Filtering Policies und aussagekräftige Reports möglich. Für einen stabilen Betrieb sollte eine Location den Internet-Egress abbilden, nicht jedes interne VLAN.

Der vollständige Ablauf beginnt unter My Products > DNS Protection > Locations: Verbindungsmethode wählen, Location anlegen, die Zuordnung auf der Seite Policies prüfen, den realen DNS-Pfad testen und erst danach alte IP-Adressen oder Locations entfernen. Die Default location ist dabei ein unveränderbarer Secure-DNS-Ausgangspunkt; eigene Locations bilden Standorte, Regionen oder getrennte Policy-Gruppen ab.

Entscheidung: Default oder eigene Location

Die vordefinierte Default location verwendet Secure DNS und funktioniert ohne erfasste öffentliche Standortadresse. Sie kann sowohl einer Endpoint policy als auch einer Filtering policy zugeordnet werden. Man kann ihre Details unter My Products > DNS Protection > Locations > Default anzeigen, sie aber weder bearbeiten noch löschen.

Eine eigene Location ist sinnvoll, wenn mindestens einer dieser Punkte gilt:

• Eine Firewall, ein Router oder ein lokaler DNS-Resolver sendet klassische DNS-Anfragen.
• Standorte oder Gerätegruppen benötigen unterschiedliche Filtering Policies.
• Reports sollen DNS-Anfragen nach Region oder Internet-Egress trennen.
• Für Endpoint-Geräte wird eine eigene Secure-DNS-Zuordnung statt Default benötigt.

DNS Protection erlaubt höchstens 50 Locations. Eine eigene Location kann Secure DNS, Traditional DNS over IPv4 oder beide Methoden verwenden. Pro Location lassen sich höchstens 100 öffentliche IPv4-Adressen oder FQDNs erfassen.

Verbindungsmethode passend wählen

Secure DNS

Secure DNS transportiert DNS über HTTPS. Diese Methode passt zu kompatiblen Geräten und ist für Sophos Endpoint mit DNS Protection zwingend. Beim Speichern erzeugt Central eine individuelle DNS over HTTPS URL. Sophos Endpoint konfiguriert verwaltete Geräte automatisch; bei einer manuellen Gerätekonfiguration wird die URL benötigt.

Für diese Bereitstellung müssen genau die beiden von Central angezeigten DNS-Protection-IPv4-Adressen verwendet und kopiert werden.

Traditional DNS over IPv4

Traditional DNS over IPv4 sendet DNS unverschlüsselt an die DNS-Protection-Resolver. Diese Methode passt zu Firewalls, Routern und lokalen DNS-Servern. DNS Protection erkennt die Location an der öffentlichen Quell-IP. Deshalb werden die öffentliche WAN-Adresse, ein öffentlicher Bereich oder ein FQDN erfasst, der auf diese Adresse zeigt – niemals eine interne RFC-1918-Adresse.

Die vollständige Firewall-Konfiguration mit Forwardern, internen Zonen und DHCP gehört in die separate Anleitung zu Sophos DNS Protection mit Sophos Firewall. Die Location allein ändert noch keinen DNS-Pfad im Netzwerk.

Beide Methoden

Beide Schalter dürfen in derselben eigenen Location aktiv sein. Das ist nützlich, wenn derselbe Policy-Kontext sowohl verwaltete Endpoints per DoH als auch einen Standortresolver per klassischem DNS umfasst. Vorher sollte bewusst entschieden werden, ob diese beiden Pfade tatsächlich dieselbe Filterung und dieselben Reports erhalten sollen.

Voraussetzungen und Adressplan

Vor dem Anlegen notiert man:

• einen eindeutigen Namen, eine kurze Beschreibung und die technisch verantwortliche Person,
• die gewünschte Verbindungsmethode,
• alle öffentlichen Egress-Adressen bei Multi-WAN, SD-WAN und Failover,
• einen gepflegten DDNS-FQDN bei dynamischer öffentlicher Adresse,
• die vorgesehene Filtering policy sowie gegebenenfalls die Endpoint policy,
• ein direkt angebundenes Testgerät pro DNS-Pfad.

Default ist als Name reserviert. Für Beispiele eignet sich ZH-HQ-Egress; die Beschreibung kann Anbieter, WANs und die verantwortliche Person enthalten. Ein Standortname sollte stabil bleiben, auch wenn der Anbieter wechselt.

Für Änderungen an DNS Protection benötigt man in Sophos Fusion eine entsprechende Administrationsrolle. Ein schreibgeschützter Zugang eignet sich zur Kontrolle, nicht zum Anlegen, Bearbeiten oder Löschen. Die manuelle Erfassung einer öffentlichen IP-Adresse oder eines FQDNs weist keine Berechtigung zur Nutzung des Dienstes nach.

Eigenständiges beziehungsweise netzwerkbasiertes DNS setzt mindestens eine gültige, mit Central verknüpfte Firewall mit Xstream Protection voraus. Verwaltetes Endpoint DNS ist dagegen eine Workspace-Funktion; Xstream allein reicht dafür nicht aus. Add known IPs erkennt nur öffentliche Adressen lizenzierter Sophos Firewalls mit Xstream Protection. Secure DNS setzt ein Gerät voraus, das DNS über HTTPS verarbeiten kann; Sophos Endpoint verlangt für DNS Protection ausdrücklich diese Verbindungsmethode.

Eigene Location anlegen

1. My Products > DNS Protection > Locations > Add location öffnen. In der Locations-Liste führt der Button Add zu diesem Dialog.
2. Unter Location name einen eindeutigen Namen und unter Description den Zweck erfassen.
3. Unter Connection method Secure DNS, Traditional DNS over IPv4 oder beide aktivieren.
4. Bei Secure DNS die angezeigten IPv4-Adressen notieren. Die DNS over HTTPS URL wird erst mit Save erzeugt.
5. Bei Traditional DNS over IPv4 unter IPv4 addresses or FQDNs die öffentlichen Werte hinzufügen. Jeden einzelnen Eintrag mit Enter oder Tab bestätigen. Beim Einfügen mehrerer Werte muss zwischen ihnen ein Zeilenumbruch stehen.
6. Save wählen.
7. Bei Secure DNS die erzeugte DNS over HTTPS URL kopieren und sicher ablegen, bevor man Close wählt.

Erkannte Adressen übernehmen

Mit Add known IPs zeigt Central Vorschläge:

• Your Current Location ist die Adresse, von der die aktuelle Central-Sitzung kommt. Bei einer VPN-Sitzung ist das die öffentliche Adresse des VPN-Servers und möglicherweise nicht die gesuchte Standortadresse.
• Your Firewalls zeigt die Adresse, über die eine lizenzierte Sophos Firewall Central erreicht. Automatisch erkannt werden nur Firewalls mit Xstream Protection.

Ein erkannter Wert ist nur ein Vorschlag. DNS Protection aktualisiert ihn bei späteren Adresswechseln nicht automatisch. Bei Multi-WAN müssen nicht erkannte Egress-Adressen manuell ergänzt werden.

IP, FQDN, Multi-WAN und DDNS

Für eine feste Leitung ist die öffentliche IPv4-Adresse meist die klarste Wahl. Bei Multi-WAN werden alle Adressen erfasst, über die DNS-Anfragen tatsächlich austreten können; alternativ kann ein passender öffentlicher Bereich verwendet werden. Fehlt die Failover-Adresse, funktioniert DNS Protection nach dem Leitungswechsel nicht für diese Location.

Bei einer dynamischen Adresse wird ein FQDN eines Drittanbieter-DDNS-Dienstes eingetragen. Der DDNS-Client muss den Record zuverlässig aktualisieren. Verwendet man dafür Sophos Firewall, erklärt Dynamic DNS auf Sophos Firewall einrichten und prüfen die Konfiguration unter Network > Dynamic DNS > Add. DNS Protection prüft Adressänderungen jede Minute und benötigt anschliessend acht Sekunden, um seinen Cache zu aktualisieren. Während Provider-, DDNS- und Cache-Aktualisierung kann die Namensauflösung kurz ausfallen.

Unterstützt werden DynDNS, DynAccess, EasyDNS, ZoneEdit, Google DDNS, Namecheap, DNS-O-Matic, No-IP, FreeDNS und Cloudflare. Bei Cloudflare muss Proxy status auf DNS only stehen; ein proxied Record liefert Cloudflare-Adressen statt der öffentlichen Egress-IP.

CGNAT und Adresskonflikte

Traditional DNS benötigt eine eindeutige öffentliche Quell-IP. Bei CGNAT sowie gemeinsam genutzten Provider-, Proxy- oder VPN-Egress-Adressen kann dieselbe IP in mehreren Kundenkonten auftauchen. DNS Protection gibt dem Benutzer Vorrang, der die Location zuerst angelegt hat. Ein anderer FQDN hilft nicht, wenn er auf dieselbe geteilte IP zeigt.

Die belastbare Lösung ist eine eindeutige öffentliche Adresse vom Provider oder Secure DNS für kompatible Geräte. Private Adressen wie 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16 identifizieren den Internet-Egress nicht und gehören nicht in die Location.

Policy-Zuordnung vollständig machen

Eine Location allein erlaubt zwar die Zuordnung eingehender DNS-Anfragen, definiert aber noch nicht die gewünschte Filterung.

• Unter My Products > DNS Protection > Policies > Filtering policies wird die Location von Available nach Assigned to this policy verschoben. Einer Location kann nur eine Filtering policy zugeordnet sein.
• In einer Endpoint policy wird den ausgewählten Windows-Geräten eine Location zugewiesen. Diese muss Secure DNS verwenden; Default location ist dafür ebenfalls zulässig.

Der Endpoint-Pfad, interne Domain Exclusions und die Agent-Komponente gehören in die separate Endpoint-Anleitung. Eine Endpoint-Zuweisung ersetzt keine Filtering policy: Die erste bestimmt, welche Geräte die Location verwenden, die zweite bestimmt deren Domain- und Kategoriebehandlung.

Location bearbeiten

Vor jeder Änderung zuerst Name, Methoden, IP-/FQDN-Liste, DoH-Verwendung und beide Policy-Zuordnungen dokumentieren. Dann unter My Products > DNS Protection > Locations die eigene Location öffnen, die Werte anpassen und mit Save speichern.

Bei einer Egress-Migration ist der sichere Ablauf:

1. Neue öffentliche Adresse zusätzlich zur alten Adresse erfassen.
2. Warten, bis der neue Internetpfad aktiv ist.
3. DNS-Auflösung und Policy-Treffer über den neuen Pfad prüfen.
4. Erst danach die alte Adresse entfernen.

Bei einem Wechsel von Traditional DNS zu Secure DNS wird zuerst der DoH-Pfad auf einer Pilotgruppe eingerichtet und validiert. Traditional DNS bleibt bis zum erfolgreichen Test aktiv. Das vermeidet eine ungetestete Umstellung und ermöglicht eine schnelle Rückkehr zum bisherigen Pfad.

Validierung nach Anlage oder Änderung

1. Unter My Products > DNS Protection > Locations prüfen, ob Location, Description und die angezeigte Anzahl unter IP addresses/FQDNs stimmen.
2. Die Location öffnen und in ihren Details kontrollieren, ob die vorgesehene Connection method und die erwarteten IP-/FQDN-Werte hinterlegt sind.
3. Unter Policies kontrollieren, dass die Location in der vorgesehenen Filtering policy und gegebenenfalls Endpoint policy zugeordnet ist.
4. Eine nachweislich erlaubte Domain und eine bewusst durch die zugewiesene Policy blockierte Testdomain aus genau dem betroffenen DNS-Pfad auflösen. Cache und DNS-TTL berücksichtigen.
5. In Dashboard beziehungsweise Reports prüfen, ob die Anfrage unter der erwarteten Location erscheint.

Eine erfolgreiche Namensauflösung allein belegt weder die richtige Policy noch die richtige Location. Erst die Kombination aus positivem Test, blockiertem Test und passendem Report-Eintrag bestätigt den vollständigen Pfad. Fehlt die Anfrage, wird zuerst die tatsächliche öffentliche Quell-IP mit IP addresses/FQDNs verglichen; bei einem ungültigen FQDN oder IP-Konflikt prüft man als Nächstes My Environment > Alerts.

Fehlersuche nach Symptom

Location akzeptiert die Adresse nicht

Statische Einträge und Hostnamen werden nur für IPv4 unterstützt. Eine private oder IPv6-Adresse ist kein gültiger Standort-Egress. Die öffentliche WAN-Adresse oder einen FQDN eintragen, der darauf auflöst, und jeden Wert mit Enter oder Tab abschliessen.

Auflösung stoppt oder Location erscheint nicht in Reports

Den realen Egress mit der gespeicherten IP-/FQDN-Liste vergleichen. Bei Multi-WAN kann eine nicht erfasste Failover-Adresse aktiv sein. Bei FQDN zuerst prüfen, ob er auf eine gültige öffentliche IPv4-Adresse auflöst. Fehlerhafte FQDNs und IP-Konflikte meldet Central unter My Environment > Alerts.

IP-Konflikt oder CGNAT

Wenn dieselbe öffentliche IP bereits zu einem anderen Kunden gehört, bleibt die zuerst angelegte Location vorrangig. Ein Alias auf dieselbe IP ändert nichts. Beim Anbieter eine eindeutige öffentliche IPv4-Adresse bestellen oder für geeignete Geräte Secure DNS einsetzen.

DDNS-Ausfall nach Adresswechsel

Prüfen, ob der DDNS-Record bereits die neue öffentliche Adresse liefert. Danach mindestens den Aktualisierungszyklus von DNS Protection und die Cache-Aktualisierung berücksichtigen. Bei Cloudflare DNS only kontrollieren. Die alte IP erst entfernen, wenn der neue Wert und der reale Egress übereinstimmen.

Policy wirkt nicht

Prüfen, welcher Location die Anfrage tatsächlich zugeordnet wurde und welcher Filtering policy diese Location angehört. Pro Location gilt nur eine Filtering policy. Nach einer Policy-Änderung kann ein bereits gecachter DNS-Eintrag bis zum Ablauf seines TTL weiter funktionieren; deshalb mit einem frischen Testnamen oder nach Cache-Ablauf erneut testen.

Andere Resolver umgehen DNS Protection

Wenn Clients zusätzliche klassische oder IPv6-DNS-Server erhalten, können Abfragen DNS Protection umgehen. Für öffentliche Auflösung ausschliesslich den geplanten DNS-Protection-Pfad verteilen. DNS Protection ist IPv4-basiert, kann aber auch AAAA-Records auflösen; ein separater IPv6-Resolver ist dafür nicht nötig.

Betrieb und Lebenszyklus

Die Locations sollten nach einem Anbieter-, WAN-, DDNS- oder Policy-Wechsel sowie regelmässig im Betrieb geprüft werden. In der Liste vergleicht man Location, Description und die Anzahl unter IP addresses/FQDNs mit dem dokumentierten Sollzustand. Die Connection method prüft man in den Details der Location, die Zuordnung auf der Seite Policies. Automatisch vorgeschlagene Adressen sind keine dauerhafte Synchronisierung: Ändert sich eine zuvor erkannte IP-Adresse, muss man die Location oder den gepflegten DDNS-Namen anpassen und erneut validieren.

Für operative Schritte sind die aktuellen Hilfeseiten massgebend. Versionshinweise ordnen Änderungen wie automatisch vorgeschlagene IP-Adressen, die Kopierfunktion für IP-Adressen und FQDNs oder die Anzeige zugeordneter Locations in Policies zeitlich ein; sie ersetzen keine aktuelle Konfigurationsanleitung. Mit Stand vom 24. September 2026 enthalten die aktuellen Hilfeseiten und Versionshinweise kein konkretes Datum für die Ausserbetriebnahme von DNS Protection.

Eigene Location sicher löschen

Die Default location kann nicht gelöscht werden. Für eine eigene Location gilt folgende Reihenfolge:

1. Name, Beschreibung, aktivierte Verbindungsmethoden, IP-/FQDN-Werte, Policy-Zuordnungen und bestehende DoH-URL sichern. Ausserdem alle Firewalls, Resolver und manuell konfigurierten Geräte dokumentieren, welche die Location verwenden.
2. Falls der DNS-Pfad weiter benötigt wird, eine Ersatz-Location anlegen und konfigurieren. Das darf nur parallel zur alten Location geschehen, wenn die Ersatz-Location eine eigene, eindeutig routbare Identität oder einen neu bereitgestellten Secure-DNS-Pfad verwendet.
3. Wird eine Ersatz-Location verwendet, diese den vorgesehenen Filtering- und Endpoint-Policies zuordnen. Danach zuerst einen kontrollierbaren Pilotpfad auf die Ersatz-Location umstellen, etwa Pilotgeräte, einen Resolver oder – soweit betrieblich möglich – eine Firewall.
4. Bei einer Ersatz-Location über den Pilotpfad eine erlaubte und eine durch die zugewiesene Policy blockierte Domain auflösen. In den Reports prüfen, ob beide Anfragen der Ersatz-Location zugeordnet sind. Nur nach erfolgreicher Prüfung die übrigen Firewalls, Resolver und manuell konfigurierten Geräte umstellen. Entfällt der DNS-Pfad ersatzlos, stattdessen seine Nutzung auf allen dokumentierten Systemen beenden. Anschliessend die alte Location aus den bisherigen Policies entfernen und kontrollieren, dass sie nicht mehr verwendet wird.
5. Erst jetzt unter My Products > DNS Protection > Locations die alte Location auswählen und Delete wählen.
6. Bei einer Ersatz-Location über den neuen Pfad die erlaubte und blockierte Auflösung sowie die Zuordnung in den Reports erneut prüfen. Bei ersatzlosem Rückbau kontrollieren, dass die verbleibenden DNS-Pfade wie vorgesehen funktionieren.

Soll eine Traditional-DNS-Ersatz-Location dieselbe öffentliche Identität verwenden und deshalb nicht eindeutig neben der alten Location bestehen können, muss man vor Delete stoppen. Die geplante Umstellung und das Konfliktrisiko sind zu dokumentieren; die Löschung darf erst für den bewusst freigegebenen Wechsel ausgeführt werden. Die Ersatz-Location gilt in diesem Fall ausdrücklich nicht als parallel validiert.

Eine Neuerstellung mit dem gesicherten Namen, der Beschreibung, den Methoden, IP-/FQDN-Werten und Policy-Zuordnungen ist nur ein bestmöglicher Wiederherstellungsversuch, keine garantierte Rückkehr zum vorherigen Zustand. Bei einer umstrittenen öffentlichen Traditional-DNS-Identität stellt sie insbesondere den Vorrang der zuerst angelegten Location nicht verlässlich wieder her. Bei Secure DNS erzeugt die Neuerstellung eine neue DNS over HTTPS URL; diese muss erneut auf allen manuell konfigurierten Geräten verteilt werden. Soweit zutreffend, Firewalls und Resolver wieder mit dem traditionellen Pfad verbinden. Danach erlaubte und blockierte Auflösung sowie Reports erneut testen.