edubun
Italiano

DNS: trasformare i nomi in indirizzi

I 13 name server radice sono gestiti da 12 organizzazioni con 2047 macchine in tutto il mondo (root-servers.org, 17 ottobre 2026).

ContestoPrima del DNS ogni computer di ARPANET teneva una copia di un unico file di testo, HOSTS.TXT, con l'elenco di tutti i nomi degli host e dei loro indirizzi. Lo curava il Network Information Center dello Stanford Research Institute, e ogni sede ne scaricava copie aggiornate. Man mano che la rete cresceva, cresceva anche il file, le modifiche ci mettevano più tempo a diffondersi e i nomi entravano in conflitto. La RFC 1034 descrive questo problema e il progetto che lo sostituì: un albero di nomi, in cui ogni parte è curata dai propri server. Il DNS fu pubblicato come RFC 1034 e RFC 1035 nel 1987.

Oggi nessuno scarica più quel file. Scrivi example.com invece di 198.51.100.20, e il nome viene cercato nel momento in cui ti serve. I router però capiscono ancora solo i numeri, quindi prima che il browser possa mandare un solo pacchetto a un sito, il nome deve diventare un indirizzo. Lo fa il Domain Name System (DNS), che la guida di Cloudflare chiama l'elenco telefonico di internet.

Un nome è un percorso che scende lungo un albero

Leggi www.example.com da destra. In cima c'è la radice, scritta come un punto invisibile. Sotto ci sono i domini di primo livello (TLD) come com, org e kr. Sotto com c'è example, e sotto ancora www. Ogni pezzo è un'etichetta; la RFC 1035 ammette fino a 63 byte per etichetta e 255 byte per un nome intero. Organizzazioni diverse gestiscono rami diversi dell'albero, quindi nessun computer deve conoscere tutti i nomi, ed era proprio questo il guaio di HOSTS.TXT, dove un solo file su ogni macchina cercava di contenerli tutti.

L'albero del DNS. www.example.com è il percorso www → example → com → radice, che si legge da sinistra a destra ma si cerca partendo dalla radice verso il basso.

Quattro server, otto passi

Cloudflare elenca quattro tipi di server in una ricerca. Il resolver ricorsivo, gestito di solito dal tuo provider o da un servizio DNS pubblico, fa il lavoro al posto tuo. Un server radice sa dove sono i server TLD. Un server TLD, come quello di com, sa quali server contengono ogni dominio sotto di lui. Il server autoritativo di un dominio contiene i suoi record veri e propri e dà la risposta finale. Senza niente in cache, una ricerca richiede otto passi. Il tuo computer chiede al resolver. Il resolver chiede alla radice, che lo rimanda a com. Chiede a com, che lo rimanda ai name server del dominio. Chiede a loro, loro rispondono con l'indirizzo, e il resolver ti restituisce l'indirizzo.

Caricamento

Trascina per ruotare. Scorri o avvicina le dita per lo zoom.

Premi Passo successivo otto volte, oppure Riproduci. Poi premi Cerca di nuovo: risponde subito la cache del browser e nessun messaggio esce dal computer. Premi Aspetta 1 minuto e cerca di nuovo: la copia del browser è scaduta ma la cache del SO ce l'ha ancora. Premi Aspetta 1 ora: il TTL di 3600 secondi è scaduto ovunque e la ricerca completa ricomincia.

Perché la seconda ricerca è istantanea

Se ogni ricerca richiedesse otto passi, il DNS sarebbe lento e i server radice affogherebbero nelle domande. Per questo le risposte vengono conservate. Restano in cache nel browser, nel sistema operativo e nel resolver. Ogni record arriva con un tempo di vita in secondi, fissato dal proprietario del dominio. Un TTL di 3600 vuol dire «puoi riusare questa risposta per un'ora». Un TTL breve permette al proprietario di spostare un sito in fretta; uno lungo risparmia ricerche. Anche i server radice sono sparsi: i 13 server radice con un nome, da a a m, il 17 ottobre 2026 funzionavano come 2047 istanze separate.

Due tipi di domanda, una porta

Una ricerca mescola due tipi di domanda. Il tuo computer manda al resolver una richiesta ricorsiva, che significa «dammi la risposta finale o un errore». Il resolver poi manda richieste iterative ai server radice, TLD e autoritativo, e ognuno risponde con il meglio che ha, spesso solo un rinvio al server successivo. I messaggi DNS vanno alla porta 53, di solito su UDP perché una domanda e una risposta stanno ciascuna in un pacchetto. Le risposte grandi e i trasferimenti tra server usano TCP, che la RFC 7766 rende parte obbligatoria di ogni implementazione completa del DNS. Puoi provarlo tu stesso. Sulla maggior parte dei computer il comando nslookup example.com stampa il resolver usato e gli indirizzi ricevuti.

I record contengono più che indirizzi

RecordContieneEsempio
AUn indirizzo IPv4www.example.com → 198.51.100.20
AAAAUn indirizzo IPv6 (RFC 3596)www.example.com → 2001:db8::20
CNAMEUn altro nome da cercare al suo postoshop.example.com → example.com
MXIl server di posta del dominioexample.com → mail.example.com
NSI name server autoritativiexample.com → ns1.example.com
  1. Una ricerca di www.example.com senza cache: a quali server chiede il resolver, e in che ordine?
  2. Quale server dà la risposta finale per www.example.com?
    • Il server autoritativo di example.com
    • Il server radice
    • Il server TLD di com
    • Il server web
  3. Quanti passi richiede una ricerca senza cache nella descrizione di Cloudflare?
  4. Quale record contiene un indirizzo IPv6?
    • AAAA
    • A
    • MX
    • CNAME
  5. Un record ha TTL 3600. Per quanti minuti una cache può riusarlo?
  6. Quanto può essere lunga al massimo una singola etichetta (come example) secondo la RFC 1035?
  7. Quanti server radice con un nome ci sono?
  8. Hai cercato un nome 10 secondi fa e la cache del browser lo conserva per 60 secondi. Quanti messaggi DNS escono dal computer se lo cerchi di nuovo adesso?
  9. A che cosa serve un record MX?
    • A indicare il server di posta di un dominio
    • A conservare una pagina web
    • A contenere un indirizzo IPv6
    • A fissare il TTL degli altri record
  10. Che cosa ha sostituito il DNS?
    • Un unico file HOSTS.TXT copiato su ogni computer
    • La rete telefonica
    • Indirizzi IP
    • I router
Errori comuni
  • «Il DNS conserva le pagine web.» Il DNS risponde solo con record come indirizzi, server di posta e altri nomi. La pagina vera e propria arriva dal server web all'indirizzo restituito dal DNS.
  • «Quando un sito cambia indirizzo, tutti vedono subito quello nuovo.» Browser, sistemi operativi e resolver tengono la vecchia risposta finché il suo TTL non scade. Con un TTL di 3600, alcuni visitatori possono essere mandati al vecchio indirizzo ancora per un'ora.
  • «Ci sono esattamente 13 computer server radice.» Ci sono 13 nomi, da a a m, gestiti da 12 organizzazioni. Il 17 ottobre 2026 rispondevano da 2047 istanze in tutto il mondo.
  • «Il mio computer chiede direttamente al server radice.» Il tuo computer chiede una volta sola al resolver ricorsivo. È il resolver che va dalla radice al server TLD fino al server autoritativo, e ti restituisce solo il risultato.
Nota per l'insegnantePrima di disegnare qualsiasi cosa, leggete insieme qualche nome da destra a sinistra: è la prima abitudine da costruire. Il resolver è il riquadro che manca nei disegni dei ragazzi, quindi disegnatelo separato dal computer e fate fermare lì ogni freccia che parte dal computer. Fate girare una volta gli otto passi del simulatore, poi premete subito Cerca di nuovo. Una seconda ricerca che non manda niente spiega la cache meglio di una definizione. Se avete un terminale, nslookup su un sito che la classe conosce già trasforma lo schema in qualcosa di reale.
Punti chiave
  • Il DNS trasforma i nomi in indirizzi; i nomi si leggono da destra a sinistra scendendo lungo un albero.
  • Resolver ricorsivo → radice → TLD → autoritativo: otto passi senza niente in cache.
  • Le risposte restano in cache nel browser, nel SO e nel resolver per il TTL del record (in secondi).
  • A = IPv4, AAAA = IPv6, CNAME = alias, MX = posta, NS = name server.
Fonti di questo corso (28)
  • (checked 2026-10-17; reordered 2026-10-19: standards first, then official documentation, then operators and papers, history sources last)
  • IETF RFCs (rfc-editor.org): RFC 768 UDP (1980, 8-byte header)
  • RFC 791 IPv4 (1981, 32-bit addresses, "does not provide a reliable communication facility", TTL field "measured in units of seconds" but every module must decrease it by at least one, so it is only an upper bound)
  • RFC 792 ICMP (Time Exceeded)
  • RFC 801 NCP/TCP transition plan (1 January 1983)
  • RFC 894 Ethernet (1500-byte payload)
  • RFC 1034 and RFC 1035 DNS (1987, HOSTS.TXT kept by SRI-NIC, labels up to 63 octets and names up to 255, TTL in seconds)
  • RFC 1122 (127.0.0.0/8 loopback)
  • RFC 1918 private addresses (10/8, 172.16/12, 192.168/16)
  • RFC 2131 DHCP, RFC 3022 NAT, RFC 3596 AAAA records, RFC 3849 and RFC 5737 documentation addresses, RFC 4271 BGP-4, RFC 4291 IPv6 text form, RFC 6298 TCP retransmission timer (initial RTO 1 second)
  • RFC 6335 port ranges (0-1023, 1024-49151, 49152-65535)
  • RFC 7766 DNS over TCP, RFC 8200 IPv6 (128-bit addresses, Hop Limit)
  • RFC 8446 TLS 1.3 (one round-trip handshake)
  • RFC 9000 QUIC and RFC 9114 HTTP/3, RFC 9110 HTTP semantics (status code classes)
  • RFC 9293 TCP (three-way handshake, sequence numbers)
  • IANA: ip-parameters registry (recommended default TTL 64)
  • IPv4 free pool depleted 3 February 2011 (NRO and ARIN announcements)
  • Official documentation: MDN Web Docs "How does the Internet work?" (45 cables for 10 computers, switches, routers, MAC and IP addresses, internet and web)
  • "What is a URL?", "HTTP response status codes" (developer.mozilla.org)
  • Cloudflare Learning Center: "What is DNS?" (four kinds of DNS server, 8 steps of an uncached lookup, browser and OS caches, TTL)
  • "What is HTTP/3?" (cloudflare.com/learning)
  • Google Chrome Help, "Browse in Incognito mode" (support.google.com/chrome/answer/95464, checked 2026-10-19: Incognito limits what is saved to the device; websites and organisations that manage your network, like your school, employer or internet service provider, may be able to observe your activity)
  • Operators and papers: root-servers.org (13 root name servers run by 12 organisations, 2047 instances on 2026-10-17)
  • Jacobson and Karels 1988, Congestion Avoidance and Control (loss mostly congestion)
  • History blocks only: UCLA Samueli School of Engineering, Internet50 (first ARPANET message "LO", UCLA to SRI, 29 October 1969, 22:30)
  • historyofinformation.com and Wikipedia ARPANET (Kline)
  • Spiceworks/SRI history (HOSTS.TXT kept by SRI-NIC)
  • Numbers (2^32, 2^96, 45 and 6 cables, packet counts, round-trip times)

Consultato il: 2026-10-17