Hantera Sophos DNS Protection Locations på ett säkert sätt

En Location anger för Sophos DNS Protection vilken plats, vilket nätverk eller vilken uppsättning enheter en DNS-fråga tillhör. Det är först genom denna koppling som platsbaserade Filtering Policies och meningsfulla rapporter blir möjliga. För stabil drift bör en Location motsvara utgående internettrafik, inte varje internt VLAN.

Hela arbetsflödet börjar under My Products > DNS Protection > Locations: välj anslutningsmetod, skapa en Location, kontrollera kopplingen på sidan Policies, testa den faktiska DNS-vägen och ta först därefter bort gamla IP-adresser eller Locations. Default location är en oföränderlig startpunkt för Secure DNS. Egna Locations används för platser, regioner eller separata policygrupper.

Välj mellan Default och en egen Location

Den fördefinierade Default location använder Secure DNS och fungerar utan att en offentlig platsadress registreras. Den kan kopplas både till en Endpoint policy och en Filtering policy. Du kan visa informationen under My Products > DNS Protection > Locations > Default, men du kan varken redigera eller ta bort den.

En egen Location är lämplig när minst ett av följande gäller:

• En brandvägg, router eller lokal DNS-resolver skickar traditionella DNS-frågor.
• Platser eller enhetsgrupper behöver olika Filtering Policies.
• Rapporter ska dela upp DNS-frågor efter region eller utgående internetanslutning.
• Endpoint-enheter behöver en egen Secure DNS-koppling i stället för Default.

DNS Protection tillåter högst 50 Locations. En egen Location kan använda Secure DNS, Traditional DNS over IPv4 eller båda metoderna. För varje Location kan högst 100 offentliga IPv4-adresser eller FQDN registreras.

Välj rätt anslutningsmetod

Secure DNS

Secure DNS överför DNS via HTTPS. Metoden passar kompatibla enheter och är obligatorisk för Sophos Endpoint med DNS Protection. När du sparar skapar Central en unik DNS over HTTPS URL. Sophos Endpoint konfigurerar hanterade enheter automatiskt. Vid manuell enhetskonfiguration behövs URL:en.

För den här distributionen måste exakt de två IPv4-adresser för DNS Protection som visas i Central användas och kopieras.

Traditional DNS over IPv4

Traditional DNS over IPv4 skickar DNS okrypterat till DNS Protection-resolvrarna. Metoden passar brandväggar, routrar och lokala DNS-servrar. DNS Protection identifierar en Location med hjälp av den offentliga käll-IP-adressen. Därför registrerar du den offentliga WAN-adressen, ett offentligt adressintervall eller ett FQDN som pekar på adressen – aldrig en intern RFC 1918-adress.

Den fullständiga brandväggskonfigurationen med vidarebefordrare, interna zoner och DHCP beskrivs i den separata guiden om Sophos DNS Protection med Sophos Firewall. Enbart en Location ändrar ännu inte DNS-vägen i nätverket.

Båda metoderna

Båda reglagen kan vara aktiva i samma egna Location. Det är användbart om samma policykontext omfattar både hanterade endpoints via DoH och en platsresolver via traditionell DNS. Bestäm först medvetet om de båda vägarna verkligen ska ha samma filtrering och samma rapporter.

Förutsättningar och adressplan

Anteckna följande innan du skapar en Location:

• ett unikt namn, en kort beskrivning och den tekniskt ansvariga personen,
• önskad anslutningsmetod,
• alla offentliga utgående adresser för Multi-WAN, SD-WAN och failover,
• ett underhållet DDNS-FQDN för en dynamisk offentlig adress,
• avsedd Filtering policy och, om tillämpligt, Endpoint policy,
• en direktansluten testenhet för varje DNS-väg.

Default är reserverat som namn. ZH-HQ-Egress är lämpligt i exempel. Beskrivningen kan innehålla leverantör, WAN-anslutningar och ansvarig person. Platsnamnet bör förbli oförändrat även om leverantören byts.

För ändringar i DNS Protection behövs en lämplig administratörsroll i Sophos Fusion. Skrivskyddad åtkomst fungerar för kontroll, men inte för att skapa, redigera eller ta bort. Att manuellt registrera en offentlig IP-adress eller ett FQDN bevisar inte att tjänsten får användas.

Fristående respektive nätverksbaserad DNS kräver minst en giltig brandvägg med Xstream Protection som är länkad till Central. Hanterad Endpoint DNS är däremot en Workspace-funktion. Enbart Xstream räcker inte för detta. Add known IPs identifierar endast offentliga adresser för licensierade Sophos-brandväggar med Xstream Protection. Secure DNS kräver en enhet som kan hantera DNS via HTTPS. Sophos Endpoint kräver uttryckligen denna anslutningsmetod för DNS Protection.

Skapa en egen Location

1. Öppna My Products > DNS Protection > Locations > Add location. I listan Locations leder knappen Add till den här dialogrutan.
2. Ange ett unikt namn under Location name och syftet under Description.
3. Aktivera Secure DNS, Traditional DNS over IPv4 eller båda under Connection method.
4. Anteckna IPv4-adresserna som visas för Secure DNS. DNS over HTTPS URL skapas först när du väljer Save.
5. För Traditional DNS over IPv4 lägger du till de offentliga värdena under IPv4 addresses or FQDNs. Bekräfta varje enskild post med Enter eller Tab. Om du klistrar in flera värden måste de avgränsas med radbrytningar.
6. Välj Save.
7. För Secure DNS kopierar du den skapade DNS over HTTPS URL och sparar den på ett säkert ställe innan du väljer Close.

Lägg till identifierade adresser

Med Add known IPs visar Central förslag:

• Your Current Location är den adress som den aktuella Central-sessionen kommer från. Under en VPN-session är det VPN-serverns offentliga adress och kanske inte den platsadress du söker.
• Your Firewalls visar den adress som en licensierad Sophos Firewall använder för att nå Central. Endast brandväggar med Xstream Protection identifieras automatiskt.

Ett identifierat värde är bara ett förslag. DNS Protection uppdaterar det inte automatiskt vid senare adressbyten. För Multi-WAN måste utgående adresser som inte identifieras läggas till manuellt.

IP, FQDN, Multi-WAN och DDNS

För en fast anslutning är den offentliga IPv4-adressen oftast det tydligaste valet. För Multi-WAN registrerar du alla adresser som DNS-frågor faktiskt kan skickas ut via. Alternativt kan ett lämpligt offentligt adressintervall användas. Om failover-adressen saknas fungerar DNS Protection inte för denna Location efter ett anslutningsbyte.

För en dynamisk adress anger du ett FQDN från en DDNS-tjänst från tredje part. DDNS-klienten måste uppdatera posten på ett tillförlitligt sätt. Om Sophos Firewall används för detta beskriver Konfigurera och kontrollera Dynamic DNS på Sophos Firewall konfigurationen under Network > Dynamic DNS > Add. DNS Protection kontrollerar adressändringar varje minut och behöver därefter åtta sekunder för att uppdatera sin cache. Namnuppslagning kan få korta avbrott medan leverantör, DDNS och cache uppdateras.

DynDNS, DynAccess, EasyDNS, ZoneEdit, Google DDNS, Namecheap, DNS-O-Matic, No-IP, FreeDNS och Cloudflare stöds. För Cloudflare måste Proxy status vara inställt på DNS only. En proxyaktiverad post returnerar Cloudflare-adresser i stället för den offentliga utgående IP-adressen.

CGNAT och adresskonflikter

Traditional DNS kräver en unik offentlig käll-IP-adress. Med CGNAT och delade utgående adresser hos leverantörer, proxyservrar eller VPN-tjänster kan samma IP-adress förekomma i flera kundkonton. DNS Protection prioriterar den användare som skapade sin Location först. Ett annat FQDN hjälper inte om det pekar på samma delade IP-adress.

Den robusta lösningen är en unik offentlig adress från leverantören eller Secure DNS för kompatibla enheter. Privata adresser som 10.0.0.0/8, 172.16.0.0/12 eller 192.168.0.0/16 identifierar inte utgående internettrafik och hör inte hemma i en Location.

Slutför policykopplingen

En Location gör det möjligt att koppla inkommande DNS-frågor, men definierar ännu inte den önskade filtreringen.

• Under My Products > DNS Protection > Policies > Filtering policies flyttas en Location från Available till Assigned to this policy. En Location kan endast vara kopplad till en Filtering policy.
• I en Endpoint policy tilldelas de valda Windows-enheterna en Location. Den måste använda Secure DNS. Default location är också tillåten.

Endpoint-vägen, interna Domain Exclusions och agentkomponenten beskrivs i den separata Endpoint-guiden. En Endpoint-tilldelning ersätter inte en Filtering policy: den första avgör vilka enheter som använder denna Location, medan den andra avgör hur dess domäner och kategorier hanteras.

Redigera en Location

Dokumentera alltid först namn, metoder, IP-/FQDN-lista, DoH-användning och båda policykopplingarna före varje ändring. Öppna sedan din Location under My Products > DNS Protection > Locations, anpassa värdena och spara med Save.

Vid migrering av utgående anslutning är det säkra arbetsflödet:

1. Lägg till den nya offentliga adressen utöver den gamla adressen.
2. Vänta tills den nya internetvägen är aktiv.
3. Kontrollera DNS-uppslagning och policyträffar via den nya vägen.
4. Ta först därefter bort den gamla adressen.

Vid byte från Traditional DNS till Secure DNS konfigurerar och validerar du först DoH-vägen för en pilotgrupp. Traditional DNS förblir aktiv tills testet har lyckats. På så sätt undviks en otestad migrering och det går snabbt att återgå till den tidigare vägen.

Validering efter skapande eller ändring

1. Kontrollera under My Products > DNS Protection > Locations att Location, Description och antalet som visas under IP addresses/FQDNs är korrekta.
2. Öppna denna Location och kontrollera i informationen att avsedd Connection method och förväntade IP-/FQDN-värden är registrerade.
3. Kontrollera under Policies att denna Location är kopplad till avsedd Filtering policy och, om tillämpligt, Endpoint policy.
4. Slå upp en domän som bevisligen är tillåten och en testdomän som avsiktligt blockeras av den tilldelade policyn, från exakt den berörda DNS-vägen. Ta hänsyn till cache och DNS-TTL.
5. Kontrollera i Dashboard respektive Reports att frågan visas under förväntad Location.

En lyckad namnuppslagning bevisar inte i sig att rätt policy eller rätt Location används. Det är först kombinationen av ett positivt test, ett blockerat test och en matchande rapportpost som bekräftar hela vägen. Om frågan saknas jämför du först den faktiska offentliga käll-IP-adressen med IP addresses/FQDNs. Vid ett ogiltigt FQDN eller en IP-konflikt kontrollerar du därefter My Environment > Alerts.

Felsökning efter symptom

Location accepterar inte adressen

Statiska poster och värdnamn stöds endast för IPv4. En privat adress eller IPv6-adress är inte en giltig utgående platsadress. Ange den offentliga WAN-adressen eller ett FQDN som slås upp till den och avsluta varje värde med Enter eller Tab.

Uppslagningen upphör eller Location visas inte i Reports

Jämför den faktiska utgående anslutningen med den sparade IP-/FQDN-listan. Med Multi-WAN kan en failover-adress som inte har registrerats vara aktiv. För ett FQDN kontrollerar du först att det slås upp till en giltig offentlig IPv4-adress. Central rapporterar felaktiga FQDN och IP-konflikter under My Environment > Alerts.

IP-konflikt eller CGNAT

Om samma offentliga IP-adress redan tillhör en annan kund fortsätter den Location som skapades först att ha företräde. Ett alias för samma IP-adress ändrar inte detta. Beställ en unik offentlig IPv4-adress från leverantören eller använd Secure DNS för lämpliga enheter.

DDNS-avbrott efter adressbyte

Kontrollera om DDNS-posten redan returnerar den nya offentliga adressen. Ta därefter hänsyn till minst DNS Protections uppdateringscykel och cacheuppdatering. Kontrollera DNS only för Cloudflare. Ta inte bort den gamla IP-adressen förrän det nya värdet och den faktiska utgående anslutningen stämmer överens.

Policyn tillämpas inte

Kontrollera vilken Location frågan faktiskt har kopplats till och vilken Filtering policy denna Location tillhör. Endast en Filtering policy kan gälla per Location. Efter en policyändring kan en redan cachad DNS-post fortsätta fungera tills dess TTL löper ut. Testa därför igen med ett nytt testnamn eller när cachetiden har löpt ut.

Andra resolvrar kringgår DNS Protection

Om klienter får ytterligare traditionella DNS-servrar eller IPv6-DNS-servrar kan frågor kringgå DNS Protection. Distribuera uteslutande den planerade DNS Protection-vägen för offentlig uppslagning. DNS Protection är IPv4-baserat men kan även slå upp AAAA-poster. Därför behövs ingen separat IPv6-resolver.

Drift och livscykel

Locations bör kontrolleras efter byte av leverantör, WAN, DDNS eller policy samt regelbundet under drift. I listan jämför du Location, Description och antalet under IP addresses/FQDNs med det dokumenterade börläget. Connection method kontrolleras i informationen för denna Location och kopplingen på sidan Policies. Automatiskt föreslagna adresser synkroniseras inte permanent: om en tidigare identifierad IP-adress ändras måste du anpassa denna Location eller det underhållna DDNS-namnet och validera på nytt.

De aktuella hjälpsidorna är vägledande för driftsåtgärder. Versionsinformationen visar när ändringar infördes, till exempel automatiskt föreslagna IP-adresser, kopieringsfunktionen för IP-adresser och FQDN samt visningen av kopplade Locations i Policies. Den ersätter inte en aktuell konfigurationsguide. Per den 24 september 2026 innehåller de aktuella hjälpsidorna och versionsinformationen inget specifikt datum för när DNS Protection ska tas ur drift.

Ta bort en egen Location på ett säkert sätt

Default location kan inte tas bort. För en egen Location följer du denna ordning:

1. Spara namn, beskrivning, aktiverade anslutningsmetoder, IP-/FQDN-värden, policykopplingar och befintlig DoH-URL. Dokumentera dessutom alla brandväggar, resolvrar och manuellt konfigurerade enheter som använder denna Location.
2. Skapa och konfigurera en ersättande Location om DNS-vägen fortfarande behövs. Detta får endast göras parallellt med den gamla Location om ersättningen använder en egen, unikt routningsbar identitet eller en nyetablerad Secure DNS-väg.
3. Om en ersättande Location används kopplar du den till avsedda Filtering- och Endpoint-policies. Migrera sedan först en kontrollerbar pilotväg till ersättningen, till exempel pilotenheter, en resolver eller – om driften medger det – en brandvägg.
4. Med en ersättande Location slår du via pilotvägen upp en tillåten domän och en domän som blockeras av den tilldelade policyn. Kontrollera i rapporterna att båda frågorna kopplas till den ersättande Location. Migrera övriga brandväggar, resolvrar och manuellt konfigurerade enheter först när kontrollen har lyckats. Om DNS-vägen avvecklas utan ersättning avslutar du i stället användningen på alla dokumenterade system. Ta därefter bort den gamla Location från tidigare policies och kontrollera att den inte längre används.
5. Välj först nu den gamla Location under My Products > DNS Protection > Locations och välj Delete.
6. Om en ersättande Location används kontrollerar du återigen den tillåtna och blockerade uppslagningen via den nya vägen samt kopplingen i rapporterna. Vid avveckling utan ersättning kontrollerar du att återstående DNS-vägar fungerar som avsett.

Om en ersättande Location för Traditional DNS ska använda samma offentliga identitet och därför inte kan existera unikt parallellt med den gamla Location, måste du stanna före Delete. Den planerade migreringen och konfliktrisken måste dokumenteras. Borttagningen får inte utföras förrän det avsiktliga bytet har godkänts. Ersättningen räknas i detta fall uttryckligen inte som parallellt validerad.

Att återskapa en Location med sparade namn, beskrivning, metoder, IP-/FQDN-värden och policykopplingar är endast ett återställningsförsök efter bästa förmåga, inte en garanterad återgång till det tidigare tillståndet. För en omtvistad offentlig Traditional DNS-identitet återställs i synnerhet inte företrädet för den Location som skapades först på ett tillförlitligt sätt. För Secure DNS skapar en återställning en ny DNS over HTTPS URL. Den måste distribueras igen till alla manuellt konfigurerade enheter. Återanslut, där det är tillämpligt, brandväggar och resolvrar till den traditionella vägen. Testa därefter tillåten och blockerad uppslagning samt rapporter på nytt.