Sophos DNS Protection Locations veilig beheren

Een Location geeft aan Sophos DNS Protection door bij welke vestiging, welk netwerk of welke groep apparaten een DNS-query hoort. Alleen met deze koppeling zijn locatiespecifieke Filtering policies en zinvolle rapporten mogelijk. Voor een stabiele werking moet een Location de internetuitgang vertegenwoordigen, niet elk intern VLAN.

De volledige procedure begint onder My Products > DNS Protection > Locations: kies de verbindingsmethode, maak de Location, controleer de toewijzing op de pagina Policies, test het werkelijke DNS-pad en verwijder pas daarna oude IP-adressen of Locations. De Default location is daarbij een onveranderlijk uitgangspunt voor Secure DNS; aangepaste Locations vertegenwoordigen vestigingen, regio’s of afzonderlijke policygroepen.

Kiezen tussen Default en een aangepaste Location

De vooraf gedefinieerde Default location gebruikt Secure DNS en werkt zonder geregistreerd openbaar vestigingsadres. Deze kan zowel aan een Endpoint policy als aan een Filtering policy worden toegewezen. U kunt de details bekijken onder My Products > DNS Protection > Locations > Default, maar de Location niet wijzigen of verwijderen.

Een aangepaste Location is zinvol als ten minste een van de volgende punten van toepassing is:

• Een firewall, router of lokale DNS-resolver verstuurt traditionele DNS-query’s.
• Vestigingen of apparaatgroepen hebben verschillende Filtering policies nodig.
• Rapporten moeten DNS-query’s per regio of internetuitgang uitsplitsen.
• Endpoint-apparaten hebben een eigen Secure DNS-toewijzing nodig in plaats van Default.

DNS Protection staat maximaal 50 Locations toe. Een aangepaste Location kan Secure DNS, Traditional DNS over IPv4 of beide methoden gebruiken. Per Location kunnen maximaal 100 openbare IPv4-adressen of FQDN’s worden geregistreerd.

De juiste verbindingsmethode kiezen

Secure DNS

Secure DNS transporteert DNS via HTTPS. Deze methode is geschikt voor compatibele apparaten en is verplicht voor Sophos Endpoint met DNS Protection. Bij het opslaan genereert Central een unieke DNS over HTTPS URL. Sophos Endpoint configureert beheerde apparaten automatisch; voor handmatige apparaatconfiguratie is de URL vereist.

Voor deze implementatie moeten exact de twee door Central weergegeven IPv4-adressen van DNS Protection worden gebruikt en gekopieerd.

Traditional DNS over IPv4

Traditional DNS over IPv4 verstuurt DNS onversleuteld naar de DNS Protection-resolvers. Deze methode is geschikt voor firewalls, routers en lokale DNS-servers. DNS Protection herkent de Location aan het openbare bron-IP-adres. Daarom registreert u het openbare WAN-adres, een openbaar bereik of een FQDN dat naar dit adres verwijst, en nooit een intern RFC 1918-adres.

De volledige firewallconfiguratie met forwarders, interne zones en DHCP staat in de afzonderlijke handleiding voor Sophos DNS Protection met Sophos Firewall. Alleen de Location verandert nog geen DNS-pad in het netwerk.

Beide methoden

Beide opties kunnen in dezelfde aangepaste Location actief zijn. Dit is nuttig wanneer dezelfde policycontext zowel via DoH beheerde endpoints als een vestigingsresolver met traditioneel DNS omvat. Bepaal vooraf bewust of deze twee paden daadwerkelijk dezelfde filtering en dezelfde rapporten moeten krijgen.

Vereisten en adresplan

Leg voordat u de Location maakt het volgende vast:

• een unieke naam, een korte beschrijving en de technisch verantwoordelijke persoon,
• de gewenste verbindingsmethode,
• alle openbare uitgaande adressen voor multi-WAN, SD-WAN en failover,
• een goed onderhouden DDNS-FQDN voor een dynamisch openbaar adres,
• de beoogde Filtering policy en, indien van toepassing, de Endpoint policy,
• een rechtstreeks verbonden testapparaat per DNS-pad.

Default is als naam gereserveerd. ZH-HQ-Egress is een geschikt voorbeeld; de beschrijving kan de provider, WAN-verbindingen en de verantwoordelijke persoon vermelden. De naam van een vestiging moet gelijk blijven, ook wanneer de provider verandert.

Voor wijzigingen aan DNS Protection is in Sophos Fusion een passende beheerdersrol vereist. Een alleen-lezenaccount is geschikt voor controle, niet voor het maken, wijzigen of verwijderen. Het handmatig invoeren van een openbaar IP-adres of FQDN bewijst niet dat u gerechtigd bent de service te gebruiken.

Zelfstandig, oftewel netwerkgebaseerd, DNS vereist ten minste één geldige, aan Central gekoppelde firewall met Xstream Protection. Beheerd Endpoint DNS is daarentegen een Workspace-functie; Xstream alleen is daarvoor niet voldoende. Add known IPs detecteert alleen openbare adressen van gelicentieerde Sophos Firewalls met Xstream Protection. Secure DNS vereist een apparaat dat DNS via HTTPS kan verwerken; voor DNS Protection vereist Sophos Endpoint uitdrukkelijk deze verbindingsmethode.

Een aangepaste Location maken

1. Open My Products > DNS Protection > Locations > Add location. In de lijst met Locations opent de knop Add dit dialoogvenster.
2. Voer onder Location name een unieke naam en onder Description het doel in.
3. Schakel onder Connection method Secure DNS, Traditional DNS over IPv4 of beide in.
4. Noteer bij Secure DNS de weergegeven IPv4-adressen. De DNS over HTTPS URL wordt pas gegenereerd met Save.
5. Voeg bij Traditional DNS over IPv4 onder IPv4 addresses or FQDNs de openbare waarden toe. Bevestig elke afzonderlijke invoer met Enter of Tab. Bij het plakken van meerdere waarden moet elke waarde op een nieuwe regel staan.
6. Selecteer Save.
7. Kopieer en bewaar bij Secure DNS de gegenereerde DNS over HTTPS URL op een veilige plaats voordat u Close selecteert.

Gedetecteerde adressen gebruiken

Met Add known IPs toont Central suggesties:

• Your Current Location is het adres waarvandaan de huidige Central-sessie afkomstig is. Tijdens een VPN-sessie is dit het openbare adres van de VPN-server en mogelijk niet het gezochte vestigingsadres.
• Your Firewalls toont het adres waarmee een gelicentieerde Sophos Firewall Central bereikt. Alleen firewalls met Xstream Protection worden automatisch gedetecteerd.

Een gedetecteerde waarde is slechts een suggestie. DNS Protection werkt deze niet automatisch bij na latere adreswijzigingen. Bij multi-WAN moeten niet-gedetecteerde uitgaande adressen handmatig worden toegevoegd.

IP, FQDN, multi-WAN en DDNS

Voor een vaste verbinding is het openbare IPv4-adres doorgaans de duidelijkste keuze. Bij multi-WAN registreert u alle adressen waarlangs DNS-query’s daadwerkelijk naar buiten kunnen gaan; als alternatief kunt u een geschikt openbaar bereik gebruiken. Als het failoveradres ontbreekt, werkt DNS Protection na de omschakeling van de verbinding niet voor deze Location.

Voer bij een dynamisch adres een FQDN van een externe DDNS-dienst in. De DDNS-client moet het record betrouwbaar bijwerken. Als u hiervoor Sophos Firewall gebruikt, wordt de configuratie onder Network > Dynamic DNS > Add beschreven in Dynamic DNS op Sophos Firewall instellen en controleren. DNS Protection controleert adreswijzigingen elke minuut en heeft vervolgens acht seconden nodig om de cache bij te werken. Tijdens het bijwerken door de provider, DDNS en de cache kan de naamomzetting kort uitvallen.

Ondersteund worden DynDNS, DynAccess, EasyDNS, ZoneEdit, Google DDNS, Namecheap, DNS-O-Matic, No-IP, FreeDNS en Cloudflare. Bij Cloudflare moet Proxy status op DNS only staan; een record met proxy retourneert Cloudflare-adressen in plaats van het openbare uitgaande IP-adres.

CGNAT en adresconflicten

Traditional DNS vereist een uniek openbaar bron-IP-adres. Bij CGNAT en gedeelde uitgaande adressen van providers, proxy’s of VPN’s kan hetzelfde IP-adres in meerdere klantaccounts voorkomen. DNS Protection geeft voorrang aan de gebruiker die de Location het eerst heeft gemaakt. Een andere FQDN helpt niet als deze naar hetzelfde gedeelde IP-adres verwijst.

De betrouwbare oplossing is een uniek openbaar adres van de provider of Secure DNS voor compatibele apparaten. Privéadressen zoals 10.0.0.0/8, 172.16.0.0/12 en 192.168.0.0/16 identificeren de internetuitgang niet en horen niet in de Location.

De policytoewijzing voltooien

Met een Location kunnen binnenkomende DNS-query’s wel worden gekoppeld, maar de gewenste filtering wordt daarmee nog niet bepaald.

• Verplaats onder My Products > DNS Protection > Policies > Filtering policies de Location van Available naar Assigned to this policy. Aan een Location kan slechts één Filtering policy zijn toegewezen.
• Wijs in een Endpoint policy een Location toe aan de geselecteerde Windows-apparaten. Deze moet Secure DNS gebruiken; Default location is hiervoor ook toegestaan.

Het endpointpad, interne Domain exclusions en de agentcomponent staan in de afzonderlijke endpointhandleiding. Een Endpoint-toewijzing vervangt geen Filtering policy: de eerste bepaalt welke apparaten de Location gebruiken, de tweede bepaalt hoe hun domeinen en categorieën worden behandeld.

Een Location wijzigen

Leg vóór elke wijziging eerst de naam, methoden, IP-/FQDN-lijst, het DoH-gebruik en beide policytoewijzingen vast. Open vervolgens de aangepaste Location onder My Products > DNS Protection > Locations, pas de waarden aan en sla deze op met Save.

Gebruik voor een veilige migratie van de internetuitgang deze volgorde:

1. Voeg het nieuwe openbare adres naast het oude adres toe.
2. Wacht totdat het nieuwe internetpad actief is.
3. Controleer de DNS-omzetting en policytreffers via het nieuwe pad.
4. Verwijder pas daarna het oude adres.

Configureer en valideer bij een overstap van Traditional DNS naar Secure DNS eerst het DoH-pad met een pilotgroep. Laat Traditional DNS actief totdat de test is geslaagd. Zo voorkomt u een ongeteste omschakeling en kunt u snel terugkeren naar het bestaande pad.

Validatie na het maken of wijzigen

1. Controleer onder My Products > DNS Protection > Locations of Location, Description en het weergegeven aantal onder IP addresses/FQDNs kloppen.
2. Open de Location en controleer in de details of de beoogde Connection method en de verwachte IP-/FQDN-waarden zijn opgeslagen.
3. Controleer onder Policies of de Location is toegewezen aan de beoogde Filtering policy en, indien van toepassing, Endpoint policy.
4. Laat vanuit precies het betreffende DNS-pad een aantoonbaar toegestaan domein en een testdomein dat bewust door de toegewezen policy wordt geblokkeerd omzetten. Houd rekening met de cache en DNS-TTL.
5. Controleer in het dashboard of de rapporten of de query onder de verwachte Location verschijnt.

Een geslaagde naamomzetting alleen bewijst noch de juiste policy, noch de juiste Location. Alleen de combinatie van een positieve test, een geblokkeerde test en een passende rapportvermelding bevestigt het volledige pad. Als de query ontbreekt, vergelijkt u eerst het werkelijke openbare bron-IP-adres met IP addresses/FQDNs; bij een ongeldige FQDN of een IP-conflict controleert u vervolgens My Environment > Alerts.

Problemen per symptoom oplossen

De Location accepteert het adres niet

Statische vermeldingen en hostnamen worden alleen voor IPv4 ondersteund. Een privé- of IPv6-adres is geen geldige internetuitgang van een vestiging. Voer het openbare WAN-adres of een FQDN in dat daarnaar verwijst en sluit elke waarde af met Enter of Tab.

De omzetting stopt of de Location verschijnt niet in rapporten

Vergelijk de werkelijke internetuitgang met de opgeslagen IP-/FQDN-lijst. Bij multi-WAN kan een niet-geregistreerd failoveradres actief zijn. Controleer bij een FQDN eerst of deze naar een geldig openbaar IPv4-adres verwijst. Central meldt ongeldige FQDN’s en IP-conflicten onder My Environment > Alerts.

IP-conflict of CGNAT

Als hetzelfde openbare IP-adres al bij een andere klant hoort, behoudt de Location die het eerst is gemaakt voorrang. Een alias voor hetzelfde IP-adres verandert daar niets aan. Vraag de provider om een uniek openbaar IPv4-adres of gebruik Secure DNS voor geschikte apparaten.

DDNS-uitval na een adreswijziging

Controleer of de DDNS-record het nieuwe openbare adres al retourneert. Houd vervolgens ten minste rekening met de updatecyclus van DNS Protection en de cache-update. Controleer bij Cloudflare DNS only. Verwijder het oude IP-adres pas wanneer de nieuwe waarde overeenkomt met de werkelijke internetuitgang.

De policy wordt niet toegepast

Controleer aan welke Location de query daadwerkelijk is gekoppeld en bij welke Filtering policy die Location hoort. Per Location geldt slechts één Filtering policy. Na een policywijziging kan een DNS-record in de cache blijven werken totdat de TTL verloopt; test daarom opnieuw met een nieuwe testnaam of nadat de cache is verlopen.

Andere resolvers omzeilen DNS Protection

Als clients extra traditionele of IPv6-DNS-servers ontvangen, kunnen query’s DNS Protection omzeilen. Distribueer voor openbare omzetting uitsluitend het geplande DNS Protection-pad. DNS Protection is gebaseerd op IPv4, maar kan ook AAAA-records omzetten; een afzonderlijke IPv6-resolver is daarvoor niet nodig.

Beheer en levenscyclus

Controleer de Locations na een wijziging van provider, WAN, DDNS of policy, en ook regelmatig tijdens het gebruik. Vergelijk in de lijst Location, Description en het aantal onder IP addresses/FQDNs met de gedocumenteerde gewenste toestand. Controleer de Connection method in de details van de Location en de toewijzing op de pagina Policies. Automatisch voorgestelde adressen worden niet permanent gesynchroniseerd: als een eerder gedetecteerd IP-adres verandert, moet u de Location of de onderhouden DDNS-naam aanpassen en opnieuw valideren.

Voor operationele stappen zijn de actuele helppagina’s leidend. Release notes plaatsen wijzigingen zoals automatisch voorgestelde IP-adressen, de kopieerfunctie voor IP-adressen en FQDN’s, of de weergave van toegewezen Locations in Policies in de tijd; ze vervangen geen actuele configuratiehandleiding. Per 24 september 2026 bevatten de actuele helppagina’s en release notes geen concrete datum voor de buitengebruikstelling van DNS Protection.

Een aangepaste Location veilig verwijderen

De Default location kan niet worden verwijderd. Volg voor een aangepaste Location deze volgorde:

1. Bewaar de naam, beschrijving, ingeschakelde verbindingsmethoden, IP-/FQDN-waarden, policytoewijzingen en bestaande DoH-URL. Documenteer bovendien alle firewalls, resolvers en handmatig geconfigureerde apparaten die de Location gebruiken.
2. Als het DNS-pad nog nodig is, maakt en configureert u een vervangende Location. Dit mag alleen parallel aan de oude Location gebeuren als de vervangende Location een eigen, uniek routeerbare identiteit of een nieuw ingericht Secure DNS-pad gebruikt.
3. Als u een vervangende Location gebruikt, wijst u deze toe aan de beoogde Filtering en Endpoint policies. Zet daarna eerst een controleerbaar pilotpad over naar de vervangende Location, bijvoorbeeld pilotapparaten, een resolver of, voor zover operationeel mogelijk, een firewall.
4. Laat bij een vervangende Location via het pilotpad een toegestaan domein en een door de toegewezen policy geblokkeerd domein omzetten. Controleer in de rapporten of beide query’s aan de vervangende Location zijn toegewezen. Zet de overige firewalls, resolvers en handmatig geconfigureerde apparaten pas na een geslaagde controle over. Als het DNS-pad zonder vervanging vervalt, beëindigt u in plaats daarvan het gebruik ervan op alle gedocumenteerde systemen. Verwijder vervolgens de oude Location uit de bestaande policies en controleer of deze niet meer wordt gebruikt.
5. Selecteer pas nu onder My Products > DNS Protection > Locations de oude Location en vervolgens Delete.
6. Controleer bij een vervangende Location via het nieuwe pad opnieuw de toegestane en geblokkeerde omzetting en de toewijzing in de rapporten. Controleer bij verwijdering zonder vervanging of de resterende DNS-paden naar behoren werken.

Als een vervangende Traditional DNS-Location dezelfde openbare identiteit moet gebruiken en daarom niet uniek naast de oude Location kan bestaan, moet u vóór Delete stoppen. Documenteer de geplande omschakeling en het conflictrisico; de verwijdering mag pas worden uitgevoerd voor de bewust goedgekeurde omschakeling. De vervangende Location geldt in dit geval uitdrukkelijk niet als parallel gevalideerd.

Het opnieuw maken met de opgeslagen naam, beschrijving, methoden, IP-/FQDN-waarden en policytoewijzingen is slechts een herstelpoging op basis van best effort, geen gegarandeerde terugkeer naar de vorige toestand. Bij een betwiste openbare Traditional DNS-identiteit wordt met name de voorrang van de eerst gemaakte Location niet betrouwbaar hersteld. Bij Secure DNS genereert het opnieuw maken een nieuwe DNS over HTTPS URL; deze moet opnieuw op alle handmatig geconfigureerde apparaten worden geïmplementeerd. Verbind, waar van toepassing, firewalls en resolvers opnieuw met het traditionele pad. Test daarna de toegestane en geblokkeerde omzetting en de rapporten opnieuw.