Che cos'è una ricerca DNS e perché le reti la utilizzano
Che cos'è una ricerca DNS, come funzionano le fasi di risoluzione e perché quel momento rappresenta un controllo pratico di sicurezza e prestazioni sul WiFi condiviso.
Published 24 ottobre 2026
Un lookup DNS è il modo in cui un resolver trova le informazioni associate a un nome di dominio leggibile dall'uomo, solitamente un indirizzo IP. Il processo classico verifica le informazioni locali, individua i server migliori, invia loro una query per ottenere una risposta, quindi restituisce e memorizza in cache il risultato.
Potresti stare leggendo questo contenuto connesso al WiFi di un hotel, di una scuola o di un ospedale dopo aver digitato l'indirizzo di un sito noto. Il tuo dispositivo è connesso, ma prima che la pagina possa caricarsi, la rete deve individuare dove risiede quel sito. Considera il DNS come una directory distribuita che aiuta il tuo dispositivo a localizzare i servizi, non semplicemente come una rubrica di siti web.
Tale distinzione è fondamentale su una rete WiFi condivisa. Il resolver che gestisce una risoluzione può influire sulla velocità di apertura di una pagina, sul blocco di un dominio e sulla capacità della rete della struttura di visualizzare o gestire la query. Crittografia, autenticità, applicazione delle policy e anonimato sono proprietà distinte: confonderle può portare a decisioni errate in materia di sicurezza.
Indice dei contenuti
- Cosa fa effettivamente una ricerca DNS
- Fasi all'interno di una ricerca DNS
- La gerarchia che rende scalabili le ricerche
- Perché una ricerca DNS è un punto di applicazione delle norme
- Cosa cambia davvero il DNS crittografato
- Quando una ricerca DNS fallisce su un WiFi condiviso
- Come scegliere successivamente un DNS protettivo
Cosa fa effettivamente una ricerca DNS
Un ospite clicca su un link tramite la rete WiFi di un hotel. Il browser conosce il nome del dominio, ma i dispositivi di rete instradano il traffico utilizzando gli indirizzi IP. Una ricerca DNS consiste nel resolver che trova le informazioni associate a quel nome leggibile dall'uomo, il più delle volte un indirizzo IP, consentendo al dispositivo di iniziare a raggiungere il servizio.
Un elenco telefonico è un'analogia iniziale utile, ma il DNS assomiglia di più a una directory distribuita e in tempo reale. Diversi tipi di record supportano l'invio di posta, gli alias, la condivisione dei servizi, le ricerche inverse e altre funzioni di rete. Il DNS non si limita ad associare i nomi dei siti web agli indirizzi, ma aiuta le applicazioni a individuare un'ampia gamma di servizi di rete.
Le specifiche DNS fondamentali sono apparse nel novembre 1987, quando l'Internet Engineering Task Force ha pubblicato la RFC 1034. Quel documento descriveva un algoritmo in quattro fasi: verificare le informazioni locali, individuare i server migliori, interrogarli fino all'arrivo di una risposta e restituire e memorizzare nella cache il risultato quando appropriato (RFC 1034). La memorizzazione nella cache è importante perché un resolver potrebbe già disporre di una risposta utilizzabile da una richiesta precedente.
Una query di directory, non una richiesta di pagina
Quando il dispositivo richiede un nome, non sta chiedendo al DNS di inviare la pagina web. Sta richiedendo informazioni che aiutano l'applicazione a raggiungere il servizio pertinente. Il browser utilizza quindi la risposta come parte del suo processo di connessione.
Sulla rete WiFi ospiti, questo rende la risoluzione un utile punto decisionale condiviso. Il resolver vede il nome richiesto prima di restituire un indirizzo, consentendo agli operatori di rete di cogliere quel momento per applicare le policy. Per una panoramica pratica su come i problemi DNS possano influire sulla disponibilità, consulta questa guida per prevenire i tempi di inattività causati da guasti DNS.
Comprendere il processo aiuta a tracciare il percorso di una ricerca, a capire perché le risposte in cache possono essere più veloci e a riconoscere cosa il DNS può e non può controllare su una rete WiFi condivisa. Velocità, policy, crittografia ed errori di ricerca sono aspetti correlati, ma non rappresentano lo stesso problema.
Fasi all'interno di una ricerca DNS
Un ospite dell'hotel digita example.com nel browser e preme invio. La pagina non è ancora caricata. Prima che possa farlo, il nome passa attraverso una sequenza fissa di ricerche e, su una rete WiFi condivisa, ogni passaggio offre alla rete della struttura una nuova opportunità di osservare o indirizzare la richiesta.
Lo stub resolver del dispositivo avvia la sequenza inviando una query ricorsiva a un caching resolver. Questa entità può essere gestita dalla struttura, da un provider Internet o da un servizio DNS autonomo, e la scelta è fondamentale poiché stabilisce chi vede la query per primo.
Cache hit o cache miss
Il resolver con cache controlla prima la propria memoria. Un record ancora valido viene restituito direttamente, un cache hit che salta ogni passaggio a monte. Un record mancante o scaduto è un cache miss, e il resolver opera quindi attraverso la gerarchia DNS: un root server lo indirizza al dominio di primo livello corretto, un server TLD lo indirizza al nameserver autorevole del dominio e quel nameserver restituisce il record.
Per un sito web, la risposta è solitamente un record A contenente un indirizzo IPv4 o un record AAAA contenente un indirizzo IPv6. Altri tipi di record coprono attività come l'instradamento della posta e gli alias.
Le diverse fasi sollevano anche questioni distinte. La crittografia stabilisce chi può leggere la query in transito. L'autenticità stabilisce se la risposta proviene dall'gestore del dominio. La politica stabilisce se il resolver la restituisce o meno. L'anonimato stabilisce quali parti sono venute a conoscenza del nome in primo luogo.
Il TTL mantiene aggiornate le risposte in cache
Ogni set di record include un time-to-live (TTL), ovvero il tempo massimo in cui un resolver può conservarlo. Il resolver deve eliminare il record alla scadenza, permettendo così agli indirizzi e alle policy aggiornati di tornare in circolazione.
L'assenza di cache per un ospite aggiorna la cache per i visitatori successivi. Valori di TTL brevi consentono alle modifiche di avere effetto prima; TTL lunghi riducono le ricerche ripetute verso i server a monte. Gli operatori di zona cercano un equilibrio tra queste esigenze e tutti gli utenti della rete condivisa ne ereditano il risultato.
Alcune reti inseriscono un passaggio di inoltro all'interno di questa sequenza, inviando le query a un altro resolver anziché percorrere direttamente la gerarchia. Questa panoramica su come il DNS forwarding modifica tale percorso spiega dove avviene la deviazione.
La gerarchia che rende scalabili i lookup
La gerarchia DNS suddivide la responsabilità. In cima ci sono le identità dei root server, che indirizzano i resolver verso il dominio di primo livello corretto. I server TLD gestiscono domini come .com e .org, mentre i server autorevoli di ciascun dominio forniscono i record per i nomi all'interno di quel dominio.
L'immagine comune dei 13 root server può essere fuorviante. Esistono 13 identità definite storicamente, contrassegnate dalla A alla M, gestite da 12 organizzazioni indipendenti. Non si tratta solo di 13 computer fisici. Il routing Anycast consente di servire le stesse identità da oltre 900 istanze distribuite in tutto il mondo, aiutando le query a raggiungere un'istanza vicina e supportando la resilienza (Panoramica dei root server di ICANN).
Come si è sviluppato il sistema root
Il sistema root è cresciuto con l'evolversi delle esigenze della rete. Il primo root server è stato istituito presso l'Information Sciences Institute della University of Southern California nel 1984. Il sistema contava quattro server nel 1985, sette nel 1987, nove nel 1993 e 13 nel 1997. Oggi, il sistema root utilizza sia IPv4 che IPv6. Una panoramica tecnica individua 26 endpoint di indirizzo principali, 13 per ciascun protocollo, accanto alle istanze anycast distribuite.
Queste cifre descrivono diverse parti dell'architettura. Le 13 identità sono i nomi riconoscibili dei root server; gli endpoint degli indirizzi supportano IPv4 e IPv6; le istanze distribuite aiutano a fornire il servizio da posizioni in tutto il mondo. Perdere l'accesso a un'istanza non equivale a perdere un'identità root ovunque.
Questa struttura è il motivo per cui un lookup può sembrare locale anche quando si affida a un sistema globale e multilivello. Il resolver può raggiungere un'istanza nelle vicinanze, mentre la gerarchia continua a distribuire la responsabilità tra gli operatori root, TLD e autorevoli.
Perché un lookup DNS è un punto di applicazione delle policy
Un laptop connesso al WiFi dell'hotel richiede un dominio al resolver della rete prima di poter raggiungere qualsiasi risorsa. Tale richiesta passa attraverso apparecchiature controllate dalla struttura, rendendo la ricerca l'ultimo punto decisionale condiviso prima che il dispositivo prosegua in autonomia. Un servizio di DNS protettivo può rispondere normalmente, rifiutare la query o restituire una risposta che non porta a nulla. Se non viene restituito alcun indirizzo utilizzabile, la connessione generalmente non viene avviata.
Questa posizione è ciò che dà portata alle politiche DNS sulle reti ospiti. Gli smartphone e i laptop dei visitatori raramente contengono software di gestione, quindi la struttura non può installare controlli sul dispositivo stesso. Il resolver è l'unico punto di controllo attraverso cui ogni dispositivo passa già. Le politiche applicate in quella sede possono bloccare i domini associati a phishing, malware o traffico di comando e controllo, applicare categorie come contenuti per adulti o gioco d'azzardo e attivare le impostazioni di Safe Search.
La tempistica rafforza questo aspetto. L'applicazione delle regole avviene nella fase di richiesta, prima che l'applicazione riceva un indirizzo tramite quel resolver. Per le protezioni che operano su altri livelli di una rete, consulta questa guida su come proteggere la tua rete aziendale Microsoft 365.
Cosa può e non può coprire una policy DNS
L'applicazione delle regole DNS gestisce la risoluzione dei nomi, ma le connessioni possono aggirarla. Un'applicazione potrebbe riutilizzare un indirizzo in cache, contattare direttamente un IP, raggiungere un servizio che non ha mai utilizzato un nome DNS o inviare query tramite un resolver crittografato non assegnato dalla struttura.
Gli operatori valutano quindi il comportamento del DNS crittografato, le cache delle applicazioni e il traffico IP diretto insieme al filtraggio. Il filtraggio DNS funziona come un singolo livello all'interno di un insieme di controlli più ampio. Una guida al filtraggio DNS e a come le policy si applicano alle risoluzioni esamina in dettaglio il ruolo del filtraggio.
La policy è solo uno degli assi della sicurezza. Se un dominio sia consentito, se una risposta sia autentica e se qualcuno possa leggere la query in transito sono questioni distinte, gestite da meccanismi differenti.
Anche le risposte negative meritano attenzione. Un resolver può salvare in cache una risposta NXDOMAIN, la quale indica che il dominio richiesto non esiste, invece di interrogare nuovamente i server upstream per lo stesso nome mancante. L'RFC 8020 descrive un NXDOMAIN cut, in cui una risposta negativa convalidata stabilisce anche che i nomi al di sotto del dominio mancante non esistono (RFC 8020). Le linee guida IETF più recenti richiedono di memorizzare in cache anche i fallimenti di risoluzione, riducendo le inutili query ripetute.
Cosa cambia davvero con il DNS crittografato
Un ospite accede al WiFi di un hotel e visita un sito web. La query DNS è uno degli ultimi punti decisionali condivisi prima della connessione: il dispositivo chiede a un resolver quale indirizzo utilizzare e il resolver può applicare le regole della struttura. La crittografia di tale richiesta modifica chi può leggerla in transito. Non modifica, di per sé, ciò che il resolver può vedere né rende l'ospite anonimo.
Il dispositivo invia la sua query a un resolver ricorsivo, che cerca la risposta e la restituisce. Il DNS over HTTPS (DoH) crittografa la connessione tra il dispositivo e quel resolver. Chiunque monitori la rete WiFi potrebbe avere maggiori difficoltà a leggere o modificare la query, ma il resolver riceve comunque il dominio richiesto.
DNSSEC gestisce un problema distinto: consente a un resolver di validazione di verificare l'autenticità e l'integrità dei dati DNS firmati. Non crittografa la query. Crittografia, autenticità, applicazione delle politiche e anonimato sono proprietà differenti.
Il compromesso sulle reti WiFi condivise
Un browser che utilizza DoH può inviare query a un resolver scelto dal browser o dall'utente, anziché a quello assegnato da un hotel, una scuola, una struttura sanitaria o un operatore di WiFi pubblico. Ciò può limitare la visibilità della struttura e le regole DNS che questa può applicare. Può anche rendere più complessa la risoluzione dei problemi se la rete della struttura dipende dal proprio resolver.
La distinzione pratica è chiara: il DoH protegge la query nel suo percorso verso il resolver; non nasconde la query a quel resolver. Il DNSSEC aiuta a verificare le risposte firmate. Una struttura può applicare la politica DNS solo quando le relative query passano attraverso un resolver da essa controllato o integrato, e nessuna delle due tecnologie rende un utente anonimo.
Quando un lookup DNS fallisce su una rete WiFi condivisa
Due ospiti si connettono alla stessa rete WiFi dell'hotel. Uno apre un sito web familiare; l'altro visualizza un errore, anche se entrambi i dispositivi risultano connessi. La differenza potrebbe risiedere nel percorso di lookup, nella cache del dispositivo o nel resolver utilizzato da ciascun client.
Un resolver potrebbe essere irraggiungibile, restituire una risposta incompleta o non essere in grado di risolvere un nome esistente solo all'interno della rete aziendale. Una rete potrebbe anche bloccare il traffico DNS tradizionale tramite la porta UDP o TCP 53, oppure restituire deliberatamente un errore se le policy bloccano il dominio richiesto.
Separa i sintomi prima di modificare le impostazioni
Considera il portale interno di una scuola che funziona tramite il resolver designato dall'istituto ma non tramite un resolver pubblico esterno. La scuola potrebbe utilizzare un DNS split-horizon, in cui i nomi interni sono disponibili solo attraverso il resolver della rete. La modifica delle impostazioni DNS di un dispositivo potrebbe consentire il caricamento di un sito web pubblico, interrompendo al contempo l'accesso al portale interno.
Il DNS crittografato può aggiungere un ulteriore punto di errore. Uno studio del 2025 ha riportato che le query DNS HTTPS rappresentavano circa l'8% del traffico DNS osservato e che le risposte incomplete aumentavano il volume delle query (studio sul traffico DNS crittografato). Una ricerca separata sui resolver ha rilevato che uno su tre dei resolver crittografati pubblicizzati non ha risposto, come menzionato in precedenza. Un client potrebbe quindi utilizzare un resolver crittografato che non risponde come previsto, anche se il resolver assegnato dalla struttura è disponibile.
Regola di risoluzione dei problemi: Conferma quale resolver stia effettivamente utilizzando il client prima di chiedere all'ospite di modificare le impostazioni DNS.
Per gli operatori, è opportuno classificare le cause probabili anziché gestire ogni errore di ricerca allo stesso modo:
- Captive portal: Il dispositivo non ha completato l'accesso al WiFi o la pagina dei termini.
- Cache obsoleta: Il client o il risolutore conserva una risposta non aggiornata.
- Interruzione upstream: Il risolutore configurato non può completare la richiesta.
- Porta 53 bloccata: Il traffico DNS tradizionale è bloccato o non può raggiungere il risolutore.
- DoH o DoT non supportati: Il comportamento del DNS crittografato del client non è supportato o gestito dalla rete.
- Blocco da policy: Il risolutore trattiene intenzionalmente una risposta.
Un errore DNS può anche indicare un problema di sicurezza WiFi anziché un problema del resolver. Per indicazioni su come riconoscere un access point ingannevole, consulta la guida alla prevenzione degli evil twin di RDE Technologies.
Come scegliere il prossimo DNS protettivo
Ogni dispositivo ospite che si connette alla tua rete WiFi deve comunque chiedere indicazioni a qualcuno prima di collegarsi. La vera scelta dell'operatore sta nel decidere chi risponde a quella domanda: il resolver che il dispositivo si porta dietro per caso, il set di regole di un firewall obsoleto o un servizio DNS protettivo sotto il tuo controllo. Ciascuna opzione modifica il livello di policy che puoi applicare e la quantità di evidenze che conservi in quel punto decisionale condiviso finale.
| Approccio | Dispositivi non gestiti | Punto di decisione | Evidenza per l'operatore |
|---|---|---|---|
| Risolutori selezionati dal client | Spesso al di fuori della policy DNS della struttura | Risolutore scelto dal dispositivo o dal browser | Visibilità limitata a livello di rete |
| Solo firewall obsoleto | La copertura dipende dalle regole del firewall e dal percorso del traffico | Controlli del firewall disponibili per quella rete | Log e avvisi del firewall |
| Risolutore DNS protettivo in cloud | Può coprire i dispositivi che utilizzano il risolutore assegnato dalla rete | Ricerca del dominio prima della restituzione di un indirizzo | Reportistica delle ricerche e dei blocchi da parte del risolutore |
Per le reti nei settori hospitality, istruzione, sanità, settore pubblico e multi-sede, Purple Shield rappresenta un'opzione di protezione DNS, come menzionato in precedenza. Valuta le ricerche prima dell'avvio delle connessioni, applica categorie di contenuto come contenuti per adulti e gioco d'azzardo, impone Safe Search su Google, Bing e YouTube e blocca i domini di comando e controllo, phishing e malware. Il fornitore descrive anche segnali supportati dall'IA pensati per segnalare le minacce emergenti prima delle blocklist standard, oltre al blocco di annunci e tracker a livello DNS che, secondo quanto dichiarato, riduce il peso della pagina e il volume del traffico.
Confronta policy e idoneità operativa
Il servizio supporta le politiche per SSID, VLAN, sede e pianificazione oraria, insieme a dashboard, pagine di blocco personalizzate e funzionamento fail-closed. La descrizione del servizio indica che non richiede alcun agente client o modifica al firewall, cita uno SLA di uptime pubblico e garantisce la conformità agli standard Friendly WiFi e Internet Watch Foundation. Considera queste informazioni come dichiarazioni del fornitore e valutale in base ai tuoi requisiti di reportistica e resilienza.
Il filtraggio DNS risponde solo a una parte dei requisiti di sicurezza. La crittografia nasconde la ricerca agli osservatori lungo il percorso, le verifiche di autenticità confermano che la risposta provenga dal resolver corretto, la politica decide se rispondere o meno e l'anonimato dipende da chi gestisce tale resolver. Un secure web gateway può coprire una parte maggiore di questo stack, quindi confronta le differenze tra i due ruoli prima di procedere.
Inizia con un SSID per gli ospiti. Registra quale resolver utilizzano oggi i dispositivi, quindi testa Purple Shield su quella rete prima di estendere la policy a tutte le sedi.