IPAddress-Lookup.com

Che cos’è il DNS e come funziona?

IPAddress-Lookup.com ·

Ogni volta che digiti il nome di un sito web nel browser, un sistema invisibile entra in azione per individuare dove si trova effettivamente quel sito. Quel sistema è il Domain Name System, o DNS, ed è uno degli elementi più importanti dell’infrastruttura di Internet. Senza di esso, dovresti memorizzare lunghe sequenze di numeri per ogni sito web che visiti, invece di nomi intuitivi come example.com. In questa guida spiegheremo esattamente cos’è il DNS, seguiremo una ricerca reale dall’inizio alla fine, analizzeremo ogni tipo di record principale e ti mostreremo come ispezionare e risolvere autonomamente i problemi relativi al DNS.

Che cos’è il DNS?

Il DNS è la rubrica telefonica di Internet. I computer non comunicano utilizzando nomi leggibili dall’uomo, ma tramite indirizzi numerici. Quando vuoi contattare un amico al telefono, non componi il suo nome, ma il suo numero; tuttavia, probabilmente ricordi il nome e lasci che sia la tua rubrica a tradurlo in cifre. Il DNS fa la stessa cosa per Internet: traduce un nome di dominio facile da ricordare, come www.example.com, nell’indirizzo IP numerico che le macchine utilizzano effettivamente per instradare il traffico, come 93.184.216.34 per IPv4 o una stringa esadecimale più lunga per IPv6.

Questa traduzione è importante perché gli indirizzi IP cambiano. Un sito web potrebbe trasferirsi su un nuovo server, cambiare provider di hosting o distribuire i propri contenuti su decine di data center in tutto il mondo. I nomi ci forniscono un’etichetta stabile e facile da ricordare che rimane la stessa anche quando l’indirizzo sottostante cambia. Il DNS è il livello che mantiene questa promessa, risolvendo i nomi in indirizzi miliardi di volte al secondo in tutto il mondo. È anche un sistema distribuito, il che significa che nessun singolo computer contiene l’intera rubrica. La responsabilità è invece distribuita su una vasta gerarchia di server, ed è proprio questo che rende il DNS veloce, resiliente e in grado di scalare fino a coprire l’intero pianeta.

Gli attori coinvolti in una ricerca DNS

Prima di seguire il percorso di una query, è utile conoscere i protagonisti. Ognuno ha un compito specifico e una singola ricerca può coinvolgerli tutti:

  • Resolver stub — il piccolo programma integrato nel sistema operativo. Quando un’applicazione ha bisogno di un indirizzo, il resolver stub inoltra la richiesta. Di per sé, non esegue quasi nessuna elaborazione.
  • Resolver ricorsivo — il vero motore del sistema, solitamente gestito dal proprio provider di servizi Internet o da un provider pubblico, come i noti servizi 8.8.8.8 o 1.1.1.1. Accetta la richiesta e svolge tutto il lavoro necessario per trovare la risposta finale, per poi restituirla all’utente.
  • Server dei nomi di root — il vertice della gerarchia. Non conoscono l’indirizzo di nessun sito web, ma sanno dove trovare i server responsabili di ciascun dominio di primo livello.
  • Server dei nomi TLD — responsabili di un dominio di primo livello come .com, .org o .net. Sanno quali server autorevoli gestiscono ciascun dominio registrato sotto di essi.
  • Server dei nomi autoritativi — la fonte definitiva di verità. Questi server contengono i record effettivi di un dominio specifico e forniscono la risposta definitiva.

Tracciamento di una query reale: risoluzione di www.example.com

Seguiamo passo dopo passo una singola richiesta. Immaginate di digitare www.example.com nel vostro browser e di premere Invio. Ecco cosa succede dietro le quinte, supponendo che non ci sia ancora nulla nella cache:

  1. Il browser interroga il resolver stub. Il resolver stub del vostro sistema operativo riceve la richiesta per www.example.com. Per prima cosa controlla la propria cache locale. Se ha cercato questo nome di recente, restituisce immediatamente la risposta e il percorso termina qui.
  2. Lo stub resolver contatta il resolver ricorsivo. In assenza di una risposta memorizzata nella cache, lo stub resolver inoltra la query al resolver ricorsivo configurato dall’utente.
  3. Il resolver ricorsivo interroga un server root. Il resolver ricorsivo non sa ancora dove si trovi .com, quindi chiede a uno dei server root. Il server root non conosce www.example.com, ma risponde con un rinvio: «Non ho quella risposta, ma ecco i server responsabili di .com».
  4. Il resolver ricorsivo interroga il server del TLD .com. Seguendo quel rinvio, il resolver chiede a un server del TLD .com informazioni su www.example.com. Il server del TLD risponde con un altro rinvio: «Non conosco l’indirizzo, ma ecco i server dei nomi autoritativi per example.com».
  5. Il resolver ricorsivo interroga il server autoritativo. Infine, il resolver chiede al server dei nomi autoritativo per example.com. Questo server detiene i record effettivi e risponde in modo definitivo: «www.example.com si trova all’indirizzo 93.184.216.34».
  6. La risposta ti viene restituita. Il resolver ricorsivo memorizza questa risposta nella cache, la trasmette al tuo resolver stub e il tuo browser apre una connessione a quell’indirizzo IP. L’intero processo si conclude in genere in poche decine di millisecondi.

Query ricorsive e iterative

La procedura illustrata sopra mette in evidenza due diversi stili di interrogazione, e comprenderne la distinzione chiarisce gran parte della confusione. Quando il tuo dispositivo pone una domanda al resolver ricorsivo, si aspetta una risposta finale completa. Si tratta di una query ricorsiva: il resolver si assume la responsabilità di fare tutto il necessario per restituire un risultato completo. Il tuo dispositivo rimane in attesa.

Le comunicazioni che il resolver ricorsivo intrattiene con i server root, TLD e autoritativi sono query iterative. Ciascuno di questi server non va alla ricerca della risposta per conto dell’utente. Risponde invece con le migliori informazioni di cui dispone, che di solito consistono in un rinvio che avvicina di un passo alla destinazione. Il resolver ricorsivo ripete quindi il processo, procedendo a cascata lungo la gerarchia fino a raggiungere una risposta autorevole. In breve: il tuo dispositivo effettua richieste in modo ricorsivo, mentre il resolver opera in modo iterativo.

Caching e TTL a ogni livello

Se ogni ricerca dovesse percorrere l’intero percorso fino a un server autorevole, Internet sarebbe estremamente lento e i server di root crollerebbero sotto il carico. La cache impedisce che ciò accada. In quasi ogni livello, le risposte vengono memorizzate temporaneamente in modo da poter essere riutilizzate. Il browser memorizza nella cache, il sistema operativo memorizza nella cache e il resolver ricorsivo ricorre ampiamente alla cache.

La durata della memorizzazione in cache di un record è controllata dal suo TTL (Time to Live), misurato in secondi e impostato dal proprietario del dominio. Un record con un TTL di 3600 può rimanere in cache per un’ora prima che un resolver debba recuperarne una copia aggiornata. I TTL brevi consentono di modificare rapidamente i record, il che è utile durante la migrazione di un server, ma aumentano il volume delle query. I TTL lunghi migliorano le prestazioni e riducono il carico, ma comportano tempi più lunghi per la propagazione delle modifiche in tutto il mondo. Questo è il motivo per cui gli amministratori spesso abbassano il TTL di un record un giorno prima di una modifica pianificata e lo aumentano nuovamente in seguito.

La gerarchia DNS e i server root

Il DNS è organizzato come un albero rovesciato. Al vertice si trova la radice, rappresentata da un singolo punto solitamente invisibile. Sotto la radice si trovano i domini di primo livello (TLD) come .com, .org e i codici paese come .uk o .de. Sotto ciascun TLD si trovano i domini di secondo livello che individui e organizzazioni registrano, come example.com. Sotto questi si trovano i sottodomini come www o mail. Leggendo un nome di dominio da destra a sinistra si scende lungo la gerarchia dal generale al specifico.

La radice è gestita da un sistema noto come i «13 server root». In realtà si tratta di 13 cluster denominati, contrassegnati dalle lettere da A a M, ciascuno gestito da un’organizzazione diversa. Dietro ciascuno di questi 13 indirizzi si celano centinaia di server fisici distribuiti in tutto il mondo tramite una tecnica chiamata anycast, che instrada la richiesta verso l’istanza disponibile più vicina. È così che una manciata di punti di accesso denominati riesce a rispondere in modo affidabile alle richieste provenienti da tutto il pianeta, con bassa latenza ed elevata resilienza contro interruzioni e attacchi.

Spiegazione dei tipi di record DNS

La zona DNS di un dominio è un insieme di record, e ogni tipo di record ha uno scopo ben preciso. Comprendere questi record è essenziale per chiunque gestisca un sito web o un servizio di posta elettronica. La tabella sottostante riassume i tipi più importanti con un esempio per ciascuno.

Record Scopo Esempio
A Assegna un nome a un indirizzo IPv4 example.com → 93.184.216.34
AAAA Assegna un nome a un indirizzo IPv6 example.com → 2606:2800:220:1:248:1893:25c8:1946
CNAME Assegna un alias da un nome a un altro nome canonico www.example.com → example.com
MX Specifica i server di posta che accettano le e-mail per il dominio 10 mail.example.com
TXT Contiene testo arbitrario, ampiamente utilizzato per l’autenticazione delle e-mail "v=spf1 include:_spf.example.com ~all"
NS Delega un dominio ai propri server dei nomi autoritativi ns1.example.com
SOA Start of Authority; contiene i metadati della zona e i timer di aggiornamento ns1.example.com admin.example.com 2026070101
CAA Indica quali autorità di certificazione possono emettere certificati 0 emettere "letsencrypt.org"
PTR Ricerca inversa, che associa un indirizzo IP a un nome 34.216.184.93.in-addr.arpa → example.com

Record A e AAAA

Questi sono gli elementi fondamentali che collegano i nomi agli indirizzi. Un record A punta a un indirizzo IPv4, mentre un record AAAA punta a un indirizzo IPv6. Un dominio può avere entrambi, in modo che i client che utilizzano uno dei due protocolli possano raggiungerlo. Quando il browser chiede "dove si trova example.com", di solito è uno di questi due record a fornire la risposta definitiva.

Record CNAME

Un record CNAME crea un alias, reindirizzando un nome verso un altro nome canonico. Viene comunemente utilizzato per indirizzare www al dominio principale, oppure per indirizzare un sottodominio personalizzato all’indirizzo di un provider di hosting. Una regola fondamentale è che un record CNAME non può coesistere con altri record con lo stesso nome; ecco perché la radice di un dominio utilizza solitamente record A o AAAA anziché un record CNAME.

Record MX e di posta elettronica

I record MX indicano quali server accettano la posta per il tuo dominio, con un numero di priorità che determina l’ordine in cui vengono provati. I numeri più bassi sono preferiti, quindi un server con priorità 10 viene provato prima di uno con priorità 20. Ma i record MX sono solo una parte della storia del DNS relativa alla posta elettronica.

Record TXT: SPF, DKIM e DMARC

I record TXT contengono testo in formato libero e il mondo della posta elettronica fa ampio ricorso a essi per tre meccanismi di autenticazione interconnessi. L’SPF elenca i server autorizzati a inviare posta per conto del proprio dominio, aiutando i destinatari a respingere i messaggi contraffatti. DKIM pubblica una chiave pubblica crittografica in modo che i destinatari possano verificare che un messaggio sia stato firmato dal proprio dominio e non sia stato alterato durante il transito. DMARC collega i due meccanismi, indicando ai destinatari cosa fare con i messaggi che non superano i controlli SPF o DKIM e dove inviare i rapporti. Insieme costituiscono la spina dorsale della moderna deliverability della posta elettronica.

Record NS e SOA

I record NS delegano l’autorità, indicando i server responsabili di una zona. Il record SOA si trova all’inizio di ogni zona e contiene dettagli amministrativi quali il server dei nomi primario, il contatto responsabile, un numero di serie che cambia quando la zona viene modificata e i timer che regolano la frequenza con cui i server secondari aggiornano le proprie copie della zona.

Record CAA e PTR

Un record CAA limita quali autorità di certificazione sono autorizzate a emettere certificati per il tuo dominio, aggiungendo un ulteriore livello di protezione contro i certificati non autorizzati. Se vuoi capire in che modo questi certificati proteggono il tuo traffico, consulta la nostra guida sui certificati SSL. Un record PTR gestisce il DNS inverso, mappando un indirizzo IP a un nome host, che viene spesso verificato dai server di posta per valutare la legittimità di un mittente.

DNS e deliverability delle e-mail

Il DNS è senza dubbio importante per la posta elettronica quanto lo è per il web. Quando un server di posta vuole consegnare un messaggio al tuo dominio, consulta i tuoi record MX per trovare la destinazione corretta. Quando un server ricevente deve decidere se un messaggio in arrivo è affidabile, controlla i tuoi record SPF, DKIM e DMARC e spesso verifica anche il record PTR del server mittente. Se uno qualsiasi di questi record è mancante o configurato in modo errato, la posta legittima potrebbe finire nelle cartelle dello spam o essere rifiutata del tutto. Assicurarsi che i record DNS relativi alla posta elettronica siano corretti è una delle misure più efficaci che puoi adottare per garantire che i tuoi messaggi arrivino nella posta in arrivo anziché sparire nella cartella dello spam.

Sicurezza del DNS

Poiché il DNS è così fondamentale, è diventato un bersaglio, ed esistono diverse tecnologie per rafforzarne la sicurezza:

  • Il DNSSEC aggiunge firme crittografiche ai record DNS in modo che i resolver possano verificare che una risposta provenga effettivamente dalla fonte autorevole e non sia stata manomessa. Protegge l’integrità dei dati ma non li crittografa.
  • Il DNS over HTTPS (DoH) e il DNS over TLS (DoT) crittografano la comunicazione tra il dispositivo dell’utente e il resolver ricorsivo. Tradizionalmente, le query DNS viaggiavano in testo in chiaro, consentendo a chiunque si trovasse sul percorso di rete di visualizzarle e persino di alterarle. DoH e DoT colmano questa lacuna avvolgendo le query in una crittografia.
  • Il cache poisoning è un attacco classico in cui un malintenzionato induce un resolver a memorizzare nella cache una risposta falsa, reindirizzando le vittime verso un server fraudolento. Il DNSSEC e le moderne protezioni dei resolver, come le porte di origine casuali, rendono questo attacco molto più difficile da portare a termine.

Problemi comuni relativi al DNS e risoluzione dei problemi

Quando un sito web non si carica, spesso la causa è da ricercarsi nel DNS. Alcuni dei problemi più frequenti includono:

  • Ritardi di propagazione. Dopo aver modificato un record, i vecchi valori memorizzati nella cache potrebbero persistere fino alla scadenza del loro TTL. Questo spiega perché una modifica possa apparire attiva per te ma non ancora per gli altri.
  • Errori di battitura e record mancanti. Un nome host scritto male o un record A dimenticato causano errori facili da trascurare.
  • Server dei nomi non corrispondenti. Se il tuo registrar punta il dominio verso server dei nomi errati, nessuno dei tuoi record accuratamente creati verrà mai consultato.
  • CNAME in conflitto. Inserire un CNAME accanto ad altri record con lo stesso nome interrompe la risoluzione.
  • Cache del resolver. A volte il problema è una voce obsoleta nel proprio dispositivo o router, che si risolve svuotando la cache.

Come controllare autonomamente i record DNS

Non è necessario essere un ingegnere di rete per cercare i record DNS. Strumenti da riga di comando come dig e nslookup, disponibili sulla maggior parte dei sistemi, consentono di interrogare direttamente qualsiasi tipo di record. Ad esempio, richiedendo il record A di un dominio si ottiene il suo indirizzo IPv4, mentre richiedendo i record MX si scoprono i suoi server di posta. Se non si preferisce la riga di comando, uno strumento di ricerca DNS online consente di interrogare i record di qualsiasi dominio dal proprio browser senza dover installare alcun software, rendendo facile verificare se una modifica recente si è propagata o diagnosticare un errore di configurazione.

Prendere l’abitudine di controllare i record DNS rende l’intero sistema più comprensibile. Una volta che riesci a visualizzare i record A, MX e TXT del tuo dominio, quella rubrica telefonica astratta diventa un insieme concreto e comprensibile di voci che puoi controllare. A quel punto, individuare la causa di un sito lento, di un’e-mail respinta o di un avviso relativo al certificato diventa una questione di lettura dei record piuttosto che di supposizioni.

Domande frequenti

Cosa significa DNS?

DNS sta per Domain Name System. È il sistema distribuito che traduce i nomi di dominio leggibili dall’uomo negli indirizzi IP numerici che i computer utilizzano per comunicare tra loro.

Perché il DNS viene definito la rubrica telefonica di Internet?

Proprio come un elenco telefonico consente di cercare il numero di telefono di una persona a partire dal suo nome, il DNS permette al computer di trovare l’indirizzo IP di un sito web a partire dal suo nome di dominio. Tu ricordi il nome facile da ricordare, mentre il DNS si occupa della traduzione nel numero di cui le macchine hanno effettivamente bisogno.

Quanto tempo ci vuole perché le modifiche al DNS entrino in vigore?

Dipende dal TTL del record e da quanto intensamente i resolver lungo il percorso lo abbiano memorizzato nella cache. Le modifiche possono apparire nel giro di pochi minuti se il TTL è breve, ma possono richiedere fino a 24-48 ore per propagarsi completamente in tutto il mondo quando sono ancora in uso valori memorizzati nella cache più vecchi.

Qual è la differenza tra un resolver ricorsivo e un server autoritativo?

Un resolver ricorsivo si occupa di trovare una risposta interrogando altri server per conto dell’utente e memorizzando il risultato nella cache. Un server autoritativo è la fonte definitiva che detiene effettivamente i record di un dominio e fornisce la risposta finale.

Il DNS è crittografato?

Il DNS tradizionale non è crittografato, il che significa che le query viaggiano in testo in chiaro. Standard più recenti come DNS over HTTPS e DNS over TLS crittografano il traffico tra il dispositivo dell’utente e il resolver, mentre il DNSSEC aggiunge firme che verificano l’autenticità delle risposte.

Come posso controllare i record DNS di un dominio?

È possibile utilizzare strumenti da riga di comando come dig o nslookup, oppure un servizio di ricerca DNS basato su browser. Questi strumenti consentono di richiedere tipi di record specifici come A, AAAA, MX e TXT, in modo da poter verificare la configurazione o risolvere eventuali problemi.