Che cos'è il DNS ricorsivo: come funziona e perché è importante
Che cos'è il DNS ricorsivo? Scopra come un resolver risponde alle ricerche, utilizza la memoria cache e dove si inseriscono i controlli di sicurezza, con esempi chiari.
Published 2 novembre 2026
Un resolver DNS ricorsivo è il server che accetta una ricerca di nome dal dispositivo e trova l'indirizzo IP corrispondente per suo conto interrogando altri server DNS, quindi memorizza la risposta per riutilizzarla.
Supponiamo che Lei abbia modificato un'impostazione sul Suo WiFi per ospiti WiFi, ma che un visitatore riesca ancora a raggiungere un sito che intendeva bloccare. Prima di modificare nuovamente il firewall, verifichi quale resolver utilizza il suo dispositivo e se la Sua politica si applica alle risposte in cache. Questi dettagli spesso spiegano il divario tra la modifica di una regola e il suo effettivo funzionamento.
Sommario
- Cosa fa un resolver DNS ricorsivo per il Suo dispositivo
- Confronto tra server DNS ricorsivi e autorevoli
- Come una ricerca ricorsiva percorre la gerarchia DNS
- Caching, TTL e tempo necessario per le modifiche
- Filtraggio e sicurezza a livello di resolver
- Interruzioni di servizio, risposte non aggiornate e incomprensioni comuni
- Verificare quale resolver utilizza la rete prima di modificarlo
Cosa fa un resolver DNS ricorsivo per il Suo dispositivo
Un resolver DNS ricorsivo individua le risposte DNS per un dispositivo, in modo simile al concierge di un hotel che contatta diversi reparti invece di inviare l'ospite da uno sportello all'altro. L'ospite pone una domanda e si aspetta una risposta, non le istruzioni per proseguire la ricerca.
Supponiamo che l'ospite di un hotel apra il proprio laptop e inserisca l'indirizzo di un sito web. Se il laptop non dispone già di una risposta utilizzabile a livello locale, invia una richiesta di ricerca al servizio DNS configurato. Tale servizio può essere fornito dalla rete dell'hotel, dal provider Internet o da un resolver configurato separatamente.
I ruoli alla base di una ricerca
- Client: il dispositivo o l'applicazione che richiede una risposta DNS.
- Resolver ricorsivo: il servizio responsabile della ricerca e della restituzione di tale risposta.
- Server autorevole: il server che pubblica i record DNS ufficiali per il dominio richiesto.
L'analogia del concierge rende più semplice separare tali responsabilità.
Affinché la ricerca dell'indirizzo vada a buon fine, il dispositivo riceve un indirizzo IP e un valore di time-to-live, solitamente abbreviato in TTL. Tale valore indica ai sistemi di memorizzazione nella cache per quanto tempo possono riutilizzare la risposta. Il browser può quindi utilizzare l'indirizzo per iniziare a contattare la destinazione.
Ricorsivo non significa ripetizione all'infinito. Descrive la responsabilità che il resolver si assume: trovare la risposta finale per il client oppure restituire un errore appropriato se non è in grado di farlo.
Solitamente l'ospite dell'hotel non sa che tutto questo stia accadendo. Non ha bisogno di scegliere i server root o di capire chi ospita il DNS del sito web.
Una verifica utile della comprensione è semplice: il dispositivo richiede un indirizzo, il resolver lo trova e il browser lo utilizza per avviare una connessione.
Confronto tra server DNS ricorsivi e autorevoli
Resolver ricorsivo e server autorevole
| Criterio | Resolver ricorsivo | Server autorevole |
|---|---|---|
| Funzione principale | Trova le risposte per i client interrogando altri server | Pubblica i record ufficiali per i domini di cui è responsabile |
| Origine delle risposte | La propria cache o i server DNS upstream | I propri record di zona |
| Gestore tipico | Fornitore di servizi Internet, servizio di resolver pubblico, proprietario della rete | Proprietario del dominio o provider di hosting |
| Contattato direttamente dai dispositivi | Sì | Di norma no; viene contattato dai resolver |
| Memorizza in cache le risposte per altri domini | Sì, in base al TTL e alle regole di cache locali | No, non nell'ambito del suo ruolo autorevole |
La distinzione fondamentale è tra recupero e autorità. Un resolver ricorsivo recupera le informazioni per conto di altri. Un server autorevole pubblica le informazioni per un dominio sotto la propria responsabilità.
Tale differenza è fondamentale durante la risoluzione dei problemi. Se tutti ricevono l'indirizzo errato per il sito web della Sua organizzazione, occorre verificare i record autorevoli. Se invece solo i visitatori di una rete specifica riscontrano problemi, è necessario esaminare il resolver di tale rete, la sua cache e le sue policy.
Gli operatori possono sovrapporsi senza unificare i ruoli
Un provider Internet potrebbe gestire il DNS ricorsivo per gli abbonati, mentre un provider di hosting pubblica il DNS autorevole per i clienti. Il proprietario di una rete può anche gestire un resolver interno per i dispositivi del personale.
La stessa organizzazione e a volte lo stesso software server possono svolgere entrambi i compiti. Un server potrebbe rispondere in modo autorevole per un dominio interno e contemporaneamente risolvere nomi Internet non correlati per i dipendenti. Il ruolo appartiene alla richiesta in fase di gestione, non solo al nome dell'azienda sul servizio.
L'inoltro aggiunge un'ulteriore distinzione. Un server DNS locale può passare le richieste a un resolver a monte anziché contattare direttamente la gerarchia. Comprendere l'inoltro DNS Aiuta a identificare quale servizio esegue la ricerca esterna.
Un server autorevole non è normalmente il punto di controllo per il filtraggio dei contenuti del visitatore. Pubblica i record del dominio, anziché applicare le regole di rete del visitatore.
Domanda diagnostica: questo server sta rispondendo da record di cui è responsabile o sta cercando record per conto di un client?
Porre questa domanda è più utile che presumere che tutti i server etichettati come DNS svolgano le medesime funzioni.
Come una ricerca ricorsiva percorre la gerarchia DNS
Si consideri una ricerca per www.example.com quando né il dispositivo né il relativo resolver dispongono delle informazioni necessarie per rispondere.
Il dispositivo invia una query ricorsiva, richiedendo al proprio resolver un risultato finale. Di norma, il resolver effettua query iterative a monte: i server root e di dominio di primo livello forniscono i reindirizzamenti, mentre il server autorevole fornisce il record richiesto.
Questo diagramma mostra il percorso complessivo prima dei singoli scambi.
Segua la richiesta e la risposta
Il dispositivo contatta il proprio resolver configurato. Invia il nome del sito web poiché necessita di un indirizzo prima di poter contattare la destinazione.
Il resolver controlla la propria cache. Una risposta memorizzata in cache e utilizzabile interrompe immediatamente la ricerca. Non c'è motivo di richiedere ai server upstream informazioni che il resolver può ancora riutilizzare.
In caso di cache miss, interroga un root server. Il root server lo indirizza verso i server responsabili del dominio di primo livello pertinente, in questo caso .com.
Interroga un server .com. Tale server individua i name server autorevoli per example.com, restringendo la ricerca alle autorità designate del dominio.
Interroga un server autorevole. Il server autorevole restituisce il record dell'indirizzo richiesto e il relativo TTL, espresso in secondi.
Memorizza e restituisce la risposta. Il resolver conserva una copia riutilizzabile e invia il risultato al dispositivo.
Le richieste successive possono utilizzare la copia in cache. Finché la risposta rimane utilizzabile, il resolver non deve ripetere il percorso upstream per lo stesso nome e tipo di record.
La gerarchia distribuisce la responsabilità. I root server individuano le autorità dei domini di primo livello, tali autorità individuano i server dei nomi a dominio e gli amministratori di dominio mantengono i record di destinazione.
Una risposta salvata in cache è comunque una risposta legittima
La risposta del resolver è normalmente non autorevole. Ciò significa che sta ritrasmettendo informazioni anziché rispondere come autorità del dominio, non che la risposta sia inaffidabile.
Alcune implementazioni inoltrano la richiesta a un servizio ricorsivo upstream, che esegue questo lavoro per loro conto. Inoltre, un resolver con referral in cache può saltare parti del percorso illustrato.
Anche le regole della cache locale sono importanti. Le note di APNIC di RIPE 91 identificano timer di cache massimi del resolver comunemente osservati di 6 ore, 12 ore, 24 ore e 7 giorni, mostrando per quale motivo gli amministratori non dovrebbero presupporre che ogni resolver segua limiti di cache identici.
Per un'ulteriore panoramica sul processo di ricerca, questo video illustra la risoluzione DNS.
Caching, TTL e tempo necessario per una modifica
Un dominio viene bloccato alle 09:00 e un laptop sulla stessa rete lo apre ancora alle 09:40. Questo intervallo è dovuto al riutilizzo della cache. Il TTL funziona come la data di scadenza del ticket di un parcheggio: indica al resolver per quanto tempo può continuare a fornire una risposta salvata prima di doversi rivolgere di nuovo a monte per effettuare una nuova richiesta.
Per un normale record in cache, il valore determinante è la durata residua. Il temporizzatore massimo della cache di un resolver può ridurre tale durata, mentre un minimo applicato a livello locale può estenderla. I valori massimi riscontrati nei resolver includono 6 ore, 12 ore, 24 ore e 7 giorni, secondo le note di APNIC ricavate da RIPE 91. Queste impostazioni regolano la freschezza dei record. Esse determinano il tempo necessario per l'applicazione di un blocco solo quando la struttura di filtraggio si basa sull'aggiornamento della risposta DNS anziché sulla verifica della policy corrente.
Impostazioni della cache e relativo significato per un nuovo blocco
| Impostazione cache | Valore tipico | Effetto su un nuovo blocco o modifica |
|---|---|---|
| TTL pari a zero secondi | Nessuna durata riutilizzabile | In condizioni normali di gestione del TTL, la richiesta successiva avvia una ricerca a monte |
| TTL breve | Da pochi secondi a diversi minuti | Le modifiche ai record diventano visibili poco dopo ogni aggiornamento |
| Timer massimo della cache del resolver | 6 ore | Limita la conservazione per i record il cui TTL dura di più |
| Timer massimo della cache del resolver | 12 ore | Tronca i TTL dei record più lunghi a mezza giornata |
| Timer massimo della cache del resolver | 24 ore | Consente a una risposta di persistere durante la notte, fino a un'intera giornata |
| Timer massimo della cache del resolver | 7 giorni | Consente la conservazione per una settimana solo laddove lo permetta anche il TTL del record |
Separare le modifiche ai record dalle modifiche alle policy
Supponiamo che l'indirizzo autorevole di un sito cambi un minuto dopo che un resolver ha memorizzato in cache la vecchia risposta. Tale resolver può continuare a restituire il vecchio indirizzo fino al termine della durata effettiva, ovvero il valore inferiore tra il TTL del record e il limite massimo del resolver stesso, adeguato a un eventuale minimo applicato. Con un TTL del record di 24 ore e un limite di 6 ore, gli utenti raggiungono il nuovo indirizzo entro sei ore. Con un TTL del record di 7 giorni in presenza di un limite di 7 giorni, l'attesa può estendersi a un'intera settimana.
Ora l'indirizzo rimane lo stesso, ma un team di sicurezza contrassegna il dominio come dannoso. Un resolver che ricontrolla la politica attuale prima di fornire una risposta in cache blocca il dominio al controllo successivo. Una configurazione che la rivaluta solo quando la risposta si aggiorna lascia il percorso aperto per il resto della durata effettiva, il che potrebbe significare un giorno di esposizione su un limite di 24 ore.
Regola pratica: Chiedere quando il resolver aggiorna la sua risposta DNS e quando rivaluta la sua decisione di filtraggio. Una modifica raggiunge gli utenti nel più tardo di questi due momenti.
Per le modifiche urgenti, testare sia un dominio interrogato in precedenza che uno non presente in cache. Monitorare i cache hit, il volume delle query upstream e l'invio degli aggiornamenti dei criteri come misurazioni separate. Una nuova ricerca rapida non dice nulla sugli utenti che conservano ancora una risposta in cache.
Filtraggio e sicurezza a livello di resolver
Un resolver può applicare regole alle ricerche che riceve prima che il dispositivo avvii una connessione. Tuttavia, la sola ricorsione non fornisce tali regole. La classificazione dei contenuti, la threat intelligence e le verifiche di autenticità del DNS sono funzionalità distinte.
Il filtraggio dei contenuti definisce le regole di accesso
Il filtraggio DNS basato su categorie consente al proprietario di una rete di decidere quali destinazioni gli utenti possono raggiungere. Un'attrazione per famiglie potrebbe limitare i contenuti per adulti sul WiFi per ospiti WiFi mantenendo al contempo regole diverse per una rete amministrativa.
Prima che un dispositivo apra un sito o un'app, chiede al DNS dove trovarlo e noi rispondiamo applicando il criterio della rete su cui si trova il dispositivo. Ciò rende fondamentale l'identità della rete, non solo il dominio richiesto.
Le funzioni principali restano distinte anche quando vengono fornite da un unico servizio.
La difesa dalle minacce valuta la destinazione
I controlli sulle minacce possono rifiutare le ricerche per domini noti di phishing e malware. La nostra difesa dalle minacce blocca inoltre i callback di comando e controllo dai dispositivi infetti direttamente alla ricerca, impedendo che tali tentativi di connessione vengano avviati attraverso quel percorso di risoluzione.
Si tratta di un contenimento utile, ma non rimuove il malware dal dispositivo. La protezione degli endpoint e i controlli del firewall svolgono comunque le rispettive funzioni.
DNSSEC verifica l'autenticità, non la sicurezza
La convalida DNSSEC utilizza un trust anchor configurato e una catena di firme crittografiche per autenticare i dati DNS firmati. La norma RFC 4033 descrive la convalida sicura e specifica che un resolver orientato alla sicurezza deve considerare la validità della firma al momento di selezionare la durata della cache, tenendo conto di eventuali imprecisioni dell'orologio.
Gli amministratori necessitano quindi di un'ora di sistema accurata e di una gestione della cache che preservi lo stato di convalida. Un resolver deve distinguere i dati legittimamente non firmati dai dati firmati che non superano la convalida.
- Controllo preventivo: il filtraggio può arrestare una ricerca indesiderata prima che la connessione abbia inizio, ma solo per le richieste che utilizzano quel resolver.
- Regole coerenti: i dispositivi che utilizzano la stessa norma di rete ricevono un trattamento coerente, ma i percorsi di risoluzione alternativi richiedono controlli separati.
- Verifica dell'autenticità: DNSSEC aiuta a rilevare risposte firmate contraffatte, ma non crittografa le query né determina se un dominio è malevolo.
Un dominio di phishing correttamente firmato rimane pur sempre un dominio di phishing. Il filtraggio stabilisce se l'accesso debba essere consentito; DNSSEC stabilisce se le informazioni DNS firmate siano autentiche.
Interruzioni di servizio, risposte obsolete e concetti errati comuni
Un utente ospite apre un sito web mentre il relativo server DNS autorevole non è raggiungibile, ma la pagina si carica comunque. Il resolver potrebbe disporre di una risposta in cache non ancora scaduta, quindi non ha bisogno di contattare il server autorevole per questa richiesta.
Alcuni resolver possono anche fornire risposte non aggiornate (stale) dopo la normale scadenza quando i server upstream non sono disponibili. Si tratta di una strategia di disponibilità, non della prova che i record DNS rimangano aggiornati a tempo indeterminato. La guida esplicativa sul DNS di Cloudflare illustra la distinzione fondamentale tra il resolver che recupera le informazioni e il server autorevole che le fornisce.
Le risposte memorizzate in cache spiegano perché un'interruzione di un server autorevole non si trasforma sempre in un'interruzione immediata della navigazione.
La disponibilità e la protezione richiedono scelte esplicite
I resolver possono memorizzare nella cache anche i risultati negativi. La memorizzazione nella cache negativa conserva le informazioni relative, ad esempio, all'inesistenza di un nome, evitando ricerche ripetute per lo stesso nome mancante. Dopo che un amministratore ha creato tale nome, alcuni client potrebbero continuare a ricevere il risultato negativo memorizzato nella cache fino alla sua scadenza.
La gestione dei guasti solleva una questione di politica distinta. Una struttura di filtraggio fail-open consente la risoluzione senza i normali controlli delle politiche quando tali controlli non sono disponibili. Una struttura fail-closed rifiuta le richieste che non può approvare, preservando la restrizione ma interrompendo potenzialmente gli accessi legittimi.
I problemi di convalida DNSSEC rappresentano un altro caso distinto. Gli operatori non devono trattare i dati firmati non validi come autenticati al solo scopo di garantire il caricamento di una pagina.
Presupposti che causano errori operativi
- La ricorsione implica automaticamente il blocco: la ricorsione recupera le risposte; gli amministratori aggiungono il blocco mediante un livello di policy.
- Un filtro DNS controlla ogni connessione: gli indirizzi di destinazione hardcoded e alcuni percorsi VPN possono ignorare completamente la ricerca protetta.
- La modifica del DNS di rete sposta istantaneamente ogni client: le impostazioni esistenti, i lease DHCP e le scelte del resolver a livello di browser possono lasciare i dispositivi su un altro percorso.
Quando si analizza un'interruzione, occorre distinguere tra un'autorità non raggiungibile, un record scaduto, una risposta negativa, un errore di convalida e un rifiuto dovuto ai criteri. All'utente ospite possono sembrare simili, ma richiedono soluzioni diverse.
La ricorsione sposta le risposte. Le policy e la resilienza determinano quali risposte la rete fornirà al variare delle condizioni.
Confermare quale resolver utilizza la rete prima di modificarlo
Se Lei si sta chiedendo che cos'è il DNS ricorsivo perché sta per modificare una rete attiva, inizi mappando il percorso attuale. Registri la configurazione funzionante in modo da poterla ripristinare qualora i test evidenzino una dipendenza da nomi interni o da applicazioni.
Verificare il percorso prima del rollout
- Individuare il servizio DNS configurato del dispositivo. Utilizzare le relative impostazioni di rete o uno strumento di ricerca DNS. L'indirizzo di un router può rappresentare un servizio di inoltro, pertanto è opportuno tracciare anche la sua destinazione upstream.
- Ispezionare le impostazioni DHCP e del controller. Verificare quale resolver viene pubblicizzato dalla rete e se i client configurati manualmente lo rispettano.
- Definire per iscritto la politica richiesta. Identificare le categorie di contenuti, i controlli anti-malware, la registrazione delle ricerche e le differenze tra l'accesso del personale e quello degli ospiti.
- Scegliere un comportamento di aggiornamento accettabile. Specificare i ritardi tollerabili per l'aggiornamento dei record e delle politiche, oltre alla risposta prevista in caso di guasti del servizio.
- Effettuare un progetto pilota su una rete limitata. Testare i siti consentiti, le destinazioni bloccate, le risorse interne e il ripristino prima di estendere la modifica.
L'implementazione consiste in un'impostazione DNS per rete o in una modifica DHCP sul controller, senza installare nulla sui dispositivi client. Questo copre i dispositivi che seguono la configurazione DNS della rete, piuttosto che garantire che ogni applicazione la utilizzi.
Testare le VPN e il DNS over HTTPS, che possono creare percorsi di risoluzione alternativi. Il nostro team mostrerà come la rete gestisce le VPN e il DNS crittografato prima di una prova.
Un resolver ricorsivo con criteri è la scelta giusta quando la rete necessita di filtraggio prima dell'avvio delle connessioni e il proprietario ne accetta i comportamenti di cache e di errore.
Purple Shield offre DNS protettivo, filtraggio dei contenuti, difesa dalle minacce e blocco degli annunci a livello DNS per il WiFi per ospiti e pubblico WiFi senza agenti sui dispositivi. Visiti Purple Shield per discutere del percorso del resolver della Sua rete, delle politiche necessarie e di come testare l'applicazione prima di implementare una modifica DNS.