Come funziona la risoluzione DNS: server, cache e problemi comuni

Quando il browser ha bisogno di un indirizzo per un nome come pudgycat.io, il DNS aiuta a trovarlo. A volte la risposta è già in cache; altre volte un resolver deve interrogare altri server. Questa guida spiega il processo, perché le risposte possono cambiare e come distinguere un problema di risoluzione da un sito che sta passando una brutta giornata. La rubrica di internet è sorprendentemente occupata, per essere qualcosa che nessuno ricorda di aver aperto.

Indice

• Che cos’è il DNS e perché ci serve
• Come funziona la risoluzione DNS, passo per passo
• I quattro tipi di server DNS
• I tipi di record da conoscere
• Cache DNS e TTL
• Query ricorsive e iterative
• Sicurezza: DNSSEC, DoH e DoT
• Quando il DNS si rompe: problemi comuni
• Domande frequenti

Che cos’è il DNS e perché ci serve

Il Domain Name System associa nomi a record di diversi tipi, compresi gli indirizzi IP. Un browser può usare un indirizzo per contattare un servizio, ma il DNS supporta anche l’instradamento della posta e altri scopi. Non recupera la pagina web stessa. Pensa a «trovare la destinazione» e poi «stabilire la connessione»: due lavori collegati che possono fallire indipendentemente.

Agli inizi di internet, le associazioni fra nomi degli host e indirizzi venivano distribuite in un file centrale HOSTS.TXT. La specifica DNS di Paul Mockapetris spiega perché quell’approccio diventasse difficile da estendere. Il DNS distribuisce invece le responsabilità in una gerarchia. La sua storia è fatta di adozione ed evoluzione graduali, non di un unico giorno in cui tutto il mondo cambiò le proprie impostazioni.

Nomi e indirizzi IP

L’indirizzo di un servizio può cambiare senza che cambi il nome. Un nome può anche avere diversi record di indirizzo. Questa flessibilità aiuta a separare il nome ricordato dai visitatori dalle macchine o dalle posizioni di rete che li servono. Il DNS non garantisce un numero permanente per ogni sito.

Come funziona la risoluzione DNS, passo per passo

Ecco un percorso di ricerca semplificato, coerente con la spiegazione di Cloudflare. Impostazioni del browser, del sistema operativo e della rete possono modificarlo; non è un viaggio in otto tappe ripetuto a ogni caricamento di pagina.

1. Ricerca locale. Il browser o il sistema operativo potrebbero già avere una risposta utilizzabile nella cache.
2. Configurazione locale. File hosts e impostazioni delle applicazioni possono influenzare la risoluzione dei nomi. La precedenza esatta dipende dal sistema.
3. Scelta del resolver. Il dispositivo può usare quello della rete, un servizio pubblico configurato o il fornitore di DNS cifrato del browser.
4. Richiesta della risposta. Un resolver ricorsivo può rispondere dalla cache o proseguire la ricerca.
5. Ricerca della delega pertinente. Se necessario, il resolver chiede a un server radice dove trovare i server del dominio di primo livello.
6. Passaggio al riferimento successivo. Un server del TLD può indirizzarlo verso i server autoritativi del dominio.
7. Recupero del record. Una risposta autoritativa può contenere un indirizzo, un alias che richiede un’altra ricerca o un risultato negativo.
8. Restituzione del risultato. Il resolver risponde e i record idonei possono essere memorizzati nella cache. Il browser può quindi tentare una connessione.

Non esiste un tempo universale di risoluzione. Stato della cache, distanza di rete, nuovi tentativi, carico del server e configurazione contano tutti. Il DNS è anche soltanto una parte del caricamento di una pagina: una risposta rapida non può mettere fretta a un server applicativo lento.

I quattro tipi di server DNS

Sono ruoli utili da riconoscere. I server radice e quelli dei TLD sono a loro volta autoritativi per le rispettive zone; le categorie descrivono dove si trova un server nella gerarchia e quale servizio offre, non quattro specie di macchine senza relazione.

1. Resolver ricorsivo

Un resolver ricorsivo cerca risposte per conto di un client, spesso usando informazioni in cache e talvolta un altro resolver a monte. Un router domestico può inoltrare le query anziché svolgere da solo tutto il lavoro. Anche i fornitori pubblici hanno politiche diverse di filtraggio e conservazione dei dati; «DNS pubblico» non è una promessa uniforme di velocità o privacy.

2. Server radice

Esistono 13 identità di server radice, denominate da A a M, gestite da 12 organizzazioni attraverso molte istanze distribuite. Il sito degli operatori dei server radice descrive il sistema. Questi server servono la zona radice, comprese le deleghe dei TLD. «Tredici radici» non significa tredici computer fisici con tutta internet in coda fuori.

3. Server del TLD

I server autoritativi di un TLD servono la sua zona, comprese le deleghe dei nomi sottostanti. Non conservano una directory in tempo reale di ogni dominio mai registrato e non contengono necessariamente l’indirizzo finale di ogni sito. Un rinvio dice al resolver dove chiedere dopo.

4. Server autoritativo

Un server autoritativo serve i dati di una zona. Gli amministratori dei domini pubblicano modifiche attraverso il fornitore DNS o un proprio sistema; più server ridondanti possono servire la stessa zona. «Autoritativo» descrive la responsabilità su quei dati, non la proprietà del sito o la garanzia che l’operatore abbia configurato tutto correttamente.

I tipi di record da conoscere

Il DNS usa tipi di record differenti per scopi differenti. Il registro IANA li elenca insieme alle specifiche. Fra gli esempi comuni:

• Record A: associa un nome a un indirizzo IPv4.
• Record AAAA: associa un nome a un indirizzo IPv6. Si pronuncia «quad-A».
• Record CNAME: un alias. Fa puntare un nome a un altro nome, per esempio www.example.com come alias di example.com.
• Record MX: mail exchange. Indica ai server di posta dove consegnare le email per il dominio.
• Record TXT: testo arbitrario. Usato per SPF, DKIM, verifica della proprietà del dominio e, nel selvaggio West dell’impianto idraulico di internet, a volte per configurare servizi.
• Record NS: name server. Elenca i server DNS autoritativi di un dominio.
• Record PTR: punta a un altro nome di dominio; le zone DNS inverse lo usano per associare un indirizzo a un nome. Non deve necessariamente essere l’inverso esatto del record A di un sito.
• Record SRV: posizione di un servizio. Definisce nome host e porta per un servizio specifico, usato da SIP, XMPP, Minecraft e simili.
• Record CAA: autorizzazione delle autorità di certificazione. Indica quali autorità possono emettere certificati HTTPS per il dominio.

Puoi esaminarli da un terminale. Su Linux e macOS, dig pudgycat.io restituisce il record A. dig -t MX pudgycat.io restituisce i record della posta. Su Windows, nslookup svolge lo stesso compito.

Cache DNS e TTL

I record DNS contengono un TTL, misurato in secondi, che normalmente limita per quanto tempo si possano riutilizzare dalla cache. RFC 1035 definisce il campo. Queste durate di esempio illustrano il compromesso, non impostazioni obbligatorie:

• 300 secondi: cinque minuti.
• 3600 secondi: un’ora.
• 86400 secondi: un giorno.

Cambiare un record autoritativo non cancella subito le copie in cache. Abbassare il TTL in anticipo può aiutare per una modifica pianificata, ma le copie memorizzate con il vecchio TTL hanno comunque bisogno di tempo per scadere. Anche le risposte negative possono essere memorizzate, come descrive RFC 2308. Alcuni resolver possono servire dati scaduti in determinate condizioni di guasto, quindi il TTL non è un cronometro universale per ogni risultato osservabile.

Query ricorsive e iterative

Spesso questi due termini vengono confusi. Descrivono ruoli diversi nella stessa catena.

Una query ricorsiva chiede al resolver di ottenere la risposta anziché lasciare al client il compito di seguire i rinvii. Un piccolo resolver lato client viene spesso chiamato stub resolver. «Resolver», quindi, non significa sempre un servizio ricorsivo pubblico.

Con le query iterative, il resolver che interroga può seguire i rinvii da sé. Potrebbe già avere abbastanza informazioni di delega in cache da saltare il passaggio alla radice o al TLD. La gerarchia spiega chi è responsabile, non un itinerario fisso.

La delega distribuisce le responsabilità; la cache evita di ripetere il lavoro. È questo il trucco architetturale, anche quando il percorso concreto viene abbreviato da informazioni già disponibili.

Sicurezza: DNSSEC, DoH e DoT

Il DNS classico ha due proprietà sgradevoli. Non è cifrato e non autentica le risposte. Tre protocolli moderni affrontano parti diverse del problema.

DNSSEC

DNSSEC permette a un resolver validante di controllare autenticità e integrità dei dati DNS firmati attraverso una catena di fiducia. Non cifra le query, non certifica che un sito sia innocuo e non autentica magicamente i dati non firmati. Una catena di validazione interrotta può essa stessa far fallire la risoluzione.

DNS over HTTPS (DoH)

DNS over HTTPS (DoH) trasporta i messaggi DNS su una connessione HTTPS cifrata. Protegge quel trasporto da intercettazioni e alterazioni dirette. Il resolver scelto continua a elaborare la query e il DNS cifrato non nasconde ogni indizio sui siti visitati. La confezione HTTPS non è un mantello di perfetta invisibilità.

DNS over TLS (DoT)

DNS over TLS (DoT) usa una connessione DNS protetta da TLS, convenzionalmente sulla porta 853. La porta dedicata rende quel traffico più facile da distinguere dal normale HTTPS. Come DoH, protegge la connessione cifrata configurata, non ogni fase della visita a un sito.

Trasporto cifrato e dati DNS firmati affrontano rischi diversi. Nessuno dei due elimina la necessità di scegliere un resolver di cui fidarsi. In particolare, cifrare la connessione a un resolver malevolo non rende oneste le sue risposte.

Quando il DNS si rompe: problemi comuni

Il DNS è una possibile causa di una visita fallita, insieme a problemi di rete, TLS, hosting, applicazione e database. Controlla il sintomo prima di cambiare impostazioni. Fra i risultati comuni legati al DNS:

• NXDOMAIN: il nome richiesto non esiste. Un nome esistente senza un record del tipo richiesto è una risposta negativa diversa, spesso chiamata NODATA.
• SERVFAIL: la risoluzione è fallita. Gli errori di validazione DNSSEC sono una possibile causa, accanto ad altri problemi a monte o del server.
• Vecchia risposta in cache: un record precedente potrebbe essere ancora entro il suo TTL. Svuotare la cache locale non svuota ogni resolver a monte.
• Risposta sbagliata: configurazioni errate o manipolazioni possono indirizzare male la ricerca. Validazione DNSSEC e trasporto cifrato svolgono ruoli protettivi diversi e limitati.
• Guasto del resolver: un altro resolver consentito può aiutare a diagnosticare un problema del fornitore locale. Non può riparare una zona autoritativa difettosa o un server web guasto.

Gli attacchi a Dyn dell’ottobre 2016 mostrano come un’interruzione presso un fornitore DNS possa influenzare l’accesso a molti servizi contemporaneamente. L’analisi dell’incidente di Dyn conservata online descrive gli attacchi alla propria infrastruttura DNS gestita e dice esplicitamente di non poter verificare le notizie di una portata di 1,2 Tbps. La lezione non richiede di trasformare un numero non confermato in un fatto.

Per la parte successiva del viaggio da un nome a qualcosa riprodotto sullo schermo, leggi la nostra spiegazione dello streaming video (in inglese). Risolvere un indirizzo avvia il viaggio; non consegna da solo il video.

Domande frequenti

Quanto tempo richiede la risoluzione DNS?

Dipende da cache, condizioni di rete e necessità di riprovare. Un risultato nella cache locale può essere rapidissimo, ma non esiste un massimo universale affidabile per una ricerca a cache vuota.

Che differenza c’è fra resolver DNS e server DNS?

Un server DNS risponde alle query DNS. Un resolver è il componente che ottiene le risposte; può essere un piccolo stub lato client o un servizio ricorsivo. I server radice e dei TLD normalmente forniscono dati autoritativi di zona, anziché svolgere la ricorsione per il browser.

Come svuoto la cache DNS?

Su Windows, ipconfig /flushdns svuota la cache del resolver DNS client. Altri sistemi e applicazioni hanno procedure proprie, che variano secondo la versione. Svuotare una cache non cambia i record autoritativi né cancella la cache del fornitore.

Dovrei cambiare resolver DNS?

Può essere utile nella diagnosi dei problemi, ma prestazioni e privacy cambiano secondo fornitore e rete. I dispositivi di lavoro o scuola potrebbero dipendere da un resolver specifico per i servizi interni. Controlla impostazioni e regole applicabili e annota la configurazione originale prima di modificarla. Un resolver diverso non è una cura universale per una connessione lenta.

Il DNS può essere usato per bloccare i siti?

Sì. Un resolver può rifiutare o modificare le risposte, ma il filtraggio DNS è solo un metodo di blocco. Inserire direttamente un IP potrebbe non funzionare con hosting condiviso e HTTPS. DNS cifrato e DNSSEC non sono sistemi garantiti per aggirare restrizioni; possono comunque applicarsi altri controlli di rete.

Che cosa portarsi a casa

È facile dimenticarsi del DNS finché un nome smette di risolversi. Il modello utile è una gerarchia di responsabilità sostenuta dalle cache, non una catena inflessibile che riparte a ogni visita. Quando un sito non funziona, il DNS merita un controllo, non una condanna automatica. Nemmeno la rubrica di internet può aggiustare un database che è uscito a pranzo.

Traduzione italiana dell’articolo originale in inglese del 2026-05-26. Tradotto il 30 ottobre 2026 con assistenza IA; i riferimenti temporali restano quelli dell’originale.