Configurare e testare le DNS Host Entry su Sophos Firewall

Una DNS Host Entry consente a Sophos Firewall di rispondere direttamente a un hostname specifico con un indirizzo IP configurato. È adatta a pochi sistemi interni fissi, ad esempio un’appliance, un servizio di gestione o il nome di un server che il firewall stesso deve risolvere.

La voce ha effetto solo se la richiesta DNS raggiunge effettivamente il firewall. Se un client usa un domain controller, un resolver pubblico o DNS over HTTPS, il firewall non vede la richiesta come resolver DNS. Una DNS Host Entry non sostituisce inoltre un oggetto di regola, il routing, il NAT o una regola firewall.

⚠️ Publish on WAN rimane disattivato per le voci interne. La pubblicazione su Internet richiede un design DNS autoritativo consapevole, record NS adeguati, un Device Access strettamente limitato e un test negativo della ricorsione. Un’autorizzazione DNS ACL dalla WAN non è da sola un motivo per esporre pubblicamente il servizio DNS.

DNS Host Entry in otto passaggi

1. Verificare che il nome sia statico e che non sia necessario inoltrare un’intera zona DNS interna.
2. Controllare che i client interessati utilizzino effettivamente Sophos Firewall come server DNS.
3. Documentare FQDN, indirizzo di destinazione, versione IP, TTL e un record PTR opzionale.
4. Inserire il nome e l’indirizzo in Network > DNS > DNS host entry > Add.
5. Lasciare Publish on WAN disattivato per una voce interna.
6. Controllare la vista del firewall in Network > DNS > Test name lookup.
7. Dal client interrogare esplicitamente l’IP del firewall e testare la risoluzione diretta e, se necessaria, quella inversa.
8. Solo a quel punto testare l’applicazione effettiva e documentare la voce con le relative dipendenze.

Quando è adatta una DNS Host Entry

Una DNS Host Entry è adatta a un singolo nome stabile, la cui risposta deve essere gestita direttamente sul firewall. Alcuni esempi tipici sono:

• un’appliance interna senza un proprio record DNS;
• un FQDN di gestione fisso per LDAP, RADIUS o un altro servizio;
• un singolo hostname per una migrazione controllata;
• un servizio pubblico con inbound DNS load balancing pianificato consapevolmente su più indirizzi WAN.

Per un intero dominio, Active Directory o zone interne gestite dinamicamente, una DNS Request Route è più ordinata. Inoltra la zona al server DNS responsabile invece di gestire singolarmente ogni nome sul firewall.

Anche un IP Host o FQDN Host svolge una funzione diversa. Questi oggetti vengono usati nelle regole firewall e NAT, ma non rispondono alle richieste DNS di un client. Usare correttamente IP Host, Services e Groups spiega i tipi di oggetto.

Una configurazione Dynamic DNS, invece, aggiorna un nome presso un provider esterno quando cambia un indirizzo WAN. La procedura completa è descritta in Configurare Dynamic DNS su Sophos Firewall.

SFOS supporta i tipi di record A, AAAA e PTR per le DNS Host Entry. La funzione non è quindi un server DNS autoritativo completo per CNAME, MX, TXT o SRV. Ogni DNS Host Entry supporta al massimo otto indirizzi; il firewall supporta in totale fino a 1024 DNS Host Entry.

Esempio e valori da sostituire

L’esempio rappresenta un singolo application server interno:

• Hostname: app01.corp.example
• Indirizzo IPv4: 192.0.2.20
• Rete client: 10.20.30.0/24
• IP del firewall come server DNS: 10.20.30.1
• Client di test: 10.20.30.50
• TTL: 300 secondi
• Publish on WAN: disattivato
• Reverse DNS: attivato facoltativamente

La zona .example e 192.0.2.0/24 sono riservate alla documentazione. In un ambiente di produzione, FQDN, indirizzo, rete client e IP del resolver devono essere sostituiti con i valori effettivi. Il nome deve essere coerente con la strategia di naming interna e non deve sovrascrivere involontariamente una zona autoritativa esistente.

Il TTL di 300 secondi è un valore di esempio controllato per test e migrazioni, non una raccomandazione universale. Un TTL breve accelera le modifiche pianificate, ma genera più richieste DNS. Un TTL lungo riduce le richieste, ma mantiene più a lungo nelle cache le vecchie risposte dopo una modifica.

Creare la DNS Host Entry

In Network > DNS, scorrere fino a DNS host entry e selezionare Add:

1. Inserire app01.corp.example in Host/Domain name.
2. Utilizzare un indirizzo IP come Entry type.
3. Inserire 192.0.2.20 in IP address.
4. Inserire 300 in Time-to-live.
5. Non trattare Weight come strumento di bilanciamento quando è presente un solo indirizzo.
6. Lasciare Publish on WAN disattivato.
7. Attivare Add reverse DNS lookup for this host entry solo se il firewall deve fornire anche una risposta PTR per questo indirizzo.
8. Salvare con Save.

Per un indirizzo IPv4, il firewall restituisce una risposta A; per un indirizzo IPv6, restituisce una risposta AAAA. Il reverse lookup opzionale associa nuovamente l’indirizzo al nome come PTR. Non crea tuttavia alcun record PTR su un domain controller o un server DNS esterno.

Se più hostname puntano allo stesso indirizzo IP, solo uno di essi può fungere da destinazione inversa. Prima di attivare l’opzione deve quindi essere chiaro quale nome sia previsto come risposta PTR canonica.

Utilizzare un’interfaccia invece di un indirizzo fisso

Come Entry Type è possibile selezionare un’interfaccia invece di un IP fisso. Questa soluzione è adatta quando la risposta deve seguire intenzionalmente l’indirizzo attuale dell’interfaccia, ad esempio in un design Multi-WAN pubblico pianificato.

La selezione di un’interfaccia non sostituisce la verifica del percorso WAN effettivo. Dopo una modifica dell’indirizzo, un cambio di link o un failover HA, è necessario testare nuovamente la risposta DNS, il servizio raggiungibile e il percorso di ritorno con una nuova connessione.

Testare la risoluzione sul firewall e sul client

Per prima cosa, in Network > DNS > Test name lookup verificare che il firewall restituisca l’indirizzo previsto per app01.corp.example. Se Reverse DNS è attivato, interrogare anche 192.0.2.20.

Questo test conferma solo la vista del resolver del firewall. Successivamente, il client interessato deve interrogare esplicitamente l’IP del firewall 10.20.30.1.

Windows:

nslookup app01.corp.example 10.20.30.1
nslookup 192.0.2.20 10.20.30.1

Linux o macOS:

dig @10.20.30.1 app01.corp.example A
dig @10.20.30.1 -x 192.0.2.20

La risposta deve contenere il record previsto, l’indirizzo corretto e, per il reverse lookup, il nome desiderato. Successivamente si testa l’applicazione tramite FQDN. Una risposta DNS corretta non dimostra ancora che routing, regola firewall, NAT, certificato TLS e servizio funzionino.

Se non è chiaro se la richiesta raggiunge il firewall, utilizzare un filtro ristretto in Diagnostics > Packet capture, ad esempio:

host 10.20.30.50 and port 53

La richiesta e la risposta devono essere visibili sull’interfaccia prevista. Packet Capture su Sophos Firewall spiega in dettaglio l’acquisizione e l’analisi sicure.

Utilizzare più indirizzi e pesi in modo consapevole

Una DNS Host Entry può contenere fino a otto indirizzi. La funzione è pensata per inbound DNS load balancing o failover su più link WAN, non per una raccolta casuale di server interni.

I valori Weight determinano la proporzione con cui le risposte vengono distribuite tra i link indicati. Questo comportamento deve essere verificato con richieste DNS ripetute e connessioni reali all’applicazione. La distribuzione delle risposte DNS da sola non conferma né la raggiungibilità del servizio pubblicato né un percorso DNAT e di ritorno corretto.

Più indirizzi non diventano automaticamente un Health Check generale per le applicazioni interne. In un design pubblico, Sophos documenta il failover per un’interfaccia non raggiungibile o guasta. Ciò non garantisce che un’interfaccia WAN raggiungibile eroghi correttamente anche il servizio applicativo dietro di essa.

Weighted DNS e la configurazione DNAT generata da Server Access Assistant non devono essere pianificati contemporaneamente come un meccanismo condiviso per la stessa DNS Host Entry. La pubblicazione richiede un design coerente di risposta DNS, indirizzo WAN, DNAT, regola firewall, TLS e percorso di ritorno. Pubblicare un server tramite DNAT spiega separatamente il percorso dei dati.

Utilizzare Publish on WAN solo per design autoritativi

Publish on WAN da solo non è sufficiente per una risposta pubblica. Affinché Sophos Firewall risponda come Name Server per un servizio pubblicato, la zona autoritativa deve essere delegata a nomi di server DNS i cui record A/AAAA o glue puntino agli indirizzi WAN previsti.

Sono inoltre necessari i seguenti elementi:

1. Il dominio pubblico e la zona DNS responsabile sono documentati in modo univoco.
2. La delega NS e i relativi record di indirizzo o glue conducono agli indirizzi WAN previsti.
3. In Administration > Device access, DNS è consentito solo tramite la zona WAN necessaria o una Local Service ACL Exception ristretta.
4. Publish on WAN è attivato solo per gli indirizzi previsti.
5. Il nome pubblicato viene testato positivamente da un resolver esterno.
6. I nomi non autoritativi e le richieste ricorsive vengono testati negativamente dall’esterno.
7. DNAT, regola firewall, certificato e percorso di ritorno del servizio effettivo vengono verificati separatamente.

Un’ulteriore DNS ACL Exception non restringe un’autorizzazione ampia della zona WAN già attiva. DNS rimane disattivato per WAN nella matrice e viene consentito tramite un’eccezione mirata, oppure l’autorizzazione più ampia viene documentata come esposizione consapevole. Device Access e Local Service ACL spiega come gestire questo livello evitando il lockout amministrativo.

Se la delega, l’ambito delle risposte o la protezione dall’uso ricorsivo non possono essere verificati chiaramente, Publish on WAN non viene attivato. Per le normali zone DNS pubbliche, un servizio DNS autoritativo dedicato è generalmente la soluzione più chiara.

Circoscrivere gli errori in base al sintomo

Il firewall risolve, ma il client no

• Verificare quale server DNS sia effettivamente configurato sul client. DHCP può distribuire l’IP del firewall; la procedura è descritta in Configurare DHCP Server su Sophos Firewall.
• Controllare DNS over HTTPS, le impostazioni del client VPN e i resolver statici del client come percorsi alternativi.
• In Administration > Device access, controllare se DNS è consentito dalla zona del client.
• Utilizzare Packet Capture per confermare che richiesta e risposta attraversino il firewall.
• Non modificare routing o NAT finché il client non interroga affatto il firewall.

Il client riceve ancora il vecchio indirizzo

• Controllare la voce attuale per individuare errori di battitura, hostname duplicati e indirizzi multipli.
• Considerare il vecchio TTL ancora valido e le cache locali, del browser o dell’applicazione.
• Inviare una nuova richiesta esplicita all’IP del firewall invece di ricaricare soltanto l’applicazione.
• Prima di una migrazione pianificata, ridurre il TTL con sufficiente anticipo e attendere la completa scadenza del TTL precedente.

Lo svuotamento della cache può correggere un singolo client di test, ma non modifica le risposte negli altri resolver o nelle cache applicative. Non sostituisce quindi un’attesa controllata e un test lungo la catena DNS effettivamente utilizzata.

Il reverse lookup manca o mostra il nome errato

• Controllare se Add reverse DNS lookup for this host entry è attivato.
• Assicurarsi che più nomi non rivendichino lo stesso indirizzo come destinazione PTR.
• Inviare esplicitamente la richiesta inversa all’IP del firewall.
• Per una zona inversa interna su un domain controller, utilizzare la DNS Request Route appropriata invece di una voce PTR locale.

La richiesta pubblica non riceve risposta

• Controllare dall’esterno la delega NS e la raggiungibilità degli indirizzi WAN.
• Verificare Publish on WAN per ogni indirizzo previsto.
• Controllare Device Access, Local Service ACL, i filtri upstream e la porta 53 UDP e TCP.
• Registrare un Packet Capture durante una singola richiesta esterna controllata.
• Non attivare un’autorizzazione DNS ampia come tentativo di risoluzione.

DNS è corretto, ma l’applicazione rimane irraggiungibile

DNS fornisce solo l’indirizzo di destinazione. Seguono routing, regola firewall, NAT, TLS e il servizio effettivo. Il test deve quindi verificare in sequenza indirizzo IP, porta e protocollo applicativo. Per problemi di regole e percorso è utile Testare una regola firewall con Log Viewer, Policy Test e Packet Capture.

Modifiche, HA e rollback

Prima di una modifica vengono documentati nome, risposta attuale, TTL, reverse lookup, resolver usati dai client e servizi dipendenti. Con più indirizzi, lo stato iniziale comprende inoltre pesi, associazione WAN, delega NS, DNAT e percorso di ritorno.

In un cluster HA, dopo un failover pianificato viene eseguita una nuova richiesta DNS. In caso di pubblicazione, vengono testati anche entrambi i percorsi WAN e un nuovo flusso applicativo. L’articolo non presuppone cache DNS sincronizzate né una connessione attiva senza interruzioni.

Per il rollback:

1. Prima di una migrazione pianificata, ridurre il TTL e attendere la scadenza del TTL precedente.
2. Documentare le applicazioni dipendenti e il percorso DNS pubblico.
3. Ripristinare indirizzo, interfaccia o Host Entry allo stato iniziale confermato.
4. Rimuovere un’eccezione temporanea di Device Access e la pubblicazione WAN non più necessaria.
5. Inviare nuovamente una richiesta esplicita dal firewall e dal client.
6. Ripetere il test di forward lookup, PTR opzionale, raggiungibilità e applicazione effettiva.

Checklist

• Sophos Firewall vede la richiesta DNS del client interessato.
• Un singolo nome statico è più adatto di una DNS Request Route.
• FQDN, versione IP, indirizzo e TTL sono documentati.
• Publish on WAN rimane disattivato per le voci interne.
• Una voce PTR è attivata solo per il nome canonico dell’indirizzo.
• Firewall e client restituiscono la stessa risposta prevista.
• L’accesso DNS è limitato alle sorgenti necessarie in Device Access.
• Con più indirizzi sono stati testati pesi, stato dei link e percorso applicativo.
• Per la pubblicazione WAN sono documentati delega NS, indirizzi dei server DNS e un test negativo della ricorsione.
• Il rollback e il tempo di attesa delle cache sono noti prima della modifica.

Domande frequenti