--- id: "root-zone" kind: "glossary-term" title: "zona radice" language: "it" category: "DNS e basi tecniche" updated: "2026-10-10T23:13:20Z" canonical: "https://tldlog.com/it/glossario/zona-radice/" translations: en: "https://tldlog.com/glossary/root-zone/" es: "https://tldlog.com/es/glosario/zona-raiz/" de: "https://tldlog.com/de/glossar/root-zone/" fr: "https://tldlog.com/fr/glossaire/zone-racine/" pt-BR: "https://tldlog.com/pt/glossario/zona-raiz/" ru: "https://tldlog.com/ru/glossariy/kornevaya-zona/" zh-Hans: "https://tldlog.com/zh/cihui/genqu/" --- # zona radice Il livello più alto del DNS. Elenca tutti i TLD, come .com o .es, e i name server di ciascuno. Aggiungere un nuovo TLD a internet significa aggiungerlo alla zona radice, con una procedura coordinata tramite l'IANA. La zona radice è il vertice del Domain Name System: un elenco piccolo e pubblico di tutti i domini di primo livello (TLD), come .com o .es, e dei server che rispondono per ciascuno di essi. Quando un resolver non sa dove trovare un TLD, chiede a un root server, che risponde in base alla zona radice. Un TLD funziona su internet solo quando è presente in quell'elenco. ## Che cos'è la zona radice e che cosa contiene Secondo l'IANA, la zona radice è composta principalmente dalle deleghe dei domini di primo livello. Per ogni TLD contiene i name server, sotto forma di record NS, e i record DS che collegano il TLD alla catena di fiducia del DNSSEC. Contiene anche gli indirizzi dei root server stessi. Non contiene singoli domini come example.com: indica soltanto i server di ciascun TLD. Chiunque può scaricare dall'IANA il file completo della zona radice, con gli stessi dati che servono i root server. L'IANA gestisce anche il Root Zone Database, che registra il gestore, i dati tecnici e i contatti di ogni TLD. La zona radice è firmata con il DNSSEC dal luglio 2010. ## Root server: quanti sono e chi li gestisce La zona radice è servita da 13 identità con un nome, da a.root-servers.net a m.root-servers.net. Questo numero conta nomi e indirizzi, non macchine: l'IANA parla di una rete di centinaia di server in molti paesi. Al 9 ottobre 2026 root-servers.org contava 2.047 istanze operative gestite da 12 organizzazioni indipendenti; Verisign gestisce due identità, la a e la j. In base a una dichiarazione dell'RSSAC del 2019, gli operatori devono restare indipendenti tra loro e da qualsiasi governo od organizzazione sovraordinata, e operano sotto giurisdizioni diverse. ## Come si aggiunge o si toglie un TLD dalla radice L'aggiunta di un TLD si chiama delega ed è un passaggio distinto dalla domanda. Per un nuovo gTLD arriva dopo che l'ICANN ha firmato un Registry Agreement e ha svolto i test di pre-delega. Il gestore del registro presenta poi il gestore, i contatti, i name server e i record DS tramite il sistema Root Zone Management dell'IANA, e i suoi record NS vengono inseriti nella zona radice. Ogni modifica della zona radice, compresi i nuovi name server di un TLD esistente, passa per le verifiche e i test tecnici dell'IANA e deve essere confermata dai contatti del TLD prima di essere applicata. Un cambiamento sostanziale nel controllo viene trattato come una ridelega, con criteri propri. Un ccTLD esiste perché il suo paese o territorio ha un codice nella ISO 3166-1. Quando il codice viene eliminato, l'IANA emette una Notice of Removal. A ottobre 2026 il ccTLD viene eliminato dopo cinque anni in via predefinita, o al massimo dopo 10 se si chiede una proroga entro 12 mesi dall'avviso. Il Consiglio di amministrazione dell'ICANN ha adottato questa policy il 22 settembre 2022. Un gTLD il cui Registry Agreement viene risolto, e che l'ICANN non affida a un gestore del registro subentrante, perde la delega; la stringa può essere offerta di nuovo in un futuro round di domande. ## Chi controlla le modifiche: l'IANA, il maintainer e gli operatori - **L'IANA**, le cui funzioni sono svolte da PTI, un'affiliata dell'ICANN, esamina ogni richiesta di modifica e gestisce il Root Zone Database. Le modifiche partono dal gestore del TLD, che le presenta online e deve confermarle. - **Verisign**, in qualità di Root Zone Maintainer in base a un accordo con l'ICANN, compila la zona su indicazione dell'IANA, la firma con la zone signing key e la invia agli operatori. A ottobre 2026 l'accordo (firmato il 28 settembre 2016 e modificato il 20 ottobre 2024) ha periodi di otto anni che si rinnovano automaticamente. - **Gli operatori dei root server** servono la zona esattamente come viene distribuita. L'RSSAC001 (dicembre 2015) osserva che un operatore non potrebbe alterare i dati firmati senza invalidarne le firme. ## Miti sullo «spegnimento di internet» dalla radice - **Non esiste un unico interruttore.** Dodici operatori indipendenti in giurisdizioni diverse gestiscono più di 2.000 istanze. - **Gli operatori non possono modificare le voci di nascosto.** Le firme DNSSEC renderebbero visibile una modifica. - **Un breve guasto si nota appena.** Secondo la RFC 8806, i resolver di solito tengono in cache i dati dei TLD per circa un giorno o due. Questo non rende la radice invulnerabile. Il 23 dicembre 2025 un attacco DDoS ha colpito 10 delle 13 identità, ha superato al picco un terabit al secondo ed è durato poco meno di dieci minuti. Il rapporto degli operatori del luglio 2026 non ha rilevato errori noti visibili agli utenti finali, solo lievi ritardi per alcune ricerche, e attribuisce il risultato all'indipendenza e alla diversità degli operatori. ## Copie locali della radice e perché i resolver le conservano Un resolver parte normalmente dai root hints, un breve elenco di nomi e indirizzi dei root server, di solito incluso nel suo software; l'IANA ne pubblica la versione ufficiale. All'avvio il resolver chiede a un root server l'elenco aggiornato, un passaggio chiamato priming (RFC 9609, febbraio 2025), perché gli indirizzi dei root server cambiano di tanto in tanto. Una radice iperlocale va oltre: il resolver conserva una copia completa della zona radice sulla stessa macchina e risponde solo a sé stesso (RFC 8806, giugno 2020). La copia deve essere convalidata con il DNSSEC e identica alla zona reale; se non può essere aggiornata in tempo, il resolver deve tornare subito ai root server. Gli obiettivi dichiarati sono l'affidabilità durante gli attacchi e la riservatezza. La RFC 8806 prevede pochi vantaggi di velocità per i TLD esistenti, che di solito sono già in cache, e avverte che una configurazione errata può fornire dati sbagliati agli utenti. Una radice iperlocale copia la zona ufficiale; una radice alternativa la modifica. Al 9 ottobre 2026 il rollover della KSK della radice è previsto per l'11 ottobre 2026, quando la KSK-2024 subentra alla KSK-2017. I resolver che convalidano, comprese le radici iperlocali, hanno bisogno del trust anchor aggiornato. ## Fonti - [Root Zone Management (IANA)](https://www.iana.org/domains/root) - [Root Zone Change Request Process (IANA)](https://www.iana.org/help/root-zone-process) - [December 2025 DDoS against multiple DNS root servers (root server operators)](https://root-servers.org/media/news/2025-12-23_DDoS.pdf) - [RFC 8806: Running a Root Server Local to a Resolver](https://www.rfc-editor.org/rfc/rfc8806.txt) ## termini correlati - [server radice](https://tldlog.com/it/glossario/server-radice/) - [delega (TLD)](https://tldlog.com/it/glossario/delega-tld/) - [IANA](https://tldlog.com/it/glossario/iana/) - [PTI](https://tldlog.com/it/glossario/pti/)