Configurare le rotte delle richieste DNS su Sophos Firewall

Con le rotte delle richieste DNS è possibile specificare su Sophos Firewall quale server DNS utilizzare per determinati domini o zone inverse. Questo è particolarmente utile quando il firewall utilizza server DNS pubblici, ma i nomi interni devono essere risolti tramite un server DNS interno.

Esempi tipici sono domini Active Directory, applicazioni interne, reverse lookup o ambienti VPN.

Quando si utilizza Sophos DNS Protection con Sophos Firewall, le rotte delle richieste DNS diventano ancora più importanti. I domini pubblici vengono inviati al servizio DNS Protection, mentre i domini interni continuano a essere risolti dal server DNS locale o dal Domain Controller. Senza questa separazione, le applicazioni interne, le autenticazioni AD o i reverse lookup possono sembrare problemi di rete.

Orientamento e design

Le DNS Request Routes funzionano in modo affidabile solo quando è chiaro quale resolver vede quale richiesta. Per questo è opportuno distinguere prima design DNS, DNS del client, zone interne e percorso di routing.

Rotta delle richieste DNS, server DNS o opzione DHCP?

Le rotte delle richieste DNS sono spesso confuse con server DNS globali o opzioni DHCP. Le funzioni risolvono problemi diversi.

Server DNS globali: Risoluzione standard del firewall DNS Internet, risoluzione FQDN generale, aggiornamenti e servizi cloud.
Rotta delle richieste DNS: inviare un dominio specifico o una zona di reverse a un server DNS definito Active Directory, domini interni, DNS di sede, Split DNS.
Opzione DHCP: distribuire server DNS o dominio di ricerca ai client i client devono utilizzare direttamente un server DNS specifico.

Una rotta delle richieste DNS non modifica automaticamente la configurazione DNS di tutti i client. La rotta controlla dove la Sophos Firewall stessa o i client che utilizzano il firewall come DNS forwarder inoltrano determinate richieste DNS. Se i client devono utilizzare direttamente un server DNS interno, è più adatta un’opzione DHCP su Sophos Firewall.

È importante anche la differenza rispetto a una DNS Host Entry: una DNS Host Entry risponde direttamente a un hostname specifico con un indirizzo IP sul firewall. Una DNS Request Route, invece, inoltra un dominio o una zona a un altro server DNS. Per Active Directory e zone interne dinamiche, una Request Route è quasi sempre più pulita di molte singole Host Entry.

Quale design DNS è adatto?

Prima di creare una rotta delle richieste DNS, è importante sapere quale resolver viene utilizzato nella rete specifica. La rotta è utile solo se la Sophos Firewall vede la richiesta.

I client interrogano la Sophos Firewall: Il firewall inoltra i domini pubblici globalmente e i domini interni tramite DNS Request Route. Questo è adatto a sedi piccole e medie, DNS Protection e reti guest o client.
I client interrogano direttamente i server DNS interni: Domain Controller o server DNS risolvono internamente e inoltrano esternamente. Questo è adatto a reti Active Directory classiche con Windows DNS come resolver centrale.
I client VPN interrogano il firewall: Il firewall utilizza Request Routes per i domini interni. Questo è adatto a Remote Access con un percorso DNS semplice tramite il firewall.
I client VPN interrogano direttamente i server DNS interni: Il DNS passa tramite VPN al Domain Controller o al server DNS. Questo è adatto ad ambienti AD più grandi quando i client devono usare la stessa logica DNS della LAN.

In ambienti misti, uno schema DNS breve è molto utile: rete client, server DNS assegnato, dominio di ricerca, zone DNS interne, rotte delle richieste DNS e percorso di routing al server di destinazione. Senza questa panoramica, spesso si lavora sulla rotta delle richieste anche se il client non utilizza affatto il firewall come resolver DNS.

Affinché le DNS Request Routes abbiano effetto sui client, Sophos Firewall deve trovarsi nel percorso delle query DNS. Questo può avvenire direttamente, se i client ricevono l’IP dell’interfaccia firewall come server DNS, oppure indirettamente, se un resolver interno inoltra consapevolmente al firewall. Se i client interrogano direttamente un Domain Controller, il firewall non vede questa richiesta DNS come resolver e non può reindirizzarla tramite Request Route.

Quando sono necessarie le rotte delle richieste DNS?

Le rotte delle richieste DNS sono utili quando:

devono essere risolti nomi host interni come server01.firma.local
devono funzionare i reverse lookup per reti IP interne
gli utenti VPN devono utilizzare nomi interni
più sedi hanno proprie zone DNS
il firewall stesso deve raggiungere sistemi interni tramite FQDN
i server DNS pubblici non conoscono nomi interni

Senza una rotta delle richieste DNS, il firewall interroga il server DNS configurato globalmente. Se il dominio interno non è noto lì, la risoluzione fallisce.

Questa differenza è particolarmente importante per l’accesso remoto. Se i client VPN utilizzano il firewall come server DNS, una rotta delle richieste DNS può garantire che i domini interni finiscano comunque nel giusto Domain Controller o server DNS. Se invece i client VPN ricevono direttamente server DNS interni, è necessario verificare anche che il routing, le regole del firewall e i suffissi DNS sul client siano corretti.

Prerequisiti

Accesso al WebAdmin di Sophos Firewall
Sophos Firewall è configurato correttamente come resolver DNS o forwarder DNS in Network > DNS > DNS configuration
Il server DNS interno è raggiungibile
Il dominio o la rete è noto
Le regole del firewall consentono il traffico DNS al server di destinazione
In caso di collegamento tra sedi: il routing al server DNS funziona
Il client interessato utilizza il firewall come server DNS o riceve consapevolmente un altro server DNS

⚠️ I problemi DNS spesso sembrano problemi di routing, VPN o applicazioni. Prima di apportare modifiche significative, è consigliabile verificare se il server di destinazione è raggiungibile tramite IP e se solo la risoluzione dei nomi fallisce.

Sotto Network > DNS > DNS configuration si dovrebbe inoltre verificare come il firewall risolve le sue normali richieste DNS. Se viene usata DNS Protection, lì sono presenti gli indirizzi IP di DNS Protection. Se si usano forwarder classici o resolver interni, questi server devono essere raggiungibili. Con Test name lookup si può verificare direttamente nella configurazione DNS se il firewall riesce in linea di principio a risolvere un nome o un IP.

Configurare una DNS Request Route

La configurazione è tecnicamente semplice, ma diventa rapidamente poco chiara quando si combinano domini, zone reverse, client VPN e più sedi.

Creare una rotta delle richieste DNS per un dominio

Una rotta di dominio garantisce che le richieste per un dominio specifico vengano inviate a un server DNS definito.

Esempio:

Nome host/dominio: firma.local
Server DNS: 10.10.10.10

Procedura:

Accedere a Sophos Firewall.
Aprire Network > DNS.
Passare alla sezione DNS request route.
Selezionare Add.
In Host/domain name inserire il dominio interno, ad esempio firma.local.
In Target servers selezionare il server DNS interno o crearlo come host tramite Create.
Salvare.

Il valore in Host/domain name deve essere scritto come FQDN o nome di zona, non come URL, regola wildcard o descrizione libera. L’API Sophos tratta questo valore come campo FQDN con una lunghezza massima di 255 caratteri. Per le normali route di dominio basta ad esempio firma.local; per i reverse lookup si usa la zona in-addr.arpa corrispondente.

Se sul firewall manca un hit nella cache DNS, la richiesta corrispondente per questo dominio non viene inviata ai forwarder normali o ai root server, ma ai Target Servers della Request Route. È voluto: le zone interne non devono essere interrogate accidentalmente all’esterno. Significa però anche che un Target Server scelto male può rispondere correttamente alla richiesta ma essere comunque sbagliato dal punto di vista funzionale.

Sophos Firewall - Aggiungi rotta richiesta DNS con server DNS interno — Sophos Firewall - Network > DNS > Add DNS request route

Utilizzare più server di destinazione

In Target servers è possibile aggiungere più di un server DNS. Questo è utile se ci sono più server DNS interni o se il DNS deve essere raggiungibile in modo ridondante tramite una connessione tra sedi.

Possibili server di destinazione:

server DNS interni nella rete locale
server DNS dall’altra parte di una connessione VPN
server DNS in un’altra sede
server DNS pubblici, se un dominio specifico deve essere risolto esternamente

L’ordine è rilevante. Il firewall interroga gli host selezionati nell’ordine in cui appaiono nella lista. Per ogni rotta delle richieste DNS possono essere memorizzati fino a otto indirizzi IP. Tuttavia, più server di destinazione non significano automaticamente una migliore ridondanza, se i server hanno stati di zona diversi, inoltri diversi o raggiungibilità diversa tramite VPN.

Sophos Firewall - Panoramica di una rotta delle richieste DNS per avanet.local — Sophos Firewall - Network > DNS > Rotta delle richieste DNS

Con più server di destinazione, non solo si dovrebbe inserire la ridondanza, ma anche verificare la responsabilità. Se il primo server DNS conosce la zona ma fornisce voci obsolete, la rotta delle richieste funzionerà tecnicamente ma fornirà comunque risposte errate dal punto di vista funzionale.

Un NXDOMAIN è una risposta DNS valida. Se il primo server DNS raggiungibile dice che un nome non esiste, il firewall non interroga automaticamente il server successivo sperando in una risposta diversa. Per questo i Target Servers della stessa DNS Request Route dovrebbero avere lo stesso stato di zona e gli stessi inoltri.

Split DNS per VPN e sedi

Lo Split DNS significa che lo stesso nome viene risolto in modo diverso a seconda della sede o della rete. Un portale interno può, ad esempio, puntare a un IP privato internamente, mentre lo stesso nome esternamente punta a un indirizzo pubblico o non viene risolto affatto.

Su Sophos Firewall, tre punti sono cruciali:

La rotta delle richieste DNS appropriata per il dominio interno.
Una regola del firewall che consente il DNS dal firewall o dal client al server DNS interno.
Un percorso di routing al server DNS, specialmente in caso di VPN site-to-site, SSL VPN o Sophos Connect.

Per ambienti di accesso remoto, è inoltre necessario verificare quali server DNS e domini di ricerca riceve il client. Per Sophos Connect, si adatta Configurare Sophos Connect su Sophos Firewall. Per configurazioni SSL VPN classiche, si adatta Configurare l’accesso remoto SSL VPN su Sophos Firewall.

Con DNS Protection si aggiunge un’ulteriore domanda di design: Sophos consiglia di configurare i dispositivi di rete in modo che usino il firewall come resolver DNS. A tale scopo, nei server DHCP del firewall viene normalmente distribuito l’IP dell’interfaccia firewall come server DNS. Se i dispositivi usano comunque resolver esterni, si può pianificare una regola NAT mirata per il traffico DNS in uscita verso il firewall. Questo dovrebbe avvenire consapevolmente e non in modo generalizzato, perché reindirizzamenti DNS rigidi possono influenzare troubleshooting, dispositivi BYOD, DoH/DoT e dispositivi speciali.

Se il firewall stesso usa DNS Protection come forwarder, gli indirizzi IP di DNS Protection copiati da Sophos Central devono essere inseriti in Network > DNS > DNS configuration come server DNS primario e secondario. Un terzo server DNS diverso o un percorso DNS IPv6 non voluto può fare in modo che le richieste aggirino DNS Protection. Per questo DNS Request Routes, opzioni DNS DHCP, impostazioni DNS IPv6 e regole NAT DNS opzionali dovrebbero essere verificati come un unico design.

Reverse DNS per reti interne

Una rotta delle richieste DNS inversa inoltra le richieste PTR per una rete IP interna al server DNS che conosce la zona di reverse lookup appropriata. Questo è utile quando log, report o servizi devono trasformare un indirizzo IP in un nome host.

Esempio:

Rete: 172.16.16.0/24
Server DNS: 172.16.16.10
Zona inversa: 16.16.172.in-addr.arpa

Per i reverse lookup, si crea anche una rotta delle richieste DNS sotto Network > DNS > DNS request route. In Host/domain name non si inserisce il dominio normale, ma la zona inversa.

Esempio per 172.16.16.0/24:

16.16.172.in-addr.arpa

L’ordine degli ottetti è invertito. Dalla rete 172.16.16.0/24 diventa 16.16.172.in-addr.arpa. Importante: in Host/domain name non si inserisce una notazione CIDR come 172.16.16.0/24, ma una zona DNS. Il valore dovrebbe quindi apparire come un nome di dominio o di zona inversa, non come una descrizione libera.

Per reti più grandi, la zona inversa può essere più ampia. Esempio: Per 172.16.0.0/16 sarebbe 16.172.in-addr.arpa. È fondamentale come è stata creata la zona di reverse lookup sul server DNS interno.

Se sul server DNS interno non esiste una zona PTR o record PTR, la rotta delle richieste non aiuta. Il firewall può solo inviare la richiesta al server DNS corretto, ma non genera voci DNS inverse sul server DNS.

In ambienti IPv6 con prefisso del provider, è importante considerare anche il DNS in anticipo. Come i client ottengono il loro indirizzo IPv6 e quale ruolo giocano Router Advertisement e DHCPv6 è spiegato in Configurare la delega del prefisso IPv6 su Sophos Firewall.

Test e operatività

Dopo la configurazione, si dovrebbero testare separatamente raggiungibilità IP, risoluzione DNS e DNS del client. Così si capisce più rapidamente se il problema riguarda davvero la Request Route.

Test e validazione

Dopo la configurazione, è consigliabile testare la risoluzione dei nomi:

Il firewall può risolvere il nome interno?
Network > DNS > Test name lookup funziona per un nome interno e uno pubblico?
La risoluzione funziona dalle zone VPN o utente?
Il server DNS è raggiungibile tramite Ping o TCP/UDP 53?
Ci sono voci nel log DNS o del firewall?

Se la risoluzione non funziona, è consigliabile verificare prima:

Il dominio è scritto correttamente?
Il client utilizza davvero Sophos Firewall o il server DNS corretto?
Una regola del firewall blocca il DNS?
Manca una rotta al server DNS?
Il server DNS risponde alle richieste dal firewall?

Un test sensato separa la raggiungibilità IP e la risoluzione DNS:

Testare il sistema di destinazione tramite IP, ad esempio Ping, porta TCP o applicazione.
Raggiungere il server DNS stesso tramite IP.
Risolvere il nome tramite la fonte DNS prevista.
Solo successivamente testare l’applicazione tramite il nome.

Se l’accesso tramite IP funziona, ma tramite nome no, il focus è su rotta delle richieste DNS, suffisso DNS, DNS client o reverse lookup. Se l’accesso tramite IP fallisce già, è consigliabile verificare prima routing, regola del firewall, NAT o VPN. Per questa delimitazione, aiutano Testare la regola del firewall con Log Viewer, Policy Test e Packet Capture e Verificare le cause per cui la regola di Sophos Firewall non si applica.

Comandi di test per firewall e client

Su Sophos Firewall, la Device Console può aiutare a testare il DNS dal punto di vista del firewall:

dnslookup server01.firma.local
dnslookup example.com

Sui client, è consigliabile verificare anche quale resolver viene effettivamente utilizzato.

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> rappresenta l’indirizzo dell’interfaccia interna di Sophos Firewall nella rete specifica. Se la richiesta contro il firewall funziona, ma la normale richiesta del client no, il problema è solitamente DHCP, profilo VPN, suffisso DNS, resolver locale o comportamento DNS del browser/sistema. Se anche la richiesta contro il firewall fallisce, i prossimi punti di controllo sono rotta delle richieste, server di destinazione, routing o regola del firewall.

Per client con browser moderni o agent endpoint, si dovrebbe inoltre verificare se DNS-over-HTTPS o un agente di sicurezza locale aggirano la normale richiesta DNS. In tal caso, il firewall potrebbe non vedere alcuna richiesta DNS classica su UDP/TCP 53, anche se la configurazione di rete sembra corretta.

Definire test positivi e negativi

Una DNS Request Route è testata correttamente solo quando funziona il nome interno desiderato e viene verificato anche un controesempio. Altrimenti non è chiaro se la route intercetta esattamente la zona interna o se il DNS viene reindirizzato in modo troppo ampio.

Di solito basta un breve piano di test:

Test positivo: un nome interno della zona di destinazione risolve l’IP privata attesa, ad esempio server01.ad.firma.local.
Test negativo: un dominio pubblico non coinvolto continua a usare il percorso standard previsto, ad esempio DNS globale, DNS Protection o forwarder interno.
Test client: eseguire il test dal VLAN, profilo VPN o sito interessato, non solo direttamente sulla firewall.
Controllo log: firewall log, DNS log o Packet Capture mostrano che la query raggiunge il resolver previsto.
Regression: ripetere lo stesso test dopo modifiche a VPN, DHCP, DNS Protection o routing del sito.

Questo piccolo test negativo evita effetti collaterali tipici: domini pubblici risposti internamente, DNS Protection aggirata, Split-DNS funzionante solo da alcune reti o client VPN che usa ancora un vecchio resolver.

Controllo operativo

Le rotte delle richieste DNS dovrebbero essere il più specifiche possibile. Una rotta per il dominio interno esatto è migliore di una configurazione troppo ampia. Per ambienti più grandi, vale la pena mantenere una piccola tabella con dominio, server DNS, sede e scopo, in modo che le modifiche successive siano tracciabili.

Documentazione pratica:

Dominio o zona inversa: ad.firma.local
Server di destinazione: 10.10.10.10, 10.10.10.11
Scopo: DNS Active Directory per sede principale.
Reti interessate: LAN, Admin-VPN, sede di Zurigo.
Dipendenze: VPN site-to-site, Domain Controller, regola del firewall DNS.
Test: server01.ad.firma.local si risolve sull’IP interno previsto.
Test negativo: ad esempio, example.com continua a usare il percorso standard previsto.

Troubleshooting

Se il DNS non funziona, non si dovrebbe modificare subito la Request Route. Spesso il client usa un resolver diverso, una regola firewall blocca il DNS oppure la zona reverse non esiste sul server di destinazione.

Errori tipici

Il nome interno non si risolve: dominio errato, ad esempio firma.local invece di ad.firma.local Verificare il dominio nella rotta delle richieste e il dominio di ricerca del client.
Il client VPN non risolve i nomi interni: Il client non utilizza il firewall o il server DNS errato Verificare le impostazioni DNS VPN, DNS client e regola del firewall.
Il firewall non può raggiungere il server DNS: Manca una rotta, VPN o regola del firewall Verificare Ping, Packet Capture e Route Lookup.
Il firewall risolve nomi esterni, ma non interni: Verificare DNS Request Route, Target Server e Test name lookup. Poi usare Packet Capture verso il server DNS interno.
Il reverse lookup non funziona: Mancano zona PTR o record PTR Verificare la zona di reverse lookup sul server DNS interno.
Singole sedi forniscono risposte errate: Server di destinazione errato o dati di zona obsoleti Verificare l’ordine dei server di destinazione e la replica DNS.
I nomi pubblici vengono improvvisamente risolti internamente: La rotta delle richieste è troppo ampia Utilizzare un dominio più specifico ed evitare il pensiero wildcard.
Il primo server DNS risponde NXDOMAIN: Il firewall tratta questa risposta come valida e non interroga automaticamente tutti gli altri Target Servers. Verificare stato della zona e ordine dei server.
DNS Protection non agisce per tutti i client: Verificare se i client usano davvero il firewall come resolver DNS o se resolver esterni, DoH/DoT, agent locali o impostazioni DNS manuali sono in mezzo.

In ambienti VPN, è consigliabile verificare anche se i client VPN ricevono i server DNS e i domini di ricerca corretti.

FAQ

Quando è necessaria una rotta delle richieste DNS su Sophos Firewall?

Una rotta delle richieste DNS è utile quando determinati domini o zone inverse non devono essere risolti tramite i server DNS globali del firewall, ma tramite server DNS interni. Casi tipici sono Active Directory, applicazioni interne, VPN e collegamenti tra sedi.

Una rotta delle richieste DNS sostituisce le opzioni DHCP-DNS?

No. Una rotta delle richieste DNS controlla l’inoltro di specifiche richieste DNS. Le opzioni DHCP distribuiscono invece server DNS o domini di ricerca ai client. A seconda del design, entrambe le funzioni vengono combinate.

Perché il DNS non funziona tramite VPN anche se esiste la rotta delle richieste?

In tal caso, il client VPN potrebbe non utilizzare la fonte DNS prevista, non avere un dominio di ricerca appropriato, non raggiungere il server DNS o essere bloccato da routing e regole del firewall. È consigliabile verificare separatamente se l’accesso tramite IP funziona e se la richiesta DNS arriva davvero al server corretto.

Sono necessarie le rotte delle richieste DNS per i reverse lookup?

Sì, se le richieste PTR per reti interne devono andare a un server DNS interno. Per questo, la zona in-addr.arpa appropriata viene inserita come nome host/dominio. Tuttavia, la zona deve essere presente sul server DNS interno.

Sono necessarie le rotte delle richieste DNS con Sophos DNS Protection?

Sì, se i client o il firewall devono risolvere domini interni. DNS Protection non conosce le zone AD locali, i domini delle applicazioni interne e le zone inverse. Queste richieste dovrebbero essere inviate tramite rotta delle richieste DNS a server DNS interni.

Perché il firewall non vede la richiesta DNS?

Di solito, il client non utilizza Sophos Firewall come server DNS. In tal caso, le rotte delle richieste DNS sul firewall non aiutano direttamente. È consigliabile verificare le opzioni DHCP, il profilo VPN, le impostazioni DNS manuali del client, i forwarder DNS interni e i resolver alternativi.