La scelta del suffisso DNS per Active Directory e per i namespace privati non è più un dettaglio secondario. Nelle installazioni storiche sono comparsi spesso .local, .lan, .corp e .home, ma oggi standard, vendor e organismi di governance del DNS spingono verso scelte più rigorose e meno esposte a collisioni.
Per anni molte reti hanno continuato a funzionare anche con suffissi “inventati”, ma il fatto che una configurazione funzioni non significa che sia una buona base architetturale. Il punto centrale è capire quali nomi sono davvero riservati, quali sono solo convenzioni diffuse e quali invece restano la scelta migliore per un ambiente enterprise moderno.
Perché evitare .local
Il problema di .local è che non è un suffisso neutro: è associato al multicast DNS, usato per il service discovery locale da sistemi Apple, dispositivi IoT, stampanti e vari software di rete. In un ambiente Active Directory questo può introdurre ambiguità nella risoluzione nomi e comportamenti incoerenti tra client, appliance e servizi.
Il tema non è solo teorico. Microsoft continua a raccomandare di evitare domini non instradabili o namespace poco standardizzati nelle nuove implementazioni, anche perché in scenari ibridi o di sincronizzazione identità i suffissi non routable possono creare UPN poco coerenti o conversioni indesiderate verso domini di servizio come onmicrosoft.com.
La novità più importante: .internal
La svolta è arrivata nel 2024, quando ICANN ha riservato .internal come top-level label per private-use DNS namespaces, cioè per namespace interni che non fanno parte del DNS pubblico globale. In pratica, .internal è stato pensato come equivalente DNS del concetto già noto negli indirizzi IP privati definiti da RFC 1918.
Questo passaggio è importante perché introduce finalmente una scelta formalizzata per gli ambienti chiusi. Dove prima si ricorreva a suffissi come .corp o .lan per abitudine, oggi esiste un’opzione espressamente dedicata a questo scenario e protetta dalla delega nel root pubblico.
I suffissi davvero riservati
Non tutti i suffissi usati in ambito interno hanno lo stesso valore tecnico. Alcuni esistono in virtù di RFC precise, altri derivano da decisioni ICANN, mentre altri ancora sono soltanto pratiche diffuse senza tutele formali.
Qui vale la pena chiarire un equivoco frequente: .home e .home.arpa non sono la stessa cosa. RFC 8375 ha introdotto home.arpa proprio per sostituire l’uso non controllato di .home, che produceva query in uscita e possibili collisioni.
Pseudo-domini storici e speciali
Prima di .internal, esistevano pseudo-TLD per reti non-Internet: – .bitnet, .csnet, .uucp: Reti accademiche anni ’80 (gateway su Internet) – .onion: Tor (overlay network, DNS speciale)
Differenza chiave:
Non sono TLD DNS root, ma namespace alternativi con resolver dedicati. `.internal` invece è un vero TLD riservato ICANN per reti DNS standard
I suffissi “comodi” che però non sono standard
In diversi articoli, forum o documentazioni di prodotto si trovano suggerimenti come .lan, .private, .corp, .home, .network, .intranet o .site. Possono funzionare in una rete isolata, ma non risultano riservati ufficialmente come namespace privati nel DNS globale.
Questo significa che il loro uso resta una convenzione locale, non una scelta garantita dagli standard. In altre parole: possono essere pratici nel breve periodo, ma non offrono la stessa sicurezza concettuale e normativa di .internal, né la specializzazione di home.arpa per il mondo domestico.
Cosa raccomanda Microsoft per Active Directory
La best practice Microsoft resta piuttosto stabile: quando possibile, conviene usare un sottodominio di un dominio registrato e controllato, ad esempio corp.tuodominio.com oppure ad.tuodominio.com. Questa soluzione semplifica naming, UPN, certificati, federazione e integrazione futura con servizi cloud o identità ibride.
Detto questo, non tutte le organizzazioni vogliono o possono registrare un dominio pubblico per un ambiente completamente isolato. In quel caso .internal è oggi l’alternativa più solida, proprio perché è l’unico suffisso private-use esplicitamente riservato a livello ICANN per namespace DNS non pubblici.
Una scelta pratica, senza estremismi
Per chi deve decidere oggi, la gerarchia può essere molto semplice.
- Se esiste un dominio registrato, la scelta più robusta resta un sottodominio dedicato, ad esempio
corp.example.com. - Se l’ambiente è enterprise, chiuso e senza registrazione pubblica,
.internalè la soluzione più coerente con l’evoluzione degli standard. - Se il contesto è domestico o di laboratorio,
home.arpaè corretto e definito da RFC 8375. - Se il suffisso in valutazione è
.local,.lan,.corpo simili, conviene fermarsi un attimo e chiedersi se si stia scegliendo una scorciatoia o una base tecnica destinata a durare.
Conclusione operativa
La risposta breve è semplice: per Active Directory enterprise la scelta migliore resta un sottodominio di un dominio registrato; se però serve un namespace realmente privato e non registrato, .internal è oggi la prima opzione tecnicamente difendibile. È qui che si vede la differenza tra una convenzione storica e uno standard finalmente riconosciuto.
Per questo motivo .internal è molto più di una moda recente: è il primo tentativo serio di portare ordine in un’area in cui per anni hanno dominato abitudini locali, workaround e pseudo-standard. E per un ambiente chiuso, questa è probabilmente la novità più importante degli ultimi anni.
Riferimenti essenziali
- Microsoft, Best Practices for Active Directory Domains — https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/deployment-operation-ad-domains
- ICANN, Proposed Top-Level Domain String for Private Use — https://www.icann.org/ar/public-comment/proceeding/proposed-top-level-domain-string-for-private-use-24-01-2024
- RFC 8375, Special-Use Domain ‘home.arpa.’ — https://datatracker.ietf.org/doc/html/rfc8375
- RFC 2606, Reserved Top Level DNS Names — https://www.rfc-editor.org/rfc/rfc2606.html
- ICANNWiki .interal – .internal – ICANNWiki