Che cos'è il DNS forwarding? Come funziona e perché è importante
Che cos'è il DNS forwarding? Scopri in che modo i forwarder si differenziano dai resolver ricorsivi, come funzionano la caching e il failover, e dove si colloca il forwarding nelle reti moderne.
Published 23 ottobre 2026
L'inoltro DNS è il processo mediante il quale un resolver DNS invia la query di un client a un altro server DNS, il forwarder, invece di risolvere il nome direttamente tramite la gerarchia DNS. Il resolver locale può comunque rispondere dalla propria cache e applicare i criteri locali, mentre il resolver a monte esegue la ricerca completa quando necessario. Ma se il server a monte si guasta, quale parte del DNS risulta interrotta?
Questa distinzione è fondamentale quando si configura una rete o si tenta di spiegare perché un sito web non si carica. Un resolver di inoltro non si limita a trasmettere pacchetti: può rispondere alle richieste note a livello locale, reindirizzare query selezionate a server diversi e stabilire quale resolver possa visualizzare il traffico DNS di un utente.
Sommario
- Cosa significa effettivamente il DNS Forwarding
- Seguire una query dal client alla risposta
- In che modo il forwarding differisce dalla ricorsione e dal servizio autorevole
- Forwarding condizionale, Split Horizon e prevenzione dei loop
- Come il caching e il TTL influenzano le prestazioni di forwarding
- Scegliere tra forwarding, ricorsione con Root-Hints e DNS crittografato
- Implementare il forwarding sulla propria rete
Che Cosa Significa Effettivamente il Forwarding DNS
Immagina il resolver locale come la reception di un ufficio postale. Un client richiede un sito web indicandone il nome e il resolver verifica se conosce già la risposta. Se ha una risposta valida nella sua cache, la restituisce. In caso contrario, invia la query a un server DNS a monte, l'inoltratore, che gestisce la ricerca e restituisce una risposta.
Questa configurazione separa due compiti. Il resolver locale si interfaccia con i client della rete e può applicare regole locali. Il resolver a monte si fa carico del lavoro di risoluzione dei nomi a cui il server locale non può rispondere tramite la propria cache o i dati locali. L'inoltro è quindi una funzione architetturale, non automaticamente un prodotto di sicurezza.
Il DNS è nato nel novembere 1983, quando le specifiche RFC 882 e RFC 883 hanno introdotto un sistema di denominazione gerarchico per sostituire il modello HOSTS.TXT, ormai diventato ingestibile. Prima del DNS, gli amministratori si affidavano a mappature nome-indirizzo gestite manualmente. Nel novembre 1987, le specifiche RFC 1034 e RFC 1035 hanno sostituito quelle originali, diventando gli standard fondamentali per la moderna architettura DNS, come riportato nella cronologia della storia del DNS.
Dove incontrerai il forwarding
Router domestici, reti aziendali, WiFi pubblico, scuole e ambienti cloud possono utilizzare l'inoltro. Un'organizzazione potrebbe impiegarlo per inviare ricerche generali su Internet a un servizio ricorsivo gestito, mantenendo al contempo il controllo locale su caching, registrazione dei log, nomi interni o regole di blocco.
Il modello concettuale utile è semplice: il resolver locale è la reception controllata; il resolver a monte è lo specialista che effettua la ricerca completa. Questo modello facilita anche l'individuazione di un problema. Un client potrebbe raggiungere con successo la reception anche se il resolver a monte non è disponibile o restituisce un errore.
Seguire una Query dal Client alla Risposta
Una ricerca tipica inizia quando un dispositivo richiede un nome al proprio resolver locale. Il resolver controlla per prima cosa la propria cache. Se la risposta memorizzata è ancora valida, può restituirla senza contattare un server upstream. Se non è presente una risposta utilizzabile in cache, il resolver inoltra la query a un resolver ricorsivo upstream.
Nella terminologia DNS, l'inoltro prevede che un resolver invii una query con il bit recursion-desired (RD) impostato. Tale bit segnala che al resolver ricevente viene richiesto di risolvere la query, anziché limitarsi a ritrasmettere un pacchetto senza tale richiesta. La definizione del glossario della RFC 7719 distingue l'inoltro dalla semplice ritrasmissione cieca dei pacchetti.
In caso di mancato riscontro nella cache (cache miss), il resolver ricorsivo a monte svolge il lavoro di ricerca. Può utilizzare la propria cache o interrogare la gerarchia DNS per ottenere la risposta. La risposta torna quindi al client passando attraverso il resolver di inoltro.
I due percorsi possibili
- Cache hit: il resolver locale restituisce una risposta valida presente in cache. Il server upstream non viene coinvolto in quella ricerca.
- Cache miss: il resolver locale invia la query upstream, riceve la risposta e la restituisce al client.
Questo passaggio di consegne definisce anche un'utile separazione delle responsabilità. Il resolver locale può applicare controlli specifici per la rete, mantenere log, utilizzare regole split-DNS o applicare una policy di validazione DNSSEC. Il resolver upstream esegue la ricerca ricorsiva quando il resolver locale non è in grado di rispondere dalla propria cache o dai dati locali.
Indizio per la risoluzione dei problemi: se il resolver locale risponde ai client ma le ricerche falliscono quando la sua cache non contiene la risposta, verificare il percorso di forwarding e la risposta upstream prima di presumere che il servizio DNS autorevole sia difettoso.
Come il Forwarding Differisce dalla Ricorsione e dal Servizio Autorevole
L'inoltro DNS, la ricorsione, il proxying e il servizio autorevole descrivono ruoli diversi. Un singolo sistema può assumere più di un ruolo, ma i termini non sono intercambiabili. In una tipica configurazione di inoltro, il server locale serve i client e mantiene una cache o delle policy; un resolver ricorsivo a monte effettua la risoluzione in caso di mancato riscontro nella cache.
| Ruolo | Chi avvia | Esegue la ricerca completa | Contiene dati autorevoli | Sintomo di errore tipico |
|---|---|---|---|---|
| Forwarder | Un resolver locale gli invia una query | Di solito, quando agisce come resolver ricorsivo upstream | Non necessariamente | Timeout o errore dal servizio upstream |
| Resolver ricorsivo | Un client o un altro resolver richiede la risoluzione | Sì, utilizzando la cache o interrogando la gerarchia DNS | Non necessariamente | Errori di risoluzione, timeout o ricerche fallite |
| Proxy | Un client o un servizio gli invia traffico | Non di per sé; il proxy inoltra le richieste in base al suo funzionamento | No | La richiesta gestita dal proxy fallisce o non può raggiungere la destinazione |
| Server autorevole | Un resolver lo interroga per un dominio che gestisce | No, fornisce dati per la propria zona | Sì, per le zone che gestisce | Record mancanti, errati o non disponibili per tali zone |
La distinzione chiave della tabella riguarda chi effettua la ricerca completa. Un resolver di inoltro invia una query senza risposta a un altro server; un resolver ricorsivo gestisce la risoluzione, potenzialmente interrogando i server autorevoli. Un server autorevole fornisce i record per il dominio che gestisce anziché cercare nella gerarchia per conto di un client.
Perché la distinzione cambia la risoluzione dei problemi
Un resolver di inoltro può restituire un timeout a monte, un errore SERVFAIL o una risposta in cache non più adeguata, anche quando l'infrastruttura DNS autorevole funziona normalmente. In questa situazione, risolvere i problemi analizzando solo il server autorevole può portare sulla strada sbagliata. Verificare quale resolver ha ricevuto la richiesta, se disponeva di una risposta in cache e cosa è accaduto all'hop successivo.
Esiste anche una dipendenza di fiducia. L'oggetto RFC 7719 approfondisce la terminologia dei resolver, inclusa la distinzione tra forwarder e resolver ricorsivi. La ricerca sugli attacchi di cache poisoning distingue questi ruoli poiché un forwarder dipende dall'integrità del resolver a monte utilizzato. Se i controlli sui contenuti fanno parte dell'architettura, una rete può anche utilizzare il filtraggio DNS per applicare le policy alle query prima che i dispositivi si connettano alle destinazioni.
Forwarding Condizionale, Split Horizon e Prevenzione dei Loop
L'inoltro non deve necessariamente inviare ogni query senza risposta allo stesso server a monte. Con l'inoltro condizionale, un resolver invia le query per i domini selezionati a un server designato. Ad esempio, una rete può indirizzare le richieste di nomi interni a un servizio DNS interno e inviare le altre richieste a un resolver ricorsivo gestito.
Un concetto correlato è il DNS split-horizon. Consente a una rete di restituire risposte diverse per lo stesso nome a seconda della provenienza della richiesta. Un utente all'interno di un'organizzazione potrebbe ricevere una risposta interna, mentre un richiedente esterno ne riceve una diversa. Il resolver locale diventa un punto decisionale per mantenere i nomi interni sul percorso appropriato.
La configurazione deve chiarire quale resolver possiede ciascun percorso di query. Una regola che invia un nome interno al server upstream errato può produrre una risposta esterna, un errore di risoluzione o un risultato che differisce tra le diverse parti della rete.
Prevenire i loop dei resolver
Un loop di inoltro si verifica quando un resolver invia una query a un secondo resolver che, alla fine, gliela restituisce. La query può continuare a circolare tra i server, causando richieste ripetute, timeout ed esaurimento delle risorse. La soluzione consiste nel mappare i percorsi di inoltro e assicurarsi che nessuna catena di resolver rimandi a un server precedente.
Anche alcuni nomi richiedono un confine esplicito. La specifica RFC 9539 segnala namespace come home.arpa che non devono essere inoltrati oltre il loro ambito locale previsto. Un resolver che funziona correttamente finché non viene aggiunto un secondo forwarder potrebbe aver generato un loop; un nome locale che inizia a essere risolto pubblicamente potrebbe richiedere una regola di inoltro o di zona locale più specifica.
Il video qui sotto fornisce un'altra introduzione visiva ai concetti di inoltro DNS.
Come il Caching e il TTL Modellano le Prestazioni di Forwarding
La cache di un forwarder funziona come la memoria di un intermediario: una volta recuperata una risposta a monte, può rispondere in autonomia alla successiva domanda identica. Questo singolo comportamento spiega la maggior parte degli effetti dell'inoltro sulle prestazioni. Ogni hit di cache elimina un tempo di andata e ritorno (round trip) verso il resolver a monte. Ogni miss ne aggiunge uno ancora prima che la ricerca vera e propria abbia inizio.
Il time to live (TTL) di ciascun record stabilisce il limite di tale memoria. Il server autorevole pubblica il TTL e qualsiasi resolver lungo il percorso può riutilizzare la risposta in cache solo finché rimane valida. TTL brevi mantengono le risposte aggiornate ma inviano più query a monte. TTL lunghi riducono il traffico a monte ma possono far sì che i client mantengano indirizzi obsoleti dopo una modifica dell'infrastruttura.
Anche la cache si sovrappone lungo il percorso. Una query può essere servita dalla cache del client, dalla cache del forwarder o dalla cache del resolver a monte, e ogni livello esegue il proprio conto alla rovescia del TTL. Quando un utente segnala una risposta non aggiornata, la soluzione dipende da quale livello la sta conservando; pertanto, durante la risoluzione dei problemi, è opportuno trattare ogni cache come un elemento separato anziché svuotare semplicemente quella più vicina.
Misurare qualcosa in più rispetto alla latenza media
Il tempo medio di ricerca può nascondere problemi che influiscono su alcuni utenti o su alcune query più di altre. Monitora il tasso di cache hit, la latenza di ricerca mediana e di coda (tail latency), il tasso di timeout upstream e il comportamento della cache negativa. Queste misurazioni aiutano a distinguere un servizio upstream lento da un forwarder che continua a mancati accessi in cache o che gestisce male le ricerche fallite.
DNSSEC aggiunge un ulteriore elemento di complessità. Un resolver di validazione recupera firme e chiavi oltre alla risposta stessa, pertanto i mancati recuperi in cache per i nomi firmati richiedono più risorse rispetto a quelli non firmati. Le risposte convalidate e memorizzate in cache evitano questo lavoro ripetuto, rendendo il rapporto di hit ancora più importante sui percorsi di validazione.
Nessun valore singolo può prevedere il tempo di ricerca su una determinata rete. Il risultato dipende dallo stato della cache a ogni livello, dalla reattività a monte, dalle operazioni di convalida, dalla configurazione del trasporto e dai tentativi di nuovo invio dopo la mancata risposta di un forwarder. Un forwarder ben configurato trasmette inoltre i codici di risposta, i comportamenti di troncamento, i record DNSSEC e i flag senza modificarli, in modo che i client vedano la risposta inviata dalla parte autorevole.
Scegliere tra Forwarding, Ricorsione Root-Hints e DNS Crittografato
L'inoltro (forwarding) e la ricorsione tramite root-hints comportano compromessi differenti. Con l'inoltro, un'organizzazione seleziona resolver upstream gestiti per elaborare le query senza risposta. Questo approccio può semplificare le operazioni locali e centralizzare le policy, ma rende la rete dipendente dai servizi upstream prescelti. Con la ricorsione tramite root-hints, un resolver esegue direttamente la ricerca iterativa; ciò riduce la dipendenza da un singolo servizio ricorsivo upstream, ma attribuisce una maggiore responsabilità di risoluzione al resolver stesso.
| Scelta di architettura | Dove avviene la risoluzione | Principale compromesso operativo |
|---|---|---|
| Inoltro | Presso il resolver ricorsivo a monte selezionato | Gestione centralizzata, con dipendenza dal servizio a monte |
| Ricorsione root-hints | Presso il resolver ricorsivo locale, che interroga attraverso la gerarchia | Maggiore controllo locale, con maggiore responsabilità per la risoluzione diretta |
| DNS crittografato diretto dal client | Presso il resolver contattato dal client tramite una connessione crittografata | La rete locale potrebbe non visualizzare o controllare la query di dominio |
Il DNS crittografato rende questa scelta meno immediata. DNS over TLS e DNS over QUIC possono proteggere il traffico DNS in transito, ma il fattore cruciale è stabilire dove termini la crittografia. Se un client crittografa le query direttamente verso un resolver esterno, un forwarder locale potrebbe non visualizzare una query di dominio utilizzabile. Se la crittografia termina presso un resolver aziendale approvato, tale resolver può comunque applicare le policy di rete e inoltrare le query a monte.
Il WiFi pubblico richiede una policy deliberata
Gli operatori di reti WiFi pubbliche devono considerare anche i Captive Portal. I dispositivi potrebbero richiedere la risoluzione dei nomi prima dell'autenticazione e controlli di connettività prima che gli utenti possano accedere. Il DNS crittografato può complicare o ritardare il rilevamento del portale, quindi gli operatori devono decidere quali resolver sono approvati, come deve funzionare il fallback e se sono necessarie eccezioni.
Un servizio DNS protettivo può inserirsi nel percorso di risoluzione selezionato e valutare le ricerche prima che le connessioni abbiano inizio. Purple Shield è progettato per reti WiFi per ospiti e location, con filtraggio dei contenuti basato su categorie, blocco delle minacce a livello DNS e policy gestibili per singola rete. Può essere distribuito come servizio autonomo o integrato con le reti Purple Access. Per i team che valutano i controlli DNS rispetto a controlli più ampi sul traffico web, una panoramica sui secure web gateway descrive un livello di applicazione differente.
Mettere in Funzione il Forwarding sulla Tua Rete
L'inoltro concentra parte del carico di lavoro DNS sui servizi a monte selezionati da un'organizzazione. Le misurazioni effettuate utilizzando i dataset Day in the Life di DNS-OARC hanno rilevato che circa il 99% dei resolver ricorsivi ha generato volumi di query moderati, mentre circa l'1% ha mostrato un comportamento aggressivo. Quel gruppo più piccolo è stato responsabile di ben il 98% del traffico DNS osservato nel 2018 e del 93% nel 2019; i ricercatori hanno stimato che includesse circa 8.300 resolver nel 2018 e oltre 14.000 nel 2019 (studio sul comportamento aggressivo dei resolver). Un resolver locale può inviare richieste a servizi ricorsivi a monte che memorizzano nella cache e riutilizzano le risposte, ma ciò concentra l'affidamento sulla loro disponibilità e sul loro comportamento.
Prima di distribuire o modificare il forwarding, verificare che:
- Gli upstream sono indipendenti: configurare almeno due forwarder nei casi in cui l'architettura lo consenta.
- I guasti hanno una risposta definita: impostare il comportamento di timeout e di riprova, e sapere cosa ricevono i client se un upstream non risponde.
- Il monitoraggio copre i sintomi: monitorare le risposte SERVFAIL, i timeout e la latenza delle risposte.
- Le aspettative di privacy sono chiare: decidere quale resolver upstream può visualizzare le query inoltrate.
Se il filtraggio DNS fa parte della policy della tua rete ospiti, confrontalo con il tuo approccio di filtraggio dei contenuti WiFi più ampio. Successivamente, verifica a quale resolver la tua rete effettua l'inoltro e conferma che la sua policy, la disponibilità e la gestione della privacy corrispondano ai tuoi obiettivi.
Purple Shield controlla le ricerche DNS prima che i dispositivi si connettano e offre filtraggio dei contenuti e blocco delle minacce per le reti WiFi per ospiti e venue. Se desideri scoprire come l'inoltro può supportare questi controlli, visita Purple Shield per esplorare le relative opzioni di distribuzione.