--- id: "name-collision" kind: "glossary-term" title: "collisione di nomi" language: "it" category: "Sistemi di nomi alternativi" updated: "2026-10-10T23:13:06Z" canonical: "https://tldlog.com/it/glossario/collisione-nomi/" translations: en: "https://tldlog.com/glossary/name-collision/" es: "https://tldlog.com/es/glosario/colision-nombres/" de: "https://tldlog.com/de/glossar/namenskollision/" fr: "https://tldlog.com/fr/glossaire/collision-noms/" pt-BR: "https://tldlog.com/pt/glossario/colisao-nomes/" ru: "https://tldlog.com/ru/glossariy/kolliziya-imen/" zh-Hans: "https://tldlog.com/zh/cihui/mingcheng-chongtu/" --- # collisione di nomi Un problema che si verifica quando un nome di una rete privata esiste anche nel DNS pubblico e indirizza i computer nel posto sbagliato. Il round del 2012 ha usato l'interruzione controllata (controlled interruption), un periodo di prova che avvisava le reti interessate. Per il Round 2026, il Name Collision Risk Management Framework dell'ICANN (quadro di gestione del rischio di collisione) prevede una valutazione iniziale, una delega temporanea e correttivi per i nomi ad alto rischio. Si ha una collisione di nomi quando un nome destinato a un sistema di denominazione, spesso la rete privata di un'azienda, riceve una risposta da un altro, di solito il DNS pubblico. Il traffico può allora non arrivare a destinazione o finire dove nessuno voleva. Il rischio si presenta ogni volta che un nuovo nome viene aggiunto a internet, quindi l'ICANN lo verifica per ogni TLD richiesto. ## Che cos'è una collisione di nomi L'Applicant Guidebook (AGB) 2026 dell'ICANN la definisce come un nome destinato a essere risolto in un sistema di denominazione che viene risolto per errore in un altro, con il rischio di interrompere o deviare la comunicazione. Il caso classico è quello di un utente che vuole raggiungere una risorsa su una rete privata e, senza saperlo, raggiunge lo stesso nome nel DNS pubblico. Il rischio non riguarda solo i nomi di primo livello: secondo l'ICANN, qualsiasi nuovo gTLD, ccTLD o nome di secondo livello può crearlo. Il Name Collision Analysis Project (NCAP) dello SSAC afferma che il problema è noto da decenni, forse già dalla fine degli anni Ottanta. ## Perché succede: nomi privati e nuovi TLD Molte organizzazioni hanno dato alle proprie reti interne una terminazione che non esisteva nel DNS pubblico. Le query per quei nomi escono verso la radice pubblica. Quando la stessa stringa viene delegata come nuovo gTLD, quelle query iniziano a ricevere risposte reali. Le liste di ricerca aggravano il problema: un dispositivo aggiunge a un nome breve, uno alla volta, i suffissi di un elenco finché uno non funziona. L'NCAP conta forse una dozzina o più di cause all'origine. Nel round del 2012, su circa 1.400 stringhe richieste, tre sono state giudicate ad alto rischio: .corp, .home e .mail. L'ICANN le ha rinviate a tempo indeterminato nel 2014, e il 7 settembre 2024 il Consiglio di amministrazione dell'ICANN ha deciso di non farle rivalutare. ## Nomi riservati e nomi per usi speciali Due sistemi distinti tengono alcuni nomi fuori dalla radice. - **L'IETF** riserva i nomi a dominio per usi speciali in base alla RFC 6761, in un registro gestito dall'IANA. Tra le voci di primo livello ci sono .test, .example, .invalid, .localhost, .local, .onion per la rete Tor e .alt per i sistemi di denominazione esterni al DNS. Sono elencati anche alcuni nomi sotto .arpa, come home.arpa per le reti domestiche. Il dominio .arpa in sé è un TLD infrastrutturale gestito dall'IANA, non un nome per usi speciali nel suo insieme. - **L'ICANN** tiene nell'AGB un elenco di Blocked Names (nomi bloccati). Comprende tutti i nomi per usi speciali più stringhe come .internal, che il Consiglio di amministrazione ha riservato in modo permanente all'uso privato il 29 luglio 2024, su parere dello SSAC. Le stringhe bloccate non possono essere richieste in nessun round. La RFC 8244 (ottobre 2017) osserva che nessun processo formale coordina i due sistemi e che nessuno dei due enti può impedire a terzi di usare semplicemente un nome. ## Come l'ICANN gestisce il rischio di collisione ### Le collisioni di nomi nel round del 2012 In base al quadro approvato il 30 luglio 2014, ogni nuovo registro ha applicato per almeno 90 giorni una controlled interruption (interruzione controllata) continua. La sua zona rispondeva alle query con l'indirizzo 127.0.53.53, che non apre alcuna connessione, e con un record di testo che diceva «Your DNS configuration needs immediate attention». L'NCAP ha poi rilevato poche segnalazioni, e solo una ha richiesto un intervento da parte di un registro. ### Le collisioni di nomi nel Round 2026 Il 7 settembre 2024 il Consiglio di amministrazione ha approvato il quadro Name Collision Risk Management, che sostituisce quello del 2014. 1. **Initial Assessment.** Dopo lo String Confirmation Day, una valutazione supervisionata dal Technical Review Team (TRT) dell'ICANN esamina ogni stringa usando, tra gli altri dati, i log dei server radice e dei resolver. Il rapporto è sottoposto a consultazione pubblica. 2. **Temporary Delegation.** Le stringhe non giudicate ad alto rischio vengono delegate a name server gestiti dall'ICANN per misurare il traffico reale, per almeno 90 e al massimo 365 giorni (a ottobre 2026). La radice cresce al massimo di circa il 5% al mese, all'inizio circa 75 deleghe al mese (a ottobre 2026). La fase contrattuale attende la fine di questo passaggio. 3. **Stringhe ad alto rischio.** A ottobre 2026 finiscono in una Collision String List. Entro 90 giorni da questa designazione (o dalla risoluzione della contesa, se la stringa è in contesa), il richiedente può ritirarsi con il rimborso completo della tariffa di valutazione oppure presentare un Mitigation Plan (fino a 180 giorni su richiesta) le cui misure si completano in non più di due anni. La tariffa per l'esame del piano è stimata tra 100.000 e 150.000 USD. Se il piano non supera l'esame, la domanda decade, salvo contestazione entro 21 giorni. Il rimborso esclude .corp, .home e .mail. Nel marzo 2026, dopo la consultazione pubblica, l'ICANN ha deciso di non usare la controlled interruption su IPv6, la versione 6 del protocollo internet, nel Round 2026. L'ICANN ritiene improbabile che le collisioni colpiscano un numero significativo di reti o di utenti, ma il rischio resta. ## Che cosa dovrebbero fare gli amministratori di rete La guida dell'ICANN per i professionisti IT raccomanda quanto segue: - Considerare 127.0.53.53 in un log come un avviso di collisione. - Usare ovunque nomi a dominio completi (FQDN) e smettere di affidarsi alle liste di ricerca. - Spostare i nomi privati sotto un dominio registrato e monitorare finché i vecchi nomi non sono più usati. - In mancanza di un dominio registrato, usare solo opzioni riservate: .internal, home.arpa per le reti domestiche o .test per i test. - Segnalare una collisione all'ICANN quando c'è il ragionevole convincimento di un danno grave e dimostrabile. Un esempio: i portatili di un'azienda hanno corp.example.com nella lista di ricerca, quindi digitando «intranet» si raggiunge intranet.corp.example.com, un nome controllato dall'azienda. Se l'azienda avesse inventato una propria terminazione, quelle query finirebbero alla radice e, una volta diventata quella stringa un gTLD in controlled interruption, gli utenti otterrebbero invece 127.0.53.53. ## Fonti - [New gTLD Program: 2026 Round Applicant Guidebook, Module 7](https://newgtldprogram-2026-agb.icann.org/en/11-module-7-string-and-application-evaluation-procedures.html) - [Name Collision - ICANN](https://www.icann.org/name-collision) - [Guide to Name Collision Identification and Mitigation for IT Professionals](https://www.icann.org/name-collision/guide-for-it-professionals) - [Special-Use Domain Names (IANA registry)](https://www.iana.org/assignments/special-use-domain-names) ## termini correlati - [Programma dei nuovi gTLD](https://tldlog.com/it/glossario/programma-nuovi-gtld/) - [radice alternativa](https://tldlog.com/it/glossario/radice-alternativa/) - [dominio blockchain](https://tldlog.com/it/glossario/dominio-blockchain/)