Il dominio .lan potrebbe diventare pubblico: cosa rischiano router e reti locali

Una candidatura presentata a ICANN potrebbe trasformare .lan, uno dei suffissi storicamente utilizzati per identificare dispositivi e servizi nelle reti private, in un dominio Internet accessibile globalmente. E cosa accade quando un nome che amministratori di sistema, router e server DNS considerano interno è introdotto nel sistema pubblico dei nomi di dominio? Il rischio riguarda possibili malfunzionamenti, interrogazioni DNS indirizzate all’esterno e comunicazioni che potrebbero raggiungere destinazioni diverse da quelle previste.

ICANN, acronimo di Internet Corporation for Assigned Names and Numbers, è un’organizzazione internazionale senza scopo di lucro che coordina la gestione dei nomi di dominio Internet e degli identificatori univoci della rete, contribuendo a garantire il funzionamento stabile e interoperabile del DNS a livello mondiale.

La candidatura per .lan si inserisce nella nuova tornata di assegnazione dei domini di primo livello (TLD) avviata da ICANN nel 2026, che ha coinvolto centinaia di aziende. Tra i richiedenti figurano Google, con estensioni come .browser, OpenAI, con .openai e .chatgpt, Meta con .facebook e l’italiana Aruba, che ha proposto domini come .pec, .vps, .lab, .roma e .ciao. Tutte le richieste sono ancora soggette alle valutazioni di ICANN e non comportano automaticamente l’assegnazione delle rispettive estensioni.

Perché la registrazione del TLD .lan desta preoccupazione

ICANN ha confermato di aver ricevuto la candidatura per la registrazione del TLD .lan da parte di Coffee Danger, società statunitense. La candidatura risulta attiva, ma si trova ancora nella fase Pre-Evaluation Processing. Non significa, quindi, che il dominio sia approvato, né che possa già essere utilizzato per registrare indirizzi Internet pubblici.

A differenza di altre estensioni proposte per finalità commerciali, .lan è un nome che moltissimi tecnici conoscono e usano da tempo.

Compare nelle configurazioni di reti locali, nei pannelli di amministrazione dei router, nei server DNS interni e nelle procedure utilizzate per raggiungere dispositivi che non dispongono di un dominio Internet registrato.

Un server NAS potrebbe essere identificato, nell’ambito della rete locale, come nas.lan, un router come router.lan, un sistema di videosorveglianza come camera.lan. Sono nomi apparentemente innocui, scelti proprio perché suggeriscono che il relativo servizio sia accessibile soltanto dall’interno della rete.

Il problema è che il suffisso .lan non è mai stato formalmente riservato per questo utilizzo: la sua diffusione nelle infrastrutture private non gli attribuisce automaticamente alcuna protezione nel DNS globale.

Che cosa accadrebbe se .lan entrasse nel DNS pubblico

Immaginiamo una piccola azienda che utilizza l’indirizzo locale gestionale.lan per accedere alla propria applicazione amministrativa, ospitata su un server interno. Il DNS aziendale contiene una regola che associa quel nome all’indirizzo privato del server.

Quando un dipendente apre il browser e digita gestionale.lan nella barra degli indirizzi, il computer interroga il DNS aziendale e raggiunge il servizio corretto: finché tutte le richieste sono gestite dal resolver interno, non emerge alcun conflitto.

La situazione diventa più delicata se, per una ragione qualsiasi, il dispositivo utilizza un resolver che non conosce la zona privata .lan: può succedere quando un portatile viene spostato su una rete esterna, quando una VPN non applica correttamente le regole DNS aziendali oppure quando un dispositivo è configurato per utilizzare un servizio DNS pubblico.

Oggi, in assenza di una delegazione pubblica di .lan, un’interrogazione che raggiunga il DNS globale non può ottenere una risposta autoritativa per quel dominio: lo spieghiamo nell’articolo su che cosa sono i server DNS. Se invece la gestione del TLD .lan fosse assegnata, da parte di ICANN, a un soggetto privato e venisse registrato anche gestionale.lan, il medesimo nome potrebbe avere un significato completamente diverso all’esterno della rete aziendale. Nello specifico, l’utente potrebbe essere indirizzato su un host remoto che non ha nulla a che vedere con il sistema gestionale che si trova in LAN.

Name collision: quando un nome privato entra in conflitto con Internet

ICANN utilizza proprio il termine name collision per descrivere le situazioni nelle quali un nome destinato a essere risolto in un determinato sistema di denominazione è interpretato da un sistema differente. Il fenomeno può provocare comportamenti inattesi, interruzioni delle comunicazioni o collegamenti indirizzati verso destinazioni non previste.

Nel caso di .lan, un dispositivo potrebbe tentare di contattare backup.lan per trasferire dati verso un server interno. Se il resolver DNS utilizzato non conoscesse la corrispondenza privata e il nome fosse risolvibile pubblicamente, la richiesta potrebbe seguire un percorso differente.

Un’applicazione che verifica correttamente il certificato TLS del server può interrompere una connessione HTTPS quando il certificato non corrisponde al nome atteso o non è considerato attendibile. Al contrario, servizi legacy che utilizzano protocolli non cifrati, credenziali trasmesse senza adeguate protezioni o controlli insufficienti sull’identità del server potrebbero essere maggiormente esposti.

Se richieste per indirizzi come nas.lan, backup.lan o vpn.lan escono dalla rete privata, possono rivelare nomi di host, convenzioni aziendali e dettagli relativi ai servizi utilizzati, pur senza esporre direttamente i loro contenuti.

Esiste .internal: il dominio che ICANN ha riservato proprio per le reti private

A luglio 2024, il consiglio direttivo di ICANN ha approvato la riserva permanente di .internal, destinando l’uso di questo TLD alle applicazioni private e impedendone la delegazione nella zona radice del DNS pubblico. L’autorità aveva sottolineato la necessità di identificare un suffisso utilizzabile nelle reti interne senza il rischio di una futura assegnazione pubblica.

ICANN ha insomma già riconosciuto l’esistenza di un problema legato alla name collision e ha scelto di riservare un nome specifico per gli utilizzi privati. La scelta assunta nel caso di .internal, tuttavia, non implica che gli altri suffissi storicamente utilizzati nelle LAN abbiano acquisito una protezione equivalente.