Configurare le route delle richieste DNS su Sophos Firewall

Una DNS Request Route inoltra le query relative a un dominio o a una zona inversa specifica verso i server DNS selezionati. Un caso tipico è ad.example.com: il firewall risolve i nomi pubblici tramite i resolver abituali, ma invia ai domain controller le query destinate a questa zona interna.

La route si applica soltanto se Sophos Firewall elabora la query come server DNS. Se un client interroga direttamente un server DNS interno, entra in gioco la configurazione di inoltro di quel server, non la route delle richieste del firewall.

La zona di destinazione non deve necessariamente essere interna: una Request Route può anche inoltrare le query per determinati domini pubblici a un resolver nella propria rete. Questa scelta è utile quando il resolver è stato designato per gestire quei domini. L’elaborazione locale può ridurre le query DNS esterne; un miglioramento delle prestazioni o una maggiore riservatezza sono però possibili soltanto se il resolver di destinazione elabora le query di conseguenza, anziché limitarsi a inoltrarle inalterate a Internet.

Individuare il percorso DNS prima della modifica

Tre configurazioni apparentemente simili rispondono a esigenze diverse:

• Il client interroga il firewall: DHCP o il profilo VPN fornisce come server DNS l’indirizzo IP dell’interfaccia del firewall. Per accedere al servizio DNS locale, la zona del client deve essere autorizzata a usare DNS in Administration > Device access > Local service ACL. Le normali regole firewall non controllano l’accesso ai servizi ospitati sul firewall stesso.
• Il client interroga direttamente un server DNS interno: il resolver interno risponde per le zone locali e inoltra le altre query. Se il traffico attraversa zone diverse, può essere necessaria una normale regola firewall. Questo percorso del client non utilizza una route delle richieste configurata sul firewall.
• Il firewall interroga un server di destinazione interno: una route delle richieste seleziona il server di destinazione in base al dominio richiesto. Il routing verso il server e la sua raggiungibilità devono essere corretti.

Una DNS Host Entry, invece, consente al firewall di rispondere direttamente per un singolo nome. Per un numero limitato di record statici, consultare Configurare le DNS Host Entry su Sophos Firewall. Una route delle richieste è più adatta a un’intera zona gestita su un server DNS. Le opzioni DHCP stabiliscono invece quale server DNS e quale dominio di ricerca riceve il client; vedere Configurare le opzioni DHCP su Sophos Firewall.

⚠️ La route delle richieste viene selezionata in base al nome di dominio, non alla rete di origine del client. Se sedi diverse devono ricevere risposte differenti, tali viste devono essere fornite dai resolver coinvolti o da percorsi DNS separati. Una singola route non può generare risposte DNS dipendenti dall’origine.

Esempio e prerequisiti

Questo esempio inoltra una zona AD interna a due resolver:

• zona interna: ad.example.com
• server di destinazione primario: 10.10.10.10
• server di destinazione secondario: 10.10.10.11
• rete client: 10.20.30.0/24
• IP del firewall usato dal client come resolver: 10.20.30.1
• test positivo: dc01.ad.example.com
• test negativo: example.net

example.com e example.net sono domini riservati alla documentazione. Nella configurazione di produzione, sostituire la zona e gli indirizzi dei server e dell’interfaccia con i propri valori. Entrambi i server di destinazione devono essere autorevoli per la stessa zona e contenere gli stessi dati. Un lungo elenco di resolver non correlati non rappresenta una strategia di ridondanza affidabile.

Prima di creare la route, verificare quanto segue:

1. Il firewall è configurato come resolver in Network > DNS > DNS configuration.
2. I server di destinazione sono raggiungibili tramite il percorso di routing locale o VPN previsto.
3. I client a cui deve applicarsi la route utilizzano effettivamente l’IP del firewall come server DNS.
4. In Administration > Device access, DNS è abilitato soltanto per le zone client necessarie. Se non deve accedere l’intera zona, usare una Local Service ACL Exception più restrittiva.
5. La zona interna esiste sui server di destinazione e contiene un record noto da usare per il test.
6. Il percorso DNS attuale e le route delle richieste esistenti sono documentati per consentire il rollback.

Creare la DNS Request Route

1. In WebAdmin, aprire Network > DNS.
2. Passare alla sezione DNS request route.
3. Selezionare Add.
4. In Host/Domain name, inserire ad.example.com.
5. In Target servers, selezionare 10.10.10.10 e 10.10.10.11. Se gli oggetti server non esistono ancora, crearli come host IP con Create.
6. Controllare l’ordine. SFOS interroga gli host selezionati nell’ordine visualizzato.
7. Selezionare Save.

Sophos supporta fino a otto indirizzi IP di destinazione per ogni route delle richieste. L’aggiunta di server migliora la disponibilità soltanto se tutti rispondono correttamente per la stessa zona e sono raggiungibili tramite percorsi indipendenti realmente collaudati.

Quando una route delle richieste corrisponde al dominio e la cache non contiene una risposta adatta, SFOS invia la query ai Target Servers della route. Per quel dominio non ripiega sui forwarder globali o sui root server. Se tutti i server di destinazione sono irraggiungibili o configurati in modo errato per la zona, la risoluzione non riesce anziché passare, senza preavviso, a un resolver pubblico.

La nuova voce deve quindi comparire in DNS request route con il dominio e i server di destinazione previsti.

Valutare correttamente più server di destinazione

L’ordine documentato dei server è un meccanismo di disponibilità, non un metodo per conciliare dati DNS discordanti. Per i resolver statici globali, SFOS considera NXDOMAIN una risposta valida e non interroga il server successivo. La guida di SFOS 22 non conferma esplicitamente lo stesso comportamento per i Target Servers di una route delle richieste. Non bisogna quindi fare affidamento su un secondo server con dati di zona diversi, né garantire uno specifico comportamento di failover dopo una risposta NXDOMAIN.

Durante il collaudo, interrogare separatamente ciascun server di destinazione da un sistema di test autorizzato. Entrambi devono restituire la stessa risposta al test positivo. Anche un nome volutamente inesistente deve produrre lo stesso risultato su tutti e due i server. Questi controlli permettono di rilevare problemi di replica o di autorità della zona prima che il firewall debba passare da un server all’altro.

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

Queste query dirette verificano i dati della zona e la risposta di ciascun server, non la route delle richieste. Eseguirle soltanto da una rete che, in base alla progettazione DNS, è autorizzata a raggiungere entrambi i resolver. Interrogare quindi 10.20.30.1 per confermare che anche il firewall inoltri la zona ai server previsti.

Inoltrare le ricerche inverse

Per le query PTR, inserire in Host/Domain name la zona inversa, non la rete. Per 172.16.16.0/24, la classica zona inversa IPv4 è:

16.16.172.in-addr.arpa

Per 172.16.0.0/16, è:

16.172.in-addr.arpa

Non inserire nel campo del dominio una notazione CIDR come 172.16.16.0/24. Conta esclusivamente la zona effettivamente configurata sul server DNS interno. Una route delle richieste non crea record PTR. Se la zona o i record non sono presenti sul server di destinazione, la ricerca inversa continuerà a non riuscire. Le reti IPv4 con prefissi non allineati all’ottetto e le zone inverse IPv6 richiedono una progettazione specifica della delega DNS; non è sufficiente invertire il prefisso.

Il DNS inverso consente a registri e servizi di associare un indirizzo a un nome. Non può correggere una risoluzione diretta non riuscita di un FQDN e va quindi verificato separatamente.

Comprendere il percorso del resolver globale

In Network > DNS > DNS configuration si stabilisce come il firewall risolve le query che non corrispondono ad alcuna Host Entry o Request Route. A seconda dell’interfaccia, SFOS può ottenere i resolver tramite Obtain DNS from DHCP o Obtain DNS from PPPoE. Con Static DNS, impostare esplicitamente DNS 1, DNS 2 e, se necessario, DNS 3.

⚠️ Se Obtain DNS from DHCP è attivo e l’ultima interfaccia DHCP corrispondente viene disattivata o passa a un’altra modalità di assegnazione, SFOS seleziona Static DNS. Riattivando l’interfaccia, la selezione precedente non viene ripristinata automaticamente. Dopo ogni modifica alla WAN o alle interfacce, controllare quindi l’impostazione DNS.

Con Static DNS, il firewall interroga i server nell’ordine configurato. Passa al server successivo dopo un timeout, ma non dopo una risposta NXDOMAIN valida. Le risposte rimangono nella cache in base al rispettivo TTL. Un secondo resolver rappresenta pertanto una riserva in caso di irraggiungibilità, non una fonte alternativa di verità DNS.

Per i server DNS globali, SFOS 22 documenta quattro opzioni di selezione. Per le due priorità fisse devono essere configurati sia server DNS IPv4 sia server DNS IPv6:

• Choose a server based on incoming requests record type seleziona il server DNS in base al tipo di record richiesto, A o AAAA.
• Choose IPv6 DNS server over IPv4 dà priorità al server DNS IPv6 rispetto al server DNS IPv4.
• Choose IPv4 DNS server over IPv6 dà priorità al server DNS IPv4 rispetto al server DNS IPv6.
• Choose IPv6 if request originator address is IPv6, else IPv4 utilizza il server DNS IPv6 per una query proveniente da un indirizzo di origine IPv6 e il server DNS IPv4 per una query proveniente da un indirizzo di origine IPv4.

Il tipo di record e la famiglia dell’indirizzo di origine sono criteri distinti: una query AAAA non è automaticamente una query proveniente da un indirizzo di origine IPv6. La selezione avviene quindi in base al percorso del resolver previsto, non soltanto in base all’indirizzo desiderato nella risposta DNS. I resolver selezionati devono essere raggiungibili tramite la rispettiva famiglia di indirizzi. Queste opzioni globali non modificano la selezione dei Target servers di una Request Route in base al dominio.

Dopo aver selezionato Apply, usare Test name lookup per risolvere un nome host o un indirizzo IP dal punto di vista del firewall. Un nome di test interno può corrispondere a una route delle richieste. Il test, tuttavia, non conferma né il resolver configurato sul client né il percorso effettivamente seguito dalle sue query.

Se WebAdmin non è disponibile durante un ripristino pianificato, la CLI interattiva in 1. Network Configuration > DNS Configuration mostra i server DNS globali IPv4 e IPv6. Questa voce di menu non modifica le route delle richieste. Annotare tutti i valori visualizzati prima di inserire dati; premendo Enter senza un nuovo valore, la modifica viene ignorata. Per gli interventi da remoto, mantenere disponibile un percorso di gestione indipendente.

Integrare DNS Protection con le zone interne

Scegliere prima la versione: a partire da SFOS 23.0, utilizzare il percorso DoH integrato con DNS Protection in Network > DNS e l’assegnazione della Filtering Policy all’oggetto firewall. L’articolo su DNS Protection collegato di seguito descrive configurazione, decisione sul fallback, pilot e rollback. La successiva sequenza Location/DDNS e Static DNS si applica esclusivamente a Traditional DNS su SFOS 22 e versioni precedenti; non eseguirla anche per il percorso integrato di SFOS 23. Le Request Routes interne e le verifiche del percorso del client e del NAT rimangono rilevanti.

Con Sophos DNS Protection e Sophos Firewall, le query pubbliche vengono inviate a DNS Protection, mentre le route delle richieste indirizzano le zone interne ai resolver locali. Per prima cosa, registrare il firewall come posizione in Sophos Fusion (in precedenza Sophos Central). Se vengono utilizzati più indirizzi WAN pubblici, registrare tutti gli indirizzi interessati o l’intervallo appropriato. Per un indirizzo WAN dinamico, usare il nome host DDNS registrato.

La configurazione ufficiale Sophos imposta i due indirizzi di DNS Protection come DNS 1 e DNS 2 in Network > DNS > DNS configuration, lascia vuoto DNS 3, rimuove i server DNS IPv6 e seleziona Choose IPv4 DNS server over IPv6. Un terzo resolver o un resolver IPv6 indesiderato può consentire alle query di aggirare DNS Protection.

Sophos indica una configurazione DHCP specifica: in Network > DHCP > Server > Edit, lasciare disattivato Use device’s DNS settings. Impostare come Primary DNS l’IP del firewall sull’interfaccia DHCP e come Secondary DNS un indirizzo pubblico di DNS Protection. I client non gestiscono tutti allo stesso modo la presenza di più resolver; occorre quindi verificare che le query interne passino davvero attraverso il firewall. Le query inviate direttamente dal client a DNS Protection non utilizzano le route delle richieste locali del firewall.

Sophos descrive inoltre una regola DNAT che reindirizza le classiche query DNS in uscita dalle reti interne verso l’IP interno del firewall. Questo reindirizzamento è una decisione di sicurezza separata: non intercetta automaticamente DNS over HTTPS o DNS over TLS e può interferire con dispositivi specializzati. Introdurlo soltanto per reti di origine chiaramente definite, mai con la WAN come Inbound Interface, e predisporre eccezioni e un piano di rollback documentati.

Testare separatamente firewall e client

Vista del resolver del firewall

In Network > DNS > Test name lookup, verificare prima dc01.ad.example.com e poi example.net. Il nome interno deve restituire l’indirizzo interno previsto, mentre quello pubblico deve continuare a essere risolto tramite il percorso predefinito stabilito.

In 4. Device Console, il comando ufficialmente documentato offre la stessa prospettiva:

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

Questi controlli mostrano il risultato ottenuto dal resolver del firewall. Non dimostrano ancora che un client stia interrogando il firewall.

Confrontare singoli resolver in Diagnostics

In Diagnostics > Tools, SFOS 22 offre Name lookup con i campi IP address or hostname e DNS server IP. Un FQDN verifica la risoluzione diretta, mentre un indirizzo IPv4 o IPv6 verifica la risoluzione inversa. Selezionare un server configurato specifico oppure usare Lookup using all configured servers per confrontare le risposte e i tempi di risposta di tutti i resolver configurati. Un tempo di risposta breve, da solo, non giustifica una modifica dell’ordine dei server: occorre prima verificare che le risposte siano corrette per la zona prevista.

In SFOS 23, la sezione si chiama DNS lookup e i campi sono Hostname or IP address e DNS server IP address. Oltre a un server disponibile e a All configured servers, sono presenti le opzioni Custom DNS server e Custom DoH server; per ciascuna di queste ultime, inserire l’indirizzo IP del server desiderato. DNS Protection è selezionabile soltanto se DNS Protection è attivato in Network > DNS. Si tratta di un’opzione diagnostica, non di un invito a modificare la configurazione DNS esistente per eseguire un test.

Per i nomi di test interni, utilizzare soltanto resolver interni autorizzati, in modo che i nomi non vengano inviati a un servizio DNS o DoH pubblico. Una query mirata a un resolver ne conferma la risposta, non il percorso effettivo della Request Route o del client. Rimane quindi necessario eseguire il collaudo tramite l’IP del firewall e Packet Capture.

Verificare il percorso del client

Su un client di test, controllare innanzitutto il server DNS configurato, quindi interrogare esplicitamente l’IP 10.20.30.1 del firewall.

Windows:

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

macOS o Linux:

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

Ripetere poi le stesse query senza specificare un server. Se i risultati sono diversi, il client sta utilizzando un altro percorso di risoluzione, per esempio un’impostazione statica, un profilo VPN, DNS over HTTPS o un agente di sicurezza locale. Un dominio di ricerca è rilevante soltanto per i nomi brevi e non qualificati; i FQDN precedenti non ne hanno bisogno.

Acquisire i pacchetti sul percorso effettivo

In Diagnostics > Packet capture, limitare il traffico con un filtro sul client di test, sui server di destinazione e sulla porta 53. Eseguire una cattura dei pacchetti su Sophos Firewall descrive la procedura in dettaglio.

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

Individuare la query in ingresso dal client, quella generata dal firewall verso il Target Server corretto e le relative risposte. In questo modo, la cattura distingue un problema di accesso del client da un problema di routing o del server di destinazione. Poiché il buffer di acquisizione è limitato, mantenere il filtro specifico e registrare soltanto durante il test.

Se si utilizza DNS Protection, il collegamento ufficiale Check your configuration in My Products > DNS Protection > Installers offre un controllo aggiuntivo. La pagina di benvenuto conferma il percorso di DNS Protection, ma la zona interna, il percorso del client e la route delle richieste devono comunque essere testati separatamente.

Diagnosticare il problema in base al sintomo

Il firewall risolve il nome interno, ma il client no

• Verificare che il client utilizzi realmente l’IP del firewall come server DNS.
• In Administration > Device access, verificare che DNS sia consentito per la zona del client o tramite una Local Service ACL Exception appropriata.
• Inviare la query esplicitamente all’IP del firewall e verificarla con Packet Capture.
• Controllare le impostazioni DHCP, VPN e del resolver locale, oltre a DoH e DoT, per individuare percorsi alternativi.

Il firewall non raggiunge il server di destinazione

• Controllare Route Lookup e il percorso locale o VPN verso l’indirizzo di destinazione.
• Verificare sia la porta UDP 53 sia la porta TCP 53 lungo tutto il percorso fino al server, compresa l’ACL del server stesso.
• Interrogare direttamente il resolver e accertarsi che accetti le richieste provenienti dall’IP del firewall.
• In Packet Capture, cercare la query generata, una risposta o il motivo dello scarto.

Se i client interrogano direttamente il server DNS interno, occorre invece verificare il normale percorso di transito, comprese le zone e la relativa regola firewall. Verificare le regole firewall con Log Viewer, Policy Test e Packet Capture aiuta a distinguere questo caso.

Le risposte sono errate o incoerenti

• Dominio troppo ampio o errato: limitare la route delle richieste alla zona per cui il server è effettivamente autorevole.
• I server di destinazione restituiscono dati diversi: verificare direttamente su ogni server la replica DNS e l’autorità della zona.
• Risposta obsoleta: tenere conto del TTL e delle cache presenti su firewall, resolver e client.
• Non funzionano soltanto i nomi brevi: controllare il dominio di ricerca del client e testare separatamente il FQDN.
• La ricerca inversa non riesce: controllare la zona PTR e il record PTR sul server di destinazione.
• Il problema riguarda soltanto i client VPN: controllare i server DNS assegnati, il routing VPN e l’accesso al servizio DNS locale. Le impostazioni client pertinenti sono descritte in Configurare Sophos Connect e Configurare l’accesso remoto SSL VPN.

XML API: identificare la route tramite il nome dell’oggetto

A partire da SFOS 23, la documentazione XML API richiede sia Name sia DomainName per la creazione e la modifica di una DNS Request Route. Name identifica l’oggetto configurato, DomainName la zona DNS da inoltrare; ad esempio, Name = ad-intern e DomainName = ad.example.com. Questi sono valori dei campi, non XML eseguibile. Name è un singolo STRING con un massimo di 64 caratteri, consente UTF-8 e vieta le virgole. DomainName rimane FQDN con un massimo di 255 caratteri; anche i server di destinazione devono continuare a essere specificati.

Per l’eliminazione, la chiave documentata passa da DomainName in SFOS 22 a Name in SFOS 23. Non ripetere inalterate le vecchie richieste e non utilizzare automaticamente il nome di dominio come nome dell’oggetto. Prima dell’operazione, verificare la versione installata e leggere l’oggetto specifico, confrontare Name, DomainName, Target Servers e dipendenze con la destinazione prevista e documentare il rollback. In caso di ambiguità, interrompere l’operazione. Successivamente, verificare la risposta API e lo stato e rileggere la destinazione esatta: deve essere stata rimossa soltanto la route prevista; le altre route devono rimanere invariate. Quindi testare la risoluzione interna e pubblica come descritto sopra. Qui non viene inventato alcun envelope di eliminazione o schema REST e non viene dichiarato alcun test sul prodotto.

La configurazione globale del protocollo DNS è separata da queste impostazioni. L’articolo su DNS Protection spiega i conflitti irrisolti dello schema XML di SFOS 23 e il percorso WebAdmin sicuro; le quattro opzioni dei resolver descritte sopra esplicitamente per SFOS 22 non dimostrano alcuna corrispondenza numerica nell’API di SFOS 23.

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

Rollback e gestione operativa

Prima della modifica, annotare le route delle richieste esistenti, la selezione DNS globale, le autorizzazioni di Device Access e i risultati di un test positivo e di uno negativo. Per un normale rollback, rimuovere la route appena creata oppure ripristinare esattamente i valori documentati in precedenza. Riportare allo stato originale anche eventuali eccezioni ACL o reindirizzamenti DNS temporanei.

Verificare quindi nuovamente questi tre aspetti:

1. Il firewall risolve un nome interno e uno pubblico attraverso i rispettivi percorsi previsti.
2. Il client interessato utilizza il resolver previsto e riceve le risposte attese.
3. Un dominio non interessato dalla route non viene inviato al Target Server interno.

Un backup completo della configurazione non è uno strumento pratico per annullare la modifica di un solo oggetto. Il ripristino sostituisce l’intera configurazione e può sovrascrivere modifiche successive. Per una singola route delle richieste, è più sicuro annullare la modifica documentata a livello di oggetto.

Domande frequenti