Scopri come Paul Mockapetris ha creato il DNS, sostituendo gli ingombranti file HOSTS.TXT con un sistema di denominazione scalabile. Scopri come funziona il DNS, perché la cache è importante e le basi della sicurezza.
Ogni volta che scrivi un indirizzo web, clicchi un link o invii un'email, fai affidamento su un'idea semplice: gli esseri umani dovrebbero poter usare nomi memorabili, mentre i computer fanno il lavoro di trovare la macchina giusta.
Il DNS risolve un problema quotidiano: i computer comunicano usando indirizzi numerici (indirizzi IP) come 203.0.113.42, ma le persone non vogliono memorizzare stringhe di numeri. Vuoi ricordare example.com, non quale indirizzo quel sito usa oggi.
Il Domain Name System (DNS) è la “rubrica” di Internet che traduce nomi di dominio comprensibili alle persone negli indirizzi IP che i computer usano per connettersi.
Questa traduzione sembra semplice, ma è la differenza tra un Internet usabile e uno che sembra una rubrica telefonica scritta interamente in cifre.
Questa è una panoramica non tecnica—non serve esperienza di networking. Passeremo in rassegna:
Lungo il percorso incontrerai Paul Mockapetris, l'ingegnere che ha progettato il DNS all'inizio degli anni '80. Il suo lavoro è importante perché non ha solo creato un nuovo formato di nomi: ha progettato un sistema che potesse scalare mentre Internet si espandeva da una piccola rete di ricerca a qualcosa usato da miliardi di persone.
Se hai mai avuto un sito che “non andava”, aspettato che una modifica al dominio “si propagasse”, o ti sei chiesto perché le impostazioni email includono voci DNS misteriose, hai già visto il DNS dall'esterno. Il resto di questo articolo spiega cosa succede dietro le quinte—in modo chiaro e senza gergo.
Molto prima che qualcuno digiti un indirizzo web familiare, le reti iniziali avevano un problema più semplice: come raggiungi una macchina specifica? I computer potevano comunicare usando indirizzi IP (numeri come 10.0.0.5), ma gli umani preferivano hostname—etichette brevi come MIT-MC o SRI-NIC più facili da ricordare e condividere.
Per l'ARPANET iniziale, la soluzione era un singolo file condiviso chiamato HOSTS.TXT. Era essenzialmente una tabella di consultazione: un elenco di hostname accoppiati ai loro indirizzi IP.
Ogni computer teneva una copia locale di questo file. Se volevi connetterti a una macchina per nome, il sistema controllava HOSTS.TXT e trovava l'indirizzo IP corrispondente.
Questo funzionava all'inizio perché la rete era piccola, i cambiamenti erano relativamente rari e c'era un luogo chiaro da cui ottenere gli aggiornamenti.
Con l'arrivo di più organizzazioni, l'approccio ha cominciato a cedere sotto la crescita normale:
La questione centrale era la coordinazione. HOSTS.TXT era come un'unica rubrica condivisa per tutto il mondo. Se tutti dipendono dallo stesso libro, ogni correzione richiede una modifica globale e tutti devono scaricare la versione più recente rapidamente. Raggiunta una certa dimensione, quel modello “un file per tutto” diventò troppo lento, troppo centralizzato e troppo soggetto a errori.
Il DNS non ha sostituito l'idea di mappare nomi a numeri—ha sostituito il modo fragile in cui quella mappatura veniva mantenuta e distribuita.
All'inizio degli anni '80, Internet stava passando da una piccola rete di ricerca a qualcosa di più grande, disordinato e ampiamente condiviso. Sempre più macchine si univano, le organizzazioni volevano autonomia e le persone avevano bisogno di un modo più semplice per raggiungere i servizi che memorizzare indirizzi numerici.
Paul Mockapetris, che lavorava in quel contesto, è ampiamente riconosciuto come il progettista del DNS. Il suo contributo non fu un prodotto appariscente—fu una risposta d'ingegneria a una domanda molto pratica: come mantenere i nomi usabili quando la rete continua a crescere?
Un sistema di denominazione sembra semplice finché non immagini cosa significava “semplice” allora: una lista condivisa di nomi che tutti dovevano scaricare e aggiornare. Quel metodo crolla non appena il cambiamento diventa costante. Ogni nuovo host, rinomina o correzione si trasforma in lavoro di coordinazione per tutti.
L'intuizione chiave di Mockapetris fu che i nomi non sono solo dati; sono accordi condivisi. Se la rete si espande, il sistema per creare e distribuire quegli accordi deve espandersi anch'esso—senza richiedere a ogni computer di recuperare costantemente una lista maestra.
Il DNS ha sostituito l'idea di “un file autoritativo” con un design distribuito:
Questa è la brillantezza silenziosa: il DNS non è stato progettato per essere elegante, ma per continuare a funzionare sotto vincoli reali—banda limitata, cambi frequenti, molti amministratori indipendenti e una rete che non smetteva di crescere.
Il DNS non fu inventato come un trucco intelligente—fu progettato per risolvere problemi specifici e molto pratici che emersero con la crescita di Internet. L'approccio di Mockapetris fu fissare obiettivi chiari e poi costruire un sistema di denominazione in grado di reggere per decenni.
Il concetto chiave è la delegation: diversi gruppi gestiscono diverse parti dell'albero dei nomi.
Per esempio, un'organizzazione gestisce ciò che è sotto .com, un registrar ti aiuta a rivendicare example.com, e poi tu (o il tuo provider DNS) controlli i record per www.example.com, mail.example.com, e così via. Questo divide chiaramente la responsabilità, così la crescita non crea un collo di bottiglia.
Il DNS presume che i problemi accadranno—i server crashano, le reti si partizionano, le rotte cambiano. Perciò si basa su più server autorevoli per un dominio e sulla cache nei risolutori, così un'interruzione temporanea non rompe immediatamente ogni ricerca.
Il DNS traduce nomi comprensibili in dati tecnici, più famosamente indirizzi IP. Non è “Internet” stessa—è un servizio di denominazione e ricerca che aiuta i tuoi dispositivi a trovare dove connettersi.
Il DNS rende i nomi gestibili organizzandoli come un albero. Invece di una lista gigante dove ogni nome deve essere univoco a livello globale (e qualcuno deve controllarlo), il DNS suddivide i nomi in livelli e delega la responsabilità.
Un nome DNS si legge da destra a sinistra:
www.example.com. termina tecnicamente con un ..com, .org, .net, codici paese come .ukexample in example.comwww in www.example.comQuindi www.example.com si può scomporre in:
com (il TLD)example (il dominio registrato sotto .com)www (un'etichetta che il proprietario del dominio crea e controlla)Questa struttura riduce i conflitti perché i nomi devono essere univoci solo all'interno del loro padre. Molte organizzazioni possono avere un sottodominio www, perché www.example.com e www.another-example.com non collidono.
Sparge anche il carico di lavoro. Gli operatori di .com non devono gestire i record di ogni sito; si limitano a indicare chi è responsabile per example.com, e poi il proprietario di example.com gestisce i dettagli.
Una zona è semplicemente un pezzo gestibile di quell'albero—i dati DNS di cui qualcuno è responsabile. Per molti team, “la nostra zona” significa “i record DNS per example.com e i sottodomini che ospitiamo,” memorizzati sul loro provider DNS autorevole.
Quando digiti un nome in un browser, non stai chiedendo direttamente “a Internet”. Alcuni aiutanti specializzati dividono il lavoro così la risposta può essere trovata in modo rapido e affidabile.
Tu (il tuo dispositivo e browser) inizi con una richiesta semplice: “Qual è l'indirizzo IP corrispondente a example.com?” Il tuo dispositivo di solito non conosce ancora la risposta e non vuole interrogare dozzine di server per scoprirlo.
Un resolver ricorsivo fa la ricerca per tuo conto. Di solito è fornito dal tuo ISP, dall'IT del tuo lavoro/scuola o da un resolver pubblico. Il vantaggio chiave: può riutilizzare risposte memorizzate in cache da ricerche precedenti, accelerando le cose per tutti gli utenti che lo usano.
I server DNS autorevoli sono la fonte di verità per un dominio. Non “cercano” in Internet; contengono i record ufficiali che dicono quali IP, server di posta o token di verifica appartengono a quel dominio.
example.com.Considera il resolver ricorsivo come un bibliotecario che può cercare le informazioni per te (e si ricorda le risposte più richieste), mentre un server autorevole è il catalogo ufficiale dell'editore: non sfoglia altri cataloghi, ma afferma cosa è vero per i suoi libri.
Quando digiti example.com nel browser, il browser non cerca un nome—ha bisogno di un indirizzo IP (un numero come 93.184.216.34) per sapere dove connettersi. Il DNS è il sistema “trova il numero per questo nome”.
Il browser prima chiede al sistema operativo del tuo computer/telefono: “Conosci già l'IP di example.com?” Il sistema operativo controlla la sua memoria a breve termine (cache). Se trova una risposta fresca, la ricerca finisce lì.
Se il sistema operativo non ce l'ha, inoltra la domanda a un resolver DNS—di solito gestito dal tuo ISP, dalla tua azienda o da un provider pubblico. Pensa al resolver come al tuo “concierge DNS”: fa il lavoro sporco così il tuo dispositivo non deve farlo.
Se il resolver non ha la risposta in cache, avvia una ricerca guidata:
.com). Il server root non fornisce l'IP finale—dà referenze, cioè indicazioni: “Chiedi a questi server .com.”.com): il resolver chiede ai server .com dove si trova example.com. Di nuovo, non è l'IP finale—altre indicazioni: “Chiedi a questo server autorevole per example.com.”A o AAAA) contenente l'indirizzo IP.Il resolver invia l'IP al tuo sistema operativo, poi al browser, che può finalmente connettersi. Molte ricerche sembrano istantanee perché resolver e dispositivi memorizzano le risposte in cache per un periodo stabilito dal proprietario del dominio (TTL).
Un flusso facile da ricordare: Browser → cache OS → cache resolver → Root (referenza) → TLD (referenza) → Autorevole (risposta) → Browser.
Il DNS sarebbe lento se ogni visita a un sito richiedesse di ricominciare da zero interrogando più server per la stessa risposta. Invece, il DNS fa affidamento sulla cache—una “memoria” temporanea delle ricerche recenti—così la maggior parte degli utenti ottiene risposte in millisecondi.
Quando il tuo dispositivo chiede a un resolver DNS example.com, quel resolver potrebbe dover fare lavoro la prima volta. Dopo aver appreso la risposta, la memorizza in cache. La prossima persona che chiede lo stesso nome può essere soddisfatta immediatamente.
La cache esiste per due motivi principali:
Ogni record DNS è servito con un valore TTL (Time To Live). Pensa al TTL come a un'istruzione che dice: conserva questa risposta per X secondi, poi scartala e ricontrolla.
Se un record ha un TTL di 300, i resolver possono riutilizzarlo per fino a 5 minuti prima di ricontrollare.
Il TTL è un equilibrio:
Se stai spostando un sito su un nuovo host, cambiando CDN o facendo un cutover delle email (modificando record MX), il TTL determina quanto velocemente gli utenti smettono di andare al vecchio posto.
Un approccio comune è abbassare i TTL in anticipo rispetto a una modifica pianificata, effettuare il cambio e poi rialzare i TTL quando tutto è stabile. Ecco perché il DNS può essere veloce nella routine quotidiana—e perché può sembrare “ostinato” subito dopo un aggiornamento.
Quando accedi a un pannello DNS, in genere modificherai una manciata di tipi di record. Ogni record è una piccola istruzione che dice a Internet dove inviare le persone (web), dove consegnare la posta o come verificare la proprietà.
| Record | Cosa fa | Esempio semplice |
|---|---|---|
| A | Punta un nome a un indirizzo IPv4 | example.com → 203.0.113.10 (il tuo server web) |
| AAAA | Punta un nome a un indirizzo IPv6 | example.com → 2001:db8::10 (stesso concetto, indirizzamento più recente) |
| CNAME | Fa di un nome un alias di un altro nome | www.example.com → example.com (così entrambi puntano allo stesso posto) |
| MX | Dice dove deve andare la posta del dominio | example.com → mail.provider.com (priorità 10) |
| TXT | Memorizza “note” che le macchine possono leggere (verifica, policy email) | example.com ha un record SPF come v=spf1 include:mailgun.org ~all |
| NS | Indica quali server autorevoli ospitano il DNS per un dominio/zona | example.com → ns1.dns-host.com |
| SOA | L'intestazione della zona: NS primario, contatto admin e valori di temporizzazione | L'SOA di example.com include ns1.dns-host.com e i timer di retry/expire |
Alcuni errori DNS ricorrono frequentemente:
example.com). Molti provider DNS non lo permettono perché il nome radice deve anche contenere record come NS e SOA. Se hai bisogno che la radice punti a un hostname, usa un record A/AAAA o una funzionalità “ALIAS/ANAME” se il provider la supporta.www). Scegli un approccio.mail.provider.com può rompere la posta; punti mancanti/in più e il campo host sbagliato (es. @ vs www) sono cause comuni di interruzioni.Se condividi indicazioni DNS con un team, una piccola tabella come quella sopra nei tuoi documenti (o in una pagina runbook) velocizza revisioni e troubleshooting.
Il DNS funziona perché la responsabilità è distribuita tra molte organizzazioni. Questa suddivisione è anche il motivo per cui puoi cambiare provider, modificare impostazioni e mantenere il tuo nome online senza chiedere il permesso a “Internet”.
Registrare un dominio significa acquistare il diritto di usare un nome (come example.com) per un periodo di tempo. È come riservare un'etichetta in modo che nessun altro la possa reclamare.
Ospitare il DNS significa gestire le impostazioni che dicono al mondo dove quel nome deve puntare—il tuo sito, il provider di posta, i record di verifica e così via. Puoi registrare un dominio con una società e ospitare il DNS con un'altra.
.com, .org o .uk. Mantiene il database ufficiale di chi possiede ogni nome sotto quel TLD e quali name server sono responsabili.I server root stanno in cima al DNS. Non conoscono l'IP del tuo sito e non memorizzano i record del tuo dominio. Il loro compito è più stretto: dicono ai resolver dove trovare i server autorevoli per ogni TLD (ad esempio dove si gestisce .com).
Quando imposti i “name server” per il tuo dominio dal registrar, stai creando una delegation. Il registry di .com (tramite i suoi server autorevoli) punterà allora le query per example.com ai name server che hai scelto.
Da quel momento, quei name server controllano le risposte che il resto di Internet riceve—fino a che non cambi nuovamente la delega.
Il DNS si basa sulla fiducia: quando digiti un nome, ti aspetti che la risposta punti al servizio reale. La maggior parte delle volte è così—ma il DNS è anche un bersaglio privilegiato, perché una piccola modifica su “dove punta questo nome” può reindirizzare molte persone.
Un problema classico è lo spoofing o cache poisoning. Se un attaccante riesce a convincere un resolver a memorizzare una risposta falsa, gli utenti possono essere inviati all'IP sbagliato anche se digitano il dominio corretto. Il risultato può essere pagine di phishing, download di malware o traffico intercettato.
Un altro problema è il dirottamento del dominio a livello di registrar. Se qualcuno entra nel tuo account registrar, può cambiare name server o record DNS e praticamente “prendere” il tuo dominio senza toccare l'hosting del sito.
Poi c'è il pericolo quotidiano: le configurazioni errate. Un CNAME errato, un TXT obsoleto o un MX sbagliato possono rompere i flussi di login, la consegna delle email o i controlli di verifica. Questi guasti spesso sembrano “Internet non funziona”, ma la causa è una piccola modifica DNS.
DNSSEC aggiunge firme crittografiche ai dati DNS. In parole semplici: la risposta DNS può essere verificata per confermare che non è stata alterata in transito e che proviene veramente dal server autorevole del dominio. DNSSEC non cifra le query DNS né nasconde cosa cerchi, ma può prevenire molte forme di risposte contraffatte.
Le query DNS tradizionali sono facilmente osservabili dalle reti. DNS-over-HTTPS (DoH) e DNS-over-TLS (DoT) cifrano la connessione tra il tuo dispositivo e un resolver, riducendo lo spionaggio e una parte della manipolazione in transito. Non rendono il DNS “anonimo”, ma cambiano chi può vedere e manipolare le query.
Usa MFA sul registrar, abilita blocchi di trasferimento/domino, e limita chi può modificare il DNS. Tratta le modifiche DNS come deploy di produzione: richiedi revisioni, tieni un registro delle modifiche e configura monitoraggio/alert per cambi di record o name server così da venire avvisati rapidamente di sorprese.
Il DNS può sembrare “impostalo e dimenticalo”, finché una piccola modifica non manda in crash sito o email. La buona notizia: poche abitudini rendono la gestione DNS prevedibile—even per team piccoli.
Inizia con un processo leggero e ripetibile:
La maggior parte dei problemi DNS non è complessa—sono solo difficili da notare subito.
Se distribuisci app frequentemente, il DNS entra nel tuo processo di rilascio. Per esempio, team che pubblicano app su piattaforme come Koder.ai (dove puoi costruire e distribuire app via chat, poi collegare domini personalizzati) usano gli stessi fondamenti: target A/AAAA/CNAME corretti, TTL sensati durante i cutover e una chiara strada per il rollback se qualcosa punta al posto sbagliato.
Se invii email dal tuo dominio, il DNS influenza direttamente se i messaggi arrivano nelle caselle di posta.
I nomi comprensibili hanno permesso a Internet di scalare oltre una piccola comunità di ricerca. Tratta il DNS come infrastruttura condivisa—un po' di cura iniziale mantiene il tuo sito raggiungibile e la tua email attendibile mentre cresci.
DNS (Domain Name System) traduce nomi comprensibili come example.com in indirizzi IP come 93.184.216.34 in modo che il tuo dispositivo sappia dove connettersi.
Senza il DNS, dovresti ricordare gli indirizzi numerici di ogni sito e servizio che usi.
Le prime reti usavano un singolo file condiviso (HOSTS.TXT) che mappava nomi su indirizzi IP.
Con la crescita della rete, questo diventò ingestibile: aggiornamenti continui, nomi in conflitto e interruzioni causate da copie obsolete. Il DNS ha sostituito l'approccio del “file globale unico” con un sistema distribuito.
Paul Mockapetris ha progettato il DNS nei primi anni '80 per risolvere il problema di scalabilità dei nomi su una rete in rapida crescita.
L'idea chiave fu la delegation: dividere la responsabilità tra molte organizzazioni in modo che nessun elenco maestro (o amministratore) diventasse un collo di bottiglia.
I nomi DNS sono gerarchici e si leggono da destra a sinistra:
www.example.com..comexample.comwww.example.comQuesta gerarchia rende pratiche la delega e la gestione su scala globale.
Un resolver ricorsivo cerca le risposte per tuo conto e le memorizza nella cache (spesso gestito da un ISP, dal tuo posto di lavoro o da un provider pubblico).
Un server DNS autorevole è la fonte di verità per i record di un dominio; non "cerca" altrove, ma risponde per la zona di cui è responsabile.
Un tipico lookup procede così:
.com) → i server autorevoli del dominio.A/).TTL (Time To Live) indica ai resolver per quanto tempo possono memorizzare una risposta DNS prima di controllare di nuovo.
La "propagazione" è per lo più dovuta alle cache che scadono in tempi diversi.
I record più comuni che gestirai sono:
Un registrar è dove registri/rielargisci il dominio (il tuo diritto di usare example.com).
Un DNS host/provider gestisce i server autorevoli e i record DNS. Puoi registrare il dominio con una società e ospitare il DNS con un'altra modificando i record NS presso il registrar.
Il DNS può fallire a causa di:
Contromisure pratiche:
AAAAAAAAACNAME: rende un hostname alias di un altro (comune per www).MX: indica dove deve essere recapitata la posta del dominio.TXT: verifica e autenticazione email (SPF, DKIM, DMARC).NS: quali server sono autorevoli per il dominio.Regola pratica: non mettere CNAME e A sullo stesso hostname.