Konfigurera DNS Request Routes till Sophos Firewall

Med DNS Request Routes kan du ange på Sophos Firewall vilken DNS-server som ska användas för vissa domäner eller omvända zoner. Detta är särskilt användbart om brandväggen använder offentliga DNS-servrar, men interna namn måste lösas via en intern DNS-server.

Typiska exempel är Active Directory-domäner, interna applikationer, omvända sökningar eller VPN-miljöer.

När Sophos DNS Protection används med Sophos Firewall, blir DNS Request Routes ännu viktigare. Offentliga domäner går sedan till DNS Protection-tjänsten, men interna domäner fortsätter att gå till den lokala DNS-servern eller domänkontrollanten. Utan denna separation kan interna applikationer, AD-inloggningar eller omvända uppslag plötsligt verka som nätverksproblem.

Orientering och design

DNS Request Routes fungerar bara tillförlitligt om det är tydligt vilken resolver som ser vilken begäran. Därför bör du först skilja mellan DNS design, klient DNS, interna zoner och routingväg.

DNS Request Route, DNS server eller DHCP alternativ?

DNS Request Routes förväxlas ofta med globala DNS-servrar eller DHCP-alternativ. Funktionerna löser olika problem.

• Globala DNS-servrar: Standardbrandväggsupplösning för Internet DNS, allmän FQDN-upplösning, uppdateringar och molntjänster.
• DNS Request Route: omdirigerar specifika domäner eller omvända zoner till definierade DNS-servrar. Active Directory, interna domäner, plats DNS och split DNS är typiska.
• DHCP Alternativ: distribuerar DNS servrar eller sökdomäner till klienter. Detta är relevant om klienter ska använda en specifik DNS-server direkt.

En DNS Request Route ändrar alltså inte automatiskt DNS-konfigurationen för alla klienter. Rutten styr vart Sophos Firewall själv, eller klienter som använder brandväggen som DNS-forwarder, vidarebefordrar specifika DNS-frågor. Om klienter ska använda en intern DNS-server direkt är ett DHCP-alternativ på Sophos Firewall lämpligare.

Skillnaden mot DNS värdposten är också viktig: En DNS värdpost besvarar ett specifikt värdnamn direkt med en IP-adress på brandväggen. En DNS Request Route, å andra sidan, vidarebefordrar en domän eller zon till en annan DNS-server. För Active Directory och dynamiska interna zoner är en förfrågningsrutt nästan alltid renare än många enskilda värdposter.

Vilken DNS design passar?

Innan du skapar en DNS Request Route bör det vara klart vilken resolver som används i respektive nätverk. Rutten hjälper bara om Sophos Firewall också ser begäran.

• Klienter frågar Sophos Firewall: Brandväggen vidarebefordrar offentliga domäner globalt och interna domäner via DNS Request Route. Detta fungerar bra för små och medelstora platser, DNS Protection såväl som gäst- eller klientnätverk.
• Klienter frågar interna DNS-servrar direkt: Domänkontrollanter eller DNS-servrar löser internt och vidarebefordrar externt. Detta är lämpligt för klassiska Active Directory-nätverk med Windows DNS som central resolver.
• VPN-klienter frågar brandväggen: Brandväggen använder Request Routes för interna domäner. Detta är lämpligt för fjärråtkomst med en enkel DNS-väg via brandväggen.
• VPN-klienter frågar interna DNS-servrar direkt: DNS körs via VPN till domänkontrollanten eller DNS-servern. Detta är lämpligt för större AD-miljöer när klienter ska använda samma DNS-logik som i LAN.

I blandade miljöer är en kort DNS-skiss till stor hjälp: klientnätverk, tilldelad DNS-server, sökdomän, interna DNS-zoner, DNS Request Routes och routingväg till målservern. Utan denna översikt bearbetas förfrågningsvägen ofta senare, även om klienten inte använder brandväggen som en DNS-resolver.

För att DNS Request Routes ska fungera för klienter måste Sophos Firewall finnas i sökvägen som en DNS-server. Detta kan vara direkt, när klienter tar emot brandväggens gränssnitts-IP som en DNS-server, eller indirekt, när en intern resolver medvetet omdirigerar till brandväggen. Om klienter direkt begär en domänkontrollant ser brandväggen inte denna DNS-begäran som en resolver och kan inte omdirigera den via en begäranväg.

När behöver du DNS Request Routes?

DNS Request Routes är användbara om:

• interna värdnamn som server01.firma.local måste lösas
• Omvända sökningar för interna IP-nätverk bör fungera
• VPN användare bör använda interna namn
• flera platser har sina egna DNS-zoner
• själva brandväggen måste nå interna system via FQDN
• offentliga DNS-servrar känner inte till interna namn

Utan DNS Request Route frågar brandväggen den globalt konfigurerade DNS-servern. Om den interna domänen inte är känd där, kommer upplösningen att misslyckas.

Denna skillnad är särskilt viktig för fjärråtkomst. Om VPN-klienter använder brandväggen som en DNS-server, kan en DNS Request Route säkerställa att interna domäner fortfarande hamnar på rätt domänkontrollant eller DNS-server. Om däremot VPN-klienter tar emot interna DNS-servrar direkt måste det också kontrolleras om routing, brandväggsregler och DNS-suffix är korrekta på klienten.

Krav

• Tillgång till WebAdmin av Sophos Firewall
• Sophos Firewall är korrekt konfigurerad som DNS-resolver eller DNS-forwarder under Network > DNS > DNS configuration
• Intern DNS-server är tillgänglig
• Domän eller nätverk är känt
• Brandväggsregler tillåter DNS trafik till målservern
• För webbplatsnätverk: Routing till DNS-servern fungerar
• Den berörda klienten använder antingen brandväggen som en DNS-server eller får avsiktligt en annan DNS-server

⚠️ DNS-problem verkar ofta som routing-, VPN- eller programproblem. Innan du gör större ändringar bör du kontrollera om målservern kan nås via IP och om bara namnupplösningen misslyckas.

Under Network > DNS > DNS configuration bör du också kontrollera hur brandväggen löser sina normala DNS-frågor. Om DNS Protection används finns DNS Protection-IP-adresserna där. Om klassiska forwarders eller interna resolvers används måste dessa servrar vara tillgängliga. Med Test name lookup kan du kontrollera direkt i DNS-konfigurationen om brandväggen i grunden kan lösa ett namn eller en IP.

Konfigurera DNS Request Route

Konfigurationen är tekniskt enkel, men blir snabbt förvirrande när domäner, omvända zoner, VPN-klienter och flera platser möts.

Skapa DNS Request Route för en domän

En domänrutt säkerställer att förfrågningar för en specifik domän skickas till en definierad DNS-server.

Exempel:

• Host/domain name: firma.local
• DNS server: 10.10.10.10

Tillvägagångssätt:

1. Logga in på Sophos Firewall.
2. Öppna Network > DNS.
3. Gå till området DNS request route.
4. Välj Add.
5. Ange den interna domänen under Host/domain name, till exempel firma.local.
6. Under Target servers väljer du den interna DNS-servern eller skapar den som host med Create.
7. Spara.

Värdet i Host/domain name ska skrivas som ett FQDN eller zonnamn, inte som URL, wildcard-regel eller fri beskrivning. Sophos API behandlar värdet som ett FQDN-fält med högst 255 tecken. För vanliga domänrutter räcker till exempel firma.local; för reverse lookups används motsvarande in-addr.arpa-zon.

Om en DNS cache-träff saknas på brandväggen, skickas den lämpliga begäran för denna domän inte till de vanliga vidarebefordrarna eller rotservrarna, utan till målservrarna för förfrågningsrutten. Detta är avsiktligt: ​​Interna zoner bör inte av misstag frågas externt. Men det betyder också att en felaktigt vald målserver svarar rätt på frågan och fortfarande kan ha tekniskt fel.

Använd flera målservrar

Under Target servers kan du lägga till mer än en DNS-server. Detta är vettigt om det finns flera interna DNS-servrar eller om DNS ska vara redundant tillgänglig via en platsanslutning.

Möjliga målservrar:

• interna DNS-servrar i det lokala nätverket
• DNS server på andra sidan av en VPN anslutning
• DNS server på en annan plats
• offentliga DNS-servrar om en specifik domän avsiktligt ska lösas externt

Beställningen är relevant. Brandväggen frågar de valda värdarna i den ordning som de visas i listan. Upp till åtta IP-adresser kan lagras per DNS Request Route. Fler målservrar betyder dock inte automatiskt bättre redundans om servrarna har olika zonstatus, olika vidarebefordran eller olika tillgänglighet via VPN.

Om det finns flera målservrar ska du inte bara ange redundans, utan även kontrollera ansvar. Om den första DNS-servern känner till zonen men ger inaktuella poster, kommer förfrågningsrutten tekniskt att fungera och fortfarande returnera tekniskt felaktiga svar.

En NXDOMAIN är ett giltigt svar ur ett DNS perspektiv. Om den första tillgängliga DNS-servern säger att ett namn inte finns, frågar brandväggen inte automatiskt nästa server i hopp om ett annat svar. Därför bör målservrar ha samma zonstatus och samma omdirigeringar för samma förfrågningsrutt.

Dela DNS för VPN och platser

Split DNS betyder att samma namn löses olika beroende på plats eller nätverk. Till exempel kan en intern portal peka internt till en privat IP, medan samma namn löser sig externt till en offentlig adress eller inte alls.

Tre punkter är avgörande på Sophos Firewall:

1. Lämplig DNS Request Route för den interna domänen.
2. En brandväggsregel som tillåter DNS från brandväggen eller klienten till den interna DNS-servern.
3. En routingsökväg till DNS-servern, speciellt för site-to-site VPN, SSL VPN eller Sophos Connect.

För fjärråtkomstmiljöer bör du också kontrollera vilka DNS-servrar och sökdomäner som klienten tar emot. För Sophos Connect passar detta Konfigurera Sophos Connect på Sophos Firewall. För klassiska SSL VPN-inställningar passar Sophos Firewall SSL VPN Konfigurera fjärråtkomst.

Med DNS Protection tillkommer en designfråga: Sophos rekommenderar att nätverksenheter använder brandväggen som DNS-resolver. Därför distribueras brandväggens gränssnitts-IP normalt som DNS-server i brandväggens DHCP-servrar. Om enheter ändå använder externa resolvers kan en riktad NAT-regel för utgående DNS-trafik till brandväggen planeras. Detta bör göras medvetet och inte generellt, eftersom hårda DNS-omdirigeringar kan påverka felsökning, BYOD-enheter, DoH/DoT och specialenheter.

Om brandväggen själv använder DNS Protection som forwarder bör de DNS Protection-IP-adresser som kopierats från Sophos Central anges under Network > DNS > DNS configuration som primär och sekundär DNS-server. En avvikande tredje DNS-server eller en oavsiktlig IPv6-DNS-väg kan göra att frågor går förbi DNS Protection. Därför bör DNS Request Routes, DHCP-DNS-alternativ, IPv6-DNS-inställningar och valfria DNS-NAT-regler kontrolleras som en gemensam design.

Omvänd DNS för interna nätverk

En omvänd DNS-förfrågningsrutt vidarebefordrar PTR-frågor för ett internt IP-nätverk till DNS-servern, som känner till den lämpliga omvända uppslagningszonen. Detta hjälper när loggar, rapporter eller tjänster behöver konvertera en IP-adress till ett värdnamn igen.

Exempel:

• Nätverk: 172.16.16.0/24
• DNS server: 172.16.16.10
• Omvänd zon: 16.16.172.in-addr.arpa

För omvända sökningar skapar du också en DNS Request Route under Network > DNS > DNS request route. Under Host/domain name anger du dock inte den normala domänen, utan snarare den omvända zonen.

Exempel för 172.16.16.0/24:

16.16.172.in-addr.arpa

Oktetternas ordning är omvänd. Nätverket 172.16.16.0/24 blir 16.16.172.in-addr.arpa. Viktigt: ange inte CIDR-notation som 172.16.16.0/24 i Host/domain name, utan en DNS-zon. Värdet bör därför se ut som ett domännamn eller en omvänd zon, inte som en fri beskrivning.

För större nätverk kan den omvända zonen vara bredare. Exempel: För 172.16.0.0/16 skulle det vara 16.172.in-addr.arpa. Det avgörande är hur zonen för omvänd sökning skapades på den interna DNS-servern.

Om det inte finns någon PTR-zon eller inga PTR-poster på den interna DNS-servern, hjälper förfrågningsrutten inte heller. Brandväggen kan bara skicka begäran till rätt DNS-server, men den skapar inte omvända DNS-poster på DNS-servern.

För IPv6-miljöer med ett leverantörsprefix bör du också överväga DNS tidigt. Hur klienter får sin IPv6-adress och vilken roll routerannonsering och DHCPv6 spelar beskrivs i Konfigurera IPv6-prefixdelegering på Sophos Firewall.

Provning och drift

Efter konfigurationen bör du testa IP-tillgänglighet, DNS-upplösning och klient DNS separat. Detta gör det lättare att se om problemet verkligen ligger i förfrågningsvägen.

Testning och validering

Efter konfiguration bör du testa namnupplösningen:

• Kan brandväggen lösa det interna namnet?
• Fungerar Network > DNS > Test name lookup för ett internt och ett offentligt namn?
• Fungerar upplösningen från VPN eller användarzoner?
• Är DNS-servern tillgänglig via ping eller TCP/UDP 53?
• Finns det poster i DNS eller brandväggsloggen?

Om upplösningen inte fungerar bör du först kontrollera:

• Är domänen rättstavad?
• Använder klienten verkligen Sophos Firewall eller rätt DNS server?
• Blockerar en brandväggsregel DNS?
• Saknas en rutt till DNS-servern?
• Svarar DNS-servern på förfrågningar från brandväggen?

Ett användbart test skiljer åt IP-tillgänglighet och DNS-upplösning:

1. Testa målsystemet via IP, till exempel ping, TCP-port eller applikation.
2. Nå servern DNS själv via IP.
3. Lös namn via den förväntade DNS-källan.
4. Testa sedan applikationen med namnet.

Om åtkomst fungerar via IP men inte med namn, ligger fokus på DNS Request Route, DNS-suffix, klient-DNS eller omvänd sökning. Om åtkomst via IP redan misslyckas bör du först kontrollera routing, brandväggsregel, NAT eller VPN. Testa brandväggsregeln med Log Viewer, Policy Test och Packet Capture och Sophos Firewall-regeln fungerar inte: kontrollera orsaker hjälper till med denna differentiering.

Testkommandon för brandvägg och klienter

På Sophos Firewall kan Device Console hjälpa till att testa DNS ur brandväggsperspektivet:

dnslookup server01.firma.local
dnslookup example.com

På klienter bör du också kontrollera vilken resolver som faktiskt används.

Windows:

ipconfig /all
nslookup server01.firma.local
nslookup server01.firma.local <firewall-ip>
Resolve-DnsName server01.firma.local

macOS:

scutil --dns
dig server01.firma.local
dig @<firewall-ip> server01.firma.local

Linux:

resolvectl status
dig server01.firma.local
dig @<firewall-ip> server01.firma.local

<firewall-ip> står för den interna gränssnittsadressen för Sophos Firewall i respektive nätverk. Om frågan mot brandväggen fungerar men den vanliga klientfrågan inte gör det, är problemet oftast med DHCP, VPN profil, DNS suffix, lokal resolver eller webbläsare/system DNS beteende. If the query against the firewall also fails, the next check points are Request Route, Target Server, Routing or Firewall Rule.

För klienter med moderna webbläsare eller slutpunktsagenter bör du också kontrollera om DNS-över-HTTPS eller en lokal säkerhetsagent kringgår den normala DNS-frågan. Då kanske brandväggen inte ser en klassisk DNS-förfrågan på UDP/TCP 53, även om nätverkskonfigurationen ser korrekt ut.

Definiera positiva och negativa tester

En DNS Request Route anses bara vara korrekt testad när inte bara det önskade interna namnet fungerar, utan även ett motexempel har kontrollerats. Annars är det oklart om rutten träffar den interna zonen exakt eller om DNS av misstag omdirigeras för brett.

En kort testplan är vanligtvis tillräckligt:

• Positivt test: Ett internt namn från målzonen löser sig till den förväntade privata IP-adressen, till exempel server01.ad.firma.local.
• Negativt test: En opåverkad offentlig domän fortsätter att köras via den avsedda standardsökvägen, till exempel global DNS, DNS Protection eller en intern forwarder.
• Kundtest: Testet körs från den berörda VLAN, VPN profilen eller platsen, inte bara direkt på brandväggen.
• Loggkontroll: Brandväggslogg, DNS-logg eller Packet Capture visar att begäran når den förväntade resolvern.
• Regression: Efter en ändring till VPN, DHCP, DNS Protection eller platsdirigering upprepas samma test.

Detta lilla negativa test förhindrar typiska biverkningar: offentliga domäner besvaras internt, DNS Protection förbigås, split DNS fungerar bara från vissa nätverk eller en VPN-klient fortsätter att använda en gammal resolver.

Driftskontroll

DNS Request Routes bör vara så specifik som möjligt. En rutt för den exakta interna domänen är bättre än en konfiguration som är för bred. För större miljöer är det värt att ha kort dokumentation med domän, DNS server, plats och syfte så att senare ändringar kan spåras.

Praktisk dokumentation:

• Domän eller omvänd zon: till exempel ad.firma.local.
• Target Servers: till exempel 10.10.10.10 och 10.10.10.11.
• Syfte: till exempel Active Directory DNS för huvudwebbplatsen.
• Påverkade nätverk: till exempel LAN, Admin-VPN och Zürich plats.
• Beroenden: till exempel plats-till-plats VPN, domänkontrollant och brandväggsregel för DNS.
• Test: till exempel server01.ad.firma.local löser sig till den förväntade interna IP-adressen.
• Negativt test: till exempel example.com fortsätter att använda den avsedda standardsökvägen.

Felsökning

Om DNS inte fungerar bör du inte ändra DNS Request Route direkt. Ofta använder klienten en annan resolver, en brandväggsregel blockerar DNS eller så finns den omvända zonen inte på målservern.

Typiska misstag

• De interna kallas solver sig inte: Ofta är domänerna vaga, exemplet firma.local är lämpligt för ad.firma.local. Controllerdomäner i klienter för frågningsrutt och sökdomän.
• VPN-klienten löser inte interna namn: Klienten kanske inte använder brandväggen eller fel DNS-server. Kontrollera VPN-DNS inställningar, klient DNS och brandväggsregel.
• Brandväggen kan inte nå servern DNS: Rutt, VPN eller brandväggsregel saknas förmodligen. Kontrollera ping, Packet Capture och ruttsökning.
• Brandväggen löser sig externt men inte internt: DNS Request Route, kontrollera målservern och testa namnsökning. Använd sedan Packet Capture mot den interna DNS-servern.
• Omvänd sökning fungerar inte: PTR-zon eller PTR-poster saknas. Kontrollera zonen för omvänd sökning på den interna DNS-servern.
• Enskilda platser ger felaktiga svar: Felaktig målserver eller inaktuella zondata är sannolikt. Kontrollera ordningen på målservrarna och DNS-replikeringen.
• Allmänna namn besvaras plötsligt internt: Förfrågningsvägen är för bred. Använd mer specifik domän och undvik jokertecken.
• Första DNS-servern svarar NXDOMAIN: Brandväggen behandlar detta svar som giltigt och frågar inte automatiskt alla ytterligare målservrar. Kontrollera zonstatus och serverordning.
• DNS Protection fungerar inte för alla klienter: Kontrollera om klienter verkligen använder brandväggen som DNS-resolver eller om externa resolvers, DoH/DoT, lokala agenter eller manuella DNS-inställningar är i vägen.

För VPN-miljöer bör du också kontrollera om VPN-klienterna får rätt DNS-servrar och sökdomäner.

FAQ