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.

I percorsi e i campi di questa guida corrispondono a SFOS 22.0 MR2 Build 546. Nelle release precedenti le etichette possono differire leggermente.

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. Per l’inbound load balancing di un singolo nome sono supportati al massimo otto indirizzi; il firewall supporta in totale fino a 1024 DNS Host Entry.

Percorsi e ambito della risoluzione DNS

Per le richieste gestite dal firewall stesso si applicano le seguenti configurazioni:

• Se il nome richiesto corrisponde a una DNS host entry, il firewall risponde con l’indirizzo memorizzato nella voce.
• Se corrisponde una DNS request route, dopo un lookup della cache non riuscito il firewall interroga i relativi Target servers nell’ordine configurato. Per quel nome non torna ai forwarder o ai root server.
• Senza una voce locale o una Request Route corrispondente, utilizza i server specificati in DNS configuration. I server statici vengono interrogati in ordine fino all’arrivo di una risposta. NXDOMAIN è già una risposta valida, quindi il server successivo non viene interrogato.

La guida di SFOS 22 descrive separatamente la corrispondenza delle Host Entry e delle Request Route, ma non specifica il risultato quando lo stesso nome corrisponde a entrambe. Evitare questa sovrapposizione: mantenere la Host Entry fuori da una zona inoltrata oppure rimuovere la voce locale duplicata. Quindi interrogare esplicitamente l’IP del firewall per confermare la risposta prevista.

Questi percorsi di risoluzione si applicano solo quando il firewall è il resolver della richiesta. Un client che usa direttamente un domain controller, un resolver pubblico o DNS over HTTPS ignora queste voci. In Administration > Device access, DNS deve inoltre essere consentito per la zona sorgente o tramite una Local Service ACL Exception adatta; una normale regola firewall non controlla l’accesso a questo servizio locale.

I server DNS configurati hanno la precedenza sui root server per la risoluzione DNS generale tramite l’IP di un’interfaccia del firewall. Questo non garantisce che ogni richiesta non riuscita venga risolta tramite i root server. Le richieste che corrispondono a una Request Route rimangono indirizzate ai Target Servers definiti.

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, usare Test name lookup per verificare che il firewall restituisca l’indirizzo previsto per app01.corp.example. Diagnostics > Tools > Name lookup interroga invece un DNS server IP selezionato; Lookup using all configured servers confronta i server DNS configurati e i relativi tempi di risposta. Usare questo strumento solo per confrontare i server upstream, non per dimostrare che una Host Entry locale o una Request Route abbia trovato corrispondenza. 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.

Per consegnare i dati al supporto o confrontare lo stato prima e dopo la modifica, è anche possibile scaricare dnsd.log da Diagnostics > Tools > Troubleshooting logs. Un Consolidated troubleshooting report (CTR) contiene inoltre dati di stato e log. Poiché questi file possono includere dettagli sulla configurazione e sull’ambiente, vanno condivisi solo tramite un canale di supporto sicuro.

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.

Per due indirizzi WAN, mantenere lo stesso nome in una sola Host Entry: inserire, ad esempio, www.example.com in Host/Domain name e 192.0.2.10 come prima IP address, poi usare Add all’interno del modulo per aggiungere un secondo indirizzo e inserire 198.51.100.10. Questi sono indirizzi di documentazione da sostituire con gli indirizzi WAN effettivi. Attivare Publish on WAN per entrambi gli indirizzi previsti solo se sono soddisfatti i prerequisiti della sezione seguente, quindi salvare con Save. Due hostname diversi non fornirebbero il bilanciamento del carico per lo stesso servizio.

Nel flusso Multi-WAN documentato, il resolver esterno segue la delega NS e interroga il firewall tramite un link WAN attivo. Il firewall restituisce l’indirizzo WAN dell’interfaccia su cui è arrivata la richiesta, e il resolver trasmette questo indirizzo al client. Il successivo accesso all’applicazione è un flusso di dati distinto. Durante la verifica, interrogare separatamente entrambi i percorsi WAN e confrontare gli indirizzi restituiti; dopo un guasto del link, eseguire una nuova query DNS. Questo non elimina le risposte già nella cache prima della scadenza del loro TTL.

Weight è il peso relativo del link rispetto agli altri link nel WAN link manager. Non è un Health Check dell’applicazione. Durante la verifica, le nuove richieste DNS esterne devono restituire solo indirizzi WAN attivi; per ogni indirizzo restituito va quindi testata una nuova connessione applicativa. Una risposta 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.

Secondo Sophos, una regola DNAT e il weighted load balancing non possono essere configurati contemporaneamente per la stessa DNS Host Entry. La pubblicazione richiede quindi 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.

Un nome rimane nella cache come localhost troppo a lungo

Per i domini che si risolvono in localhost, Sophos Firewall non utilizza semplicemente il TTL del record DNS. Il firewall interroga nuovamente questi nomi secondo l’intervallo localhost-ttl. Il valore predefinito è 655360 secondi e l’intervallo consentito va da 60 a 655360 secondi. Quando un record passa da localhost a un altro host, il firewall può quindi conservare la vecchia risposta più a lungo rispetto a un normale client.

Prima si conferma con una query diretta al resolver autoritativo o previsto che il record non punti più a localhost. Quindi si legge il valore SFOS corrente nella Device Console:

show dns

Solo quando questo caso specifico è confermato si deve ridurre temporaneamente l’intervallo globale. I 300 secondi sono qui un esempio per un test di migrazione controllato, non una raccomandazione generale:

set dns localhost-ttl 300

Un valore inferiore genera query DNS più frequenti e non esegue un flush immediato della cache. Dopo la modifica si verifica nuovamente la risoluzione dal firewall e da un client reale. Se la riduzione era necessaria solo per la migrazione, si ripristina successivamente il valore predefinito del prodotto:

set dns localhost-ttl default

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.

XML API: nome dell’oggetto e nome DNS a partire da SFOS 23

Nell’automazione, Name e HostName sono campi distinti: Name identifica l’oggetto configurato, HostName il nome DNS da risolvere. La documentazione di SFOS 23 richiede entrambi i campi per la creazione e la modifica. Name è un singolo STRING con un massimo di 64 caratteri; UTF-8 è consentito, la virgola no. HostName rimane DOMAINNAMELOOKUP con un massimo di 253 caratteri. Ad esempio, Name = app01-intern e HostName = app01.corp.example possono avere valori diversi; questa è un’associazione di campi, non XML eseguibile.

Per l’eliminazione, SFOS 22 documenta HostName come chiave, mentre SFOS 23 documenta Name. Non ripetere quindi inalterate le vecchie richieste SFOS 22 e non utilizzare automaticamente il nome DNS come nome dell’oggetto. Prima di una chiamata di eliminazione, verificare la versione installata, leggere l’oggetto specifico e confrontare nome dell’oggetto, nome DNS, indirizzi e dipendenze con la destinazione documentata. Se l’identità non è univoca, interrompere l’operazione. Successivamente, verificare la risposta API e il relativo stato e rileggere la destinazione esatta: deve risultare assente soltanto l’oggetto previsto; le altre voci devono rimanere invariate. Il solo successo del trasporto non dimostra che l’eliminazione sia riuscita. Qui non viene fornito alcun envelope di eliminazione e non viene dichiarato alcun test sul prodotto.

Conflitto irrisolto sul DNS inverso: in entrambe le versioni, l’esempio API per AddReverseDNSLookUp mostra Enable/Disable, ma la tabella dei parametri consente soltanto Enable e indica contemporaneamente Disable come valore predefinito. Da ciò non si può ricavare una richiesta sicura con Disable o con omissione del campo. Fino a un chiarimento del produttore, non utilizzare una simile procedura API; impostare invece consapevolmente Reverse DNS nel flusso WebAdmin descritto sopra e verificare separatamente il PTR. Le istruzioni dell’interfaccia non confermano la semantica dei valori enum dell’API.

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

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