Konfigurera DNS Request Routes på Sophos Firewall

En DNS Request Route vidarebefordrar frågor för en viss domän eller omvänd zon till utvalda DNS-servrar. Ett typiskt exempel är ad.example.com: Brandväggen slår upp offentliga namn via sina vanliga resolvrar, medan frågor för den interna zonen skickas till domänkontrollanterna.

Routen fungerar bara om Sophos Firewall behandlar frågan som DNS-server. Om en klient frågar den interna DNS-servern direkt ansvarar den serverns vidarebefordran, inte brandväggens Request Route.

Målzonen behöver inte vara intern: En Request Route kan även vidarebefordra frågor för utvalda offentliga domäner till en resolver i det egna nätet. Det är lämpligt om resolvern avsiktligt ansvarar för dessa domäner. Lokal behandling kan minska antalet externa DNS-frågor, men en viss hastighetsökning eller ytterligare konfidentialitet uppnås bara om målresolvern behandlar frågorna på motsvarande sätt och inte själv vidarebefordrar dem oförändrade till internet.

Fastställ DNS-vägen före ändringen

Tre konfigurationer med liknande verkan löser olika uppgifter:

• Klienten frågar brandväggen: DHCP eller VPN-profilen delar ut brandväggens gränssnitts-IP som DNS-server. För åtkomst till den lokala DNS-tjänsten måste DNS tillåtas för klientzonen under Administration > Device access > Local service ACL. Vanliga brandväggsregler styr inte denna åtkomst till själva brandväggen.
• Klienten frågar en intern DNS-server direkt: Den interna resolvern besvarar lokala zoner och vidarebefordrar andra frågor. Mellan olika zoner kan en vanlig brandväggsregel krävas; den här klientvägen använder inte någon Request Route på brandväggen.
• Brandväggen frågar en intern målserver: En Request Route väljer målserver utifrån den efterfrågade domänen. Routingen till målservern och dess nåbarhet måste vara korrekta.

En DNS Host Entry besvarar däremot ett enskilt namn direkt på brandväggen. För ett fåtal statiska poster visar Konfigurera DNS Host Entries på Sophos Firewall hela förloppet. En Request Route passar bättre för en hel zon som underhålls på en DNS-server. DHCP-alternativ avgör i sin tur vilken DNS-server och sökdomän en klient får; se Konfigurera DHCP-alternativ på Sophos Firewall.

⚠️ En Request Route väljs utifrån domännamnet, inte klientens källnät. Olika svar för olika platser måste tillhandahållas av de berörda resolvrarna eller av separata DNS-vägar. En enda route skapar inte en källberoende DNS-vy.

Exempel och förutsättningar

Det här exemplet vidarebefordrar en intern AD-zon till två resolvrar:

• intern zon: ad.example.com
• primär målserver: 10.10.10.10
• andra målserver: 10.10.10.11
• klientnät: 10.20.30.0/24
• brandväggens IP som klientresolver: 10.20.30.1
• positivt test: dc01.ad.example.com
• negativt test: example.net

example.com och example.net är dokumentationsdomäner. I produktionskonfigurationen ersätts zon-, server- och gränssnittsadresser med de egna värdena. Båda målservrarna bör ansvara för samma zon och ha samma zondata. En lång lista med olika resolvrar är inte en bra redundanslösning.

Följande måste vara klarlagt innan routen skapas:

1. Brandväggen är konfigurerad som resolver under Network > DNS > DNS configuration.
2. Målservrarna kan nås via den avsedda lokala routingvägen eller VPN-vägen.
3. De klienter som ska använda routen använder faktiskt brandväggens IP som DNS-server.
4. Under Administration > Device access är DNS endast tillåtet för nödvändiga klientzoner. En mer begränsad Local Service ACL Exception är lämplig om inte hela zonen ska ha åtkomst.
5. Den interna zonen finns på målservrarna och innehåller en känd testpost.
6. Den tidigare DNS-vägen och befintliga Request Routes är dokumenterade för återställning.

Skapa en DNS Request Route

1. Öppna Network > DNS i WebAdmin.
2. Gå till avsnittet DNS request route.
3. Välj Add.
4. Ange ad.example.com under Host/Domain name.
5. Välj 10.10.10.10 och 10.10.10.11 under Target servers. Om serverobjekten saknas skapas de som IP Hosts via Create.
6. Kontrollera ordningen: SFOS frågar de valda värdarna i angiven ordning.
7. Spara med Save.

Sophos tillåter högst åtta mål-IP-adresser per Request Route. Fler servrar förbättrar bara tillgängligheten om de besvarar samma zon korrekt och kan nås via oberoende vägar som faktiskt fungerar.

När en Request Route matchar och brandväggen inte hittar ett lämpligt svar i cachen skickar SFOS frågan till dess Target Servers. För den domänen faller den inte tillbaka på globala forwarders eller root-servrar. Om alla målservrar är onåbara eller felkonfigurerade för zonen misslyckas därför namnuppslagningen i stället för att obemärkt använda en offentlig resolver.

Under DNS request route ska den nya posten därefter visas med den förväntade domänen och målservrarna.

Bedöm flera målservrar korrekt

Den dokumenterade ordningen är en tillgänglighetsmekanism, inte ett sätt att jämka motstridiga DNS-data. För globala statiska resolvrar behandlar SFOS NXDOMAIN som ett giltigt svar och frågar därefter inte nästa server. Hjälpen för SFOS 22 bekräftar inte uttryckligen detta beteende för målservrarna i en Request Route. Förlita dig därför varken på en andra server med avvikande zondata eller på ett visst failover-beteende efter NXDOMAIN.

Vid acceptanstestet frågas båda målservrarna individuellt från ett behörigt testsystem. De måste ge samma svar på det positiva testet; ett avsiktligt obefintligt namn bör också ge samma resultat på båda servrarna. På så sätt upptäcks replikerings- eller zonauktoritetsfel innan brandväggen behöver växla mellan servrarna.

nslookup dc01.ad.example.com 10.10.10.10
nslookup dc01.ad.example.com 10.10.10.11
nslookup does-not-exist.ad.example.com 10.10.10.10
nslookup does-not-exist.ad.example.com 10.10.10.11

De direkta frågorna testar zondata och serversvar, inte Request Routen. De ska bara köras från ett nät som enligt DNS-designen får nå båda resolvrarna. Därefter bekräftar frågan via 10.20.30.1 att även brandväggen skickar zonen till de avsedda servrarna.

Vidarebefordra omvända uppslag

För PTR-frågor anger du den omvända zonen i stället för ett nät under Host/Domain name. För 172.16.16.0/24 är den klassiska omvända IPv4-zonen:

16.16.172.in-addr.arpa

För 172.16.0.0/16 är den:

16.172.in-addr.arpa

En CIDR-angivelse som 172.16.16.0/24 hör inte hemma i domänfältet. Det avgörande är den zon som faktiskt är konfigurerad på den interna DNS-servern. Request Routen skapar inga PTR-poster; om zonen eller posterna saknas på målservern misslyckas det omvända uppslaget. IPv4-nät som inte följer oktettgränser och omvända IPv6-zoner kräver en egen DNS-delegeringsdesign och bör inte improviseras genom att bara vända på prefixet.

Omvänd DNS hjälper loggar och tjänster att koppla en adress till ett namn. Den reparerar dock inte ett misslyckat framåtriktat uppslag av ett FQDN och är därför ett separat testfall.

Förstå den globala resolvervägen

Under Network > DNS > DNS configuration anger du hur brandväggen slår upp frågor som inte matchar någon Host Entry eller Request Route. Beroende på gränssnitt kan SFOS hämta resolvrar via Obtain DNS from DHCP eller Obtain DNS from PPPoE. Med Static DNS anges DNS 1, DNS 2 och valfritt DNS 3 uttryckligen.

⚠️ Om Obtain DNS from DHCP är aktivt och det sista matchande DHCP-gränssnittet stängs av eller ändras till ett annat tilldelningsläge växlar SFOS till Static DNS. När gränssnittet aktiveras igen återställs inte inställningen automatiskt. Kontrollera därför DNS-valet efter ändringar av WAN och gränssnitt.

Med Static DNS frågar brandväggen servrarna i angiven ordning. Den går vidare till nästa server efter en timeout, men inte efter ett giltigt NXDOMAIN-svar. Svaren ligger kvar i cachen enligt sin TTL. En andra resolver är därmed en tillgänglighetsreserv, inte en alternativ DNS-sanning.

För de globala DNS-servrarna dokumenterar SFOS 22 fyra valmöjligheter. För de två alternativen med fast prioritet måste både IPv4- och IPv6-DNS-servrar vara konfigurerade:

• Choose a server based on incoming requests record type väljer DNS-server utifrån den efterfrågade posttypen A eller AAAA.
• Choose IPv6 DNS server over IPv4 ger IPv6-DNS-servern prioritet framför IPv4-DNS-servern.
• Choose IPv4 DNS server over IPv6 ger IPv4-DNS-servern prioritet framför IPv6-DNS-servern.
• Choose IPv6 if request originator address is IPv6, else IPv4 använder IPv6-DNS-servern för en fråga från en IPv6-källadress och IPv4-DNS-servern för en fråga från en IPv4-källadress.

Posttyp och källadressfamilj är olika kriterier: En AAAA-fråga är inte automatiskt en fråga från en IPv6-källadress. Valet görs därför utifrån den avsedda resolvervägen, inte enbart utifrån den önskade adressen i DNS-svaret. De valda resolvrarna måste kunna nås via respektive adressfamilj. Dessa globala alternativ ändrar inte det domänbaserade valet av Target servers i en Request Route.

Efter Apply testar Test name lookup ett värdnamn eller en IP-adress ur brandväggens perspektiv. Ett internt testnamn kan använda en passande Request Route. Testet bekräftar dock varken resolvern som angetts på klienten eller klientens faktiska DNS-väg.

Om WebAdmin inte är tillgängligt under en planerad återställning visar den interaktiva CLI:n under 1. Network Configuration > DNS Configuration de globala DNS-servrarna för IPv4 och IPv6. Menyalternativet ändrar inga Request Routes. Spara alla visade värden före inmatning; Enter utan ett nytt värde hoppar över ändringen. Behåll en oberoende administrationsväg för fjärrändringar.

Kombinera DNS Protection med interna zoner

Välj version först: Använd från SFOS 23.0 den integrerade DoH-vägen med DNS Protection under Network > DNS och tilldelning av Filtering Policy till brandväggsobjektet. Konfiguration, fallbackbeslut, pilot och återställningsväg beskrivs i DNS Protection-artikeln som länkas nedan. Följande sekvens för Location, DDNS och Static DNS gäller uteslutande Traditional DNS på SFOS 22 och äldre; den ska inte också utföras för den integrerade SFOS 23-vägen. Interna Request Routes och kontrollerna av klientväg och NAT förblir relevanta.

Med Sophos DNS Protection och Sophos Firewall går offentliga frågor till DNS Protection, medan Request Routes skickar interna zoner till lokala resolvrar. Brandväggen registreras först som en Location i Sophos Fusion (tidigare Sophos Central). Om flera offentliga WAN-adresser används måste alla adresser eller lämpligt intervall registreras; vid en dynamisk WAN-adress används det registrerade DDNS-värdnamnet.

Sophos officiella konfiguration anger de två DNS Protection-adresserna som DNS 1 och DNS 2 under Network > DNS > DNS configuration, lämnar DNS 3 tomt, tar bort IPv6-DNS-servrar och väljer Choose IPv4 DNS server over IPv6. En tredje resolver eller en oavsiktlig IPv6-resolver kan göra att frågor går förbi DNS Protection.

För DHCP anger Sophos en särskild väg: Under Network > DHCP > Server > Edit ska Use device’s DNS settings vara avstängt. Brandväggens IP på DHCP-gränssnittet anges som Primary DNS och en offentlig DNS Protection-adress som Secondary DNS. Eftersom klienter kan hantera flera resolvrar olika måste du kontrollera att interna frågor verkligen går via brandväggen. Direkta klientfrågor till DNS Protection använder inte brandväggens lokala Request Routes.

Sophos beskriver även en DNAT-regel som omdirigerar klassiska utgående DNS-frågor från interna nät till brandväggens interna IP. Omdirigeringen är ett separat säkerhetsbeslut: den fångar inte automatiskt DNS over HTTPS eller DNS over TLS och kan påverka specialenheter. Den ska endast införas med tydligt angivna källnät, utan WAN som Inbound Interface och med en dokumenterad undantags- och återställningsplan.

Testa brandvägg och klient separat

Brandväggens resolverperspektiv

Testa dc01.ad.example.com och example.net efter varandra under Network > DNS > Test name lookup. Det interna namnet måste ge den förväntade interna adressen, medan det offentliga namnet fortsatt ska lösas via den avsedda standardvägen.

I 4. Device Console kan samma perspektiv testas med det officiellt dokumenterade kommandot:

dnslookup host dc01.ad.example.com
dnslookup host example.net

Testerna visar brandväggens resolverperspektiv. De bevisar ännu inte att en klient frågar brandväggen.

Jämför enskilda resolvrar under Diagnostics

Under Diagnostics > Tools erbjuder SFOS 22 Name lookup med IP address or hostname och DNS server IP. Ett FQDN testar framåtriktad namnuppslagning, medan en IPv4- eller IPv6-adress testar omvänd namnuppslagning. Välj en specifik konfigurerad server eller jämför svar och svarstider från alla konfigurerade resolvrar med Lookup using all configured servers. En kort svarstid är i sig inget skäl att ändra serverordningen; först måste svaren stämma för den avsedda zonen.

I SFOS 23 heter avsnittet DNS lookup och fälten Hostname or IP address och DNS server IP address. Utöver en tillgänglig server och All configured servers finns alternativen Custom DNS server och Custom DoH server; för vart och ett anges den önskade serverns IP-adress. DNS Protection kan bara väljas om DNS Protection är aktiverat under Network > DNS. Detta är ett diagnostikalternativ, inte en uppmaning att ändra den befintliga DNS-konfigurationen för ett test.

Använd endast godkända interna resolvrar för interna testnamn, så att namnen inte skickas till en offentlig DNS- eller DoH-tjänst. En riktad fråga till en resolver bekräftar dess svar, inte den faktiska vägen via en Request Route eller klientens faktiska väg. Därför behövs fortfarande acceptanstestet via brandväggens IP och Packet Capture.

Verifiera klientvägen

Kontrollera först den konfigurerade DNS-servern på en testklient och fråga sedan uttryckligen brandväggens IP 10.20.30.1.

Windows:

ipconfig /all
nslookup dc01.ad.example.com 10.20.30.1
nslookup example.net 10.20.30.1

macOS eller Linux:

dig @10.20.30.1 dc01.ad.example.com A
dig @10.20.30.1 example.net A

Kör därefter samma frågor utan att ange en server. Om resultaten skiljer sig använder klienten en annan resolverväg, exempelvis en statisk inställning, en VPN-profil, DNS over HTTPS eller en lokal säkerhetsagent. En sökdomän är bara relevant för korta, okvalificerade namn; de FQDN som används ovan behöver den inte.

Packet Capture för den faktiska vägen

Under Diagnostics > Packet capture begränsar ett filter på testklienten, målservrarna och port 53 trafikflödet. Packet Capture på Sophos Firewall förklarar det exakta förfarandet.

(host 10.20.30.50 or host 10.10.10.10 or host 10.10.10.11) and port 53

Kontrollera den inkommande klientfrågan, frågan som brandväggen skapar till rätt Target Server och respektive svar. Capturen skiljer därmed utebliven klientåtkomst från ett routing- eller målserverproblem. Eftersom capture-bufferten är begränsad ska filtret vara snävt och inspelningen endast aktiveras under testet.

För DNS Protection kompletterar den officiella länken Check your configuration under My Products > DNS Protection > Installers kontrollen. Välkomstsidan bekräftar DNS Protection-vägen; intern zon, klientväg och Request Route testas ändå separat.

Avgränsa fel efter symptom

Brandväggen löser internt, men inte klienten

• Kontrollera att klienten verkligen använder brandväggens IP som DNS-server.
• Kontrollera under Administration > Device access att DNS är tillåtet för klientzonen eller via en lämplig Local Service ACL Exception.
• Skicka frågan uttryckligen till brandväggens IP och bekräfta med Packet Capture.
• Kontrollera DHCP-, VPN- och lokala resolverinställningar samt DoH/DoT som alternativa vägar.

Brandväggen når inte Target Server

• Kontrollera Route Lookup och den lokala vägen eller VPN-vägen till måladressen.
• Kontrollera UDP- och TCP-port 53 fram till målservern samt serverns egen ACL.
• Fråga resolvern direkt och kontrollera att den accepterar frågor från brandväggens IP.
• Leta i Packet Capture efter en skapad fråga, ett svar eller en drop-orsak.

Om klienterna frågar den interna DNS-servern direkt gäller i stället den normala transitvägen med zoner och brandväggsregel. För denna avgränsning hjälper Kontrollera brandväggsregler med Log Viewer, Policy Test och Packet Capture.

Felaktiga eller varierande svar

• Domänen är för bred eller felaktig: Begränsa Request Routen till den zon som faktiskt ansvarar.
• Målservrarna ger olika data: Kontrollera DNS-replikering och zonauktoritet direkt på varje server.
• Gammalt svar: Ta hänsyn till TTL och cache på brandvägg, resolver och klient.
• Endast korta namn misslyckas: Kontrollera klientens sökdomän och testa FQDN separat.
• Omvänt uppslag misslyckas: Kontrollera PTR-zonen och PTR-posten på målservern.
• Endast VPN-klienter påverkas: Kontrollera tilldelade DNS-servrar, VPN-routing och åtkomst till den lokala DNS-tjänsten. Rätt klientfält finns i Konfigurera Sophos Connect respektive Konfigurera SSL VPN Remote Access.

XML API: identifiera routen med objektnamnet

Från SFOS 23 kräver XML-API-dokumentationen både Name och DomainName när en DNS Request Route skapas eller redigeras. Name identifierar det konfigurerade objektet, medan DomainName avser DNS-zonen som ska vidarebefordras; exempelvis Name = ad-intern och DomainName = ad.example.com. Detta är fältvärden, inte körbar XML. Name är ett enskilt STRING med högst 64 tecken, tillåter UTF-8 och förbjuder kommatecken. DomainName förblir FQDN med högst 255 tecken; målservrarna måste också fortsatt anges.

Vid borttagning ändras den dokumenterade nyckeln från DomainName i SFOS 22 till Name i SFOS 23. Återanvänd inte gamla anrop oförändrade och använd inte automatiskt domännamnet som objektnamn. Kontrollera först den installerade versionen och läs det specifika objektet, jämför Name, DomainName, Target Servers och beroenden med det avsedda målet och dokumentera återställningsvägen. Stoppa vid tvetydighet. Kontrollera efteråt API-svaret och status och läs det exakta målobjektet igen: endast den avsedda routen får vara borttagen; andra routes måste vara oförändrade. Testa därefter intern och offentlig namnuppslagning enligt ovan. Här uppfinns inget borttagnings-envelope eller REST-schema och inget produkttest påstås ha genomförts.

Den globala DNS-protokollkonfigurationen är separat. DNS Protection-artikeln förklarar de olösta konflikterna i SFOS 23:s XML-schema och den säkra WebAdmin-vägen; de fyra resolveralternativen ovan, som uttryckligen beskrivs för SFOS 22, bevisar ingen numerisk mappning i SFOS 23:s API.

XML API: SFOS 22 — Add/Edit; SFOS 23 — Add/Edit; SFOS 22 — Delete; SFOS 23 — Delete.

Återställning och drift

Dokumentera före ändringen befintliga Request Routes, det globala DNS-valet, Device Access-behörigheter samt ett positivt och ett negativt test. Vid normal återställning tas den nya routen bort eller återställs till de exakt dokumenterade tidigare värdena. Tillfälliga ACL-undantag eller DNS-omdirigeringar återställs också till ursprungsläget.

Därefter kontrolleras tre saker igen:

1. Brandväggen löser ett internt och ett offentligt namn via den avsedda vägen.
2. Den berörda klienten använder avsedd resolver och får förväntade svar.
3. En opåverkad domän skickas inte till den interna Target Server.

En fullständig konfigurationsbackup är inte en smidig återställning av ett enskilt objekt: En restore ersätter hela konfigurationen och kan skriva över senare ändringar. För en enda Request Route är den dokumenterade objektändringen därför den säkrare vägen tillbaka.

Vanliga frågor