Domini Active Directory .local e .lan: nel 2026 sono un errore, non naming legacy

Vai al TL;DR

Nel 2026 progettare un nuovo dominio Active Directory come:

azienda.local

azienda.lan

o usando un suffisso inventato che non appartiene a un namespace controllato dall’organizzazione è un errore.

Non naming legacy.

Un errore.

Il percorso che ha portato ad abbandonare questo modello è iniziato molti anni fa, ma ignorarlo nel 2026 non è più tollerabile.

Eppure capita ancora di trovare domini.local appena creati. E capita ancora che questa convenzione venga trasmessa ai tecnici più giovani come una normale modalità di progettazione di Active Directory.

Per questo vale ancora la pena parlarne.

Un.local creato vent’anni fa è un’eredità infrastrutturale. Uno creato oggi è una scelta progettuale.

E quando quella scelta viene insegnata, rischia di sopravvivere per un’altra generazione.

Quando .local aveva senso

Torniamo all’epoca di Windows 2000 e Windows Server 2003.

La rete interna e Internet erano mondi molto più separati di oggi.

Active Directory, DNS, file server e applicazioni aziendali vivevano dentro il perimetro. Il sito web e la posta stavano fuori.

Anche il rapporto con i certificati era completamente diverso.

HTTPS non era onnipresente. TLS non faceva parte di ogni servizio e di ogni integrazione. Anche molti servizi pubblici venivano ancora esposti senza la protezione che oggi consideriamo normale.

Internamente, quando serviva un certificato, una CA aziendale poteva risolvere il problema.

In quel mondo aveva senso pensare:

azienda.it

fuori,

azienda.local

dentro.

Due namespace per due mondi considerati distinti.

.local non nasce quindi da incompetenza. Nasce da un’architettura coerente con il proprio tempo.

La selce funziona ancora, ma appartiene a un’altra era tecnologica.

Intorno al 2009 la direzione era già cambiata

Con l’epoca Windows Server 2008 il modello aveva già cominciato a cambiare.

La direzione si sposta verso namespace DNS globalmente univoci e costruiti, dove possibile, sotto domini registrati e controllati dall’organizzazione.

Se l’azienda possiede:

azienda.it

diventa molto più sensato costruire:

ad.azienda.it

invece di:

azienda.local

Non perché.local avesse improvvisamente smesso di funzionare. Continuava a funzionare.

Era cambiato il problema che stavamo cercando di risolvere.

Le infrastrutture aziendali iniziavano a essere meno isolate, aumentavano le integrazioni, l’identità usciva progressivamente dal solo perimetro LAN e il DNS interno non poteva più essere progettato come se Internet fosse un universo completamente separato.

La zona ad.azienda.it può comunque esistere soltanto sui DNS interni. I domain controller possono rimanere completamente irraggiungibili da Internet.

Non stiamo pubblicando Active Directory.

Stiamo semplicemente costruendo il namespace interno sotto un dominio che l’organizzazione controlla realmente.

Microsoft continua ancora oggi a raccomandare namespace DNS registrati o subordinati a namespace registrati nella progettazione di Active Directory.

Anche usare direttamenteazienda.itpuò creare confusione

Poi ho visto anche domini che provavano a seguire questa direzione, ma in modo un po’ ingenuo: usavano direttamente il dominio di secondo livello come zona AD, senza dedicargli un terzo livello.

azienda.it fuori e azienda.it dentro.

Poi chiamavi azienda.it dalla rete interna aspettandoti il sito pubblico e ti rispondevano i domain controller.

Con ad.azienda.it il confine rimane molto più leggibile.

Il dominio pubblico continua a fare il dominio pubblico. Il namespace Active Directory ha il proprio spazio.

2013:.local smette anche di essere neutro

Nel 2013 RFC 6762 formalizza Multicast DNS e assegna a.local un significato specifico nell’ambito mDNS.

Da quel momento.local non è più neppure un suffisso che possiamo considerare semplicemente “nostro perché interno”.

Ha già un significato tecnico preciso.

Questo rende.local particolarmente poco adatto a un nuovo dominio Active Directory.

Cambiare.local con.lan, però, non risolve il problema progettuale.

azienda.lan

azienda.private

azienda.corp

possono evitare la collisione specifica con mDNS, ma rimangono namespace inventati localmente.

Se possediamo giàazienda.it, la domanda diventa molto semplice: quale vantaggio concreto otteniamo inventando un altro spazio dei nomi?

2015: arriva la ghigliottina

Poi arriva un passaggio molto concreto.

Le Certification Authority pubblicamente trusted stavano eliminando progressivamente i cosiddetti Internal Names.

Dall’11 novembre 2015 non è più consentita l’emissione di normali certificati pubblicamente trusted per nomi interni come:

server.azienda.local

Una CA privata può continuare tranquillamente a certificarlo.

Una CA pubblicamente trusted no.

Con:

server.ad.azienda.it

quella possibilità rimane.

Questo non significa che ogni server interno debba avere un certificato pubblico.

Significa che il naming non ha già preso quella decisione al posto nostro.

Ed è qui che la differenza tra un namespace controllato e uno inventato diventa immediatamente visibile.

LDAPS come cartina al tornasole

Prendiamo un caso molto concreto.

Abbiamo un firewall che autentica gli amministratori attraverso Active Directory.

Il tecnico accede alla sua interfaccia con un account di dominio e il firewall interroga un domain controller tramite LDAPS.

Il firewall deve poter verificare l’identità del server LDAP attraverso il certificato che gli viene presentato.

Se il domain controller si chiama:

dc01.azienda.local

la strada passa necessariamente da una PKI privata per quel nome.

È una soluzione tecnicamente valida.

Ma quella fiducia dobbiamo costruirla e mantenerla noi.

La root della CA deve essere presente sul firewall. Dobbiamo assicurarci che l’apparato continui a fidarsi della catena, gestire il certificato e verificare cosa supporta quel particolare prodotto.

Poi magari arriva un secondo firewall.

Poi un NAS.

Poi un hypervisor.

Poi un’applicazione Linux.

Poi un altro apparato che deve parlare con Active Directory.

Una PKI privata può gestire tutto questo, e in molti ambienti è esattamente la scelta corretta.

Il punto è un altro.

Con:

dc01.ad.azienda.it

possiamo decidere caso per caso quale modello di trust utilizzare.

Con:

dc01.azienda.local

per quel nome una delle possibilità è stata esclusa quando abbiamo creato il dominio.

Il certificato diventa quindi una cartina al tornasole molto efficace: mostra oggi un vincolo che il giorno dell’installazione di Active Directory poteva sembrare inesistente.

“Ma tanto è tutto interno”

È una frase che ricorre spesso.

Ma interno non significa implicitamente trusted.

Un firewall, un NAS, un hypervisor, un’applicazione Linux o un browser non si fidano della nostra CA privata perché si trovano nella stessa LAN.

Devono conoscere la catena di fiducia.

Possiamo distribuirla. Possiamo amministrarla. Possiamo farlo benissimo.

Ma è una responsabilità operativa reale.

Se la PKI privata è una scelta deliberata dell’architettura, perfetto.

Se siamo obbligati a usarla semplicemente perché anni prima abbiamo scelto un nome che non può essere certificato pubblicamente, è un’altra cosa.

Il problema nasce quando dobbiamo cambiare il modello di trust ma una configurazione ce lo impedisce.

2024: arriva.internal, ma non è la nuova best practice Active Directory

Nel 2024 ICANN ha riservato.internal per applicazioni private.

È una novità importante, ma è facile leggerla nel modo sbagliato.

Non significa che:

azienda.internal

sia diventato il nuovo equivalente raccomandato diazienda.local per Active Directory.

Lo scopo è diverso.

.internal serve a identificare namespace che nascono deliberatamente privati e che non devono essere delegati nella root DNS pubblica.

In pratica è quasi un’etichetta incorporata nel nome:

questo namespace nasce privato e deve rimanere privato.

Ed è utile quando è esattamente ciò che vogliamo.

Per Active Directory, però, la domanda resta diversa.

Se l’azienda possiede:

azienda.it

e dobbiamo scegliere tra:

azienda.internal

e:

ad.azienda.it

con il secondo possiamo comunque mantenere tutto il DNS Active Directory esclusivamente interno.

Non dobbiamo pubblicare i domain controller. Non dobbiamo rendere raggiungibile Active Directory da Internet. Non dobbiamo nemmeno utilizzare certificati pubblici.

Abbiamo però un namespace che discende da qualcosa che possediamo e quindi possiamo dimostrarlo. E che non impone fin dall’inizio di rimanere confinato nel mondo privato.

.internal, quindi, non va messo nello stesso gruppo di.lan.

Ha uno scopo legittimo e standardizzato.

Ma non è una nuova best practice Microsoft per sostituire.local nei domini Active Directory.

È un modo corretto per identificare namespace destinati a rimanere privati. Sono due problemi diversi.

Il debito tecnico può rimanere silenzioso per anni

Questa è probabilmente una delle ragioni per cui.local è sopravvissuto così a lungo.

Funziona.

Kerberos funziona.

Le Group Policy funzionano.

DNS funziona.

Gli utenti fanno login.

Le share si aprono.

E quindi il naming sembra innocuo.

Passano cinque anni.

Poi dieci.

Nel frattempo quel namespace entra negli SPN, negli script, nelle configurazioni LDAP, nei certificati, nei gestionali, nelle appliance e nelle integrazioni con altri sistemi.

Poi arriva un requisito nuovo.

A quel punto scopriamo che una scelta che costava praticamente zero all’inizio è diventata costosa da cambiare.

Il requisito può essere nuovo.

Il debito no.

Un dominio Active Directory vive molto più a lungo della procedura che lo crea

La promozione del primo domain controller richiede poco tempo.

Il dominio che nasce da quella procedura può rimanere in produzione per quindici o vent’anni.

Questo dovrebbe cambiare il modo in cui valutiamo il naming.

Non dobbiamo chiederci soltanto:

“Funziona oggi?”

Dobbiamo anche chiederci:

“Sto introducendo oggi un limite che potrei evitare senza alcun costo significativo?”

Se possiedo:

azienda.it

scegliere:

ad.azienda.it

non richiede una tecnologia più sofisticata di:

azienda.local

Non espone Active Directory su Internet.

Non obbliga a usare certificati pubblici.

Non impedisce di usare una CA privata.

Non aggiunge complessità significativa.

Semplicemente lascia aperte più possibilità.

Una buona architettura non deve prevedere il futuro. Deve evitare di ostacolarlo senza motivo.

Quanto tempo è passato?

Vale la pena metterlo in prospettiva.

La cultura di.local appartiene soprattutto all’epoca Windows 2000 e Windows Server 2003.

Intorno al 2009 la direzione progettuale era già cambiata.

Poi sono arrivati:

Windows Server 2008 → 2008 R2 → 2012 → 2012 R2 → 2016 → 2019 → 2022 → 2025

Otto generazioni.

Nel 2013.local assume un significato specifico in mDNS.

Nel 2015 si chiude definitivamente la strada degli Internal Names nei certificati pubblicamente trusted.

Nel 2024 viene riservato.internal, questa volta proprio per namespace che devono essere esplicitamente e deliberatamente privati.

E siamo nel 2026.

Non stiamo parlando di una best practice comparsa sei mesi fa.

Trovare oggi un dominio.localè vintage. Crearne uno nuovo è anacronistico.

Un.local del 2003 può essere storia dell’infrastruttura.

Un.localcreato nel 2026 è debito tecnico appena comprato.

“Abbiamo sempre fatto così”

Qui arriviamo alla parte meno tecnica, ma forse quella che vale la pena guardare più da vicino.

Se nel 2026 si crea ancora un nuovo.local perché “abbiamo sempre fatto così”, non si tratta di una best practice pubblicata sei mesi fa che è sfuggita a qualcuno. Sono passati più di dieci anni persino dalla chiusura degli Internal Names nei certificati pubblicamente trusted.

Questo non dice nulla sulla competenza di chi lo fa. Dice qualcosa sul modo in cui, come settore, trasmettiamo le pratiche da una generazione di tecnici all’altra.

Una convenzione può sopravvivere molto più a lungo della sua validità, semplicemente perché nessuno si ferma a chiederle conto.

La prudenza verso l’innovazione fa parte del mestiere: nessuno deve rincorrere ogni novità. Ma c’è una differenza tra valutare con cautela un cambiamento e non accorgersi che quel cambiamento è già maturo da un decennio.

E c’è una differenza ulteriore, forse la più importante, tra sbagliare per sé stessi e insegnare l’errore a chi si sta ancora formando.

Un dominio.local creato oggi da un tecnico esperto è già un debito tecnico evitabile.

Lo stesso dominio creato oggi e insegnato a un junior come procedura corretta è qualcosa di diverso: non un errore isolato, ma una pratica che viene trasmessa proprio nel momento in cui qualcuno sta costruendo il proprio modello mentale di cosa sia “giusto” fare.

Chi impara oggi da noi molto probabilmente ripeterà la stessa scelta tra cinque o dieci anni, in perfetta buona fede, su un altro dominio, per un’altra azienda.

Continuare nel 2026 a progettare con una convenzione dell’epoca Windows Server 2003 non è necessariamente inesperienza individuale.

È più spesso il segno che quella pratica si è tramandata senza che nessuno, lungo la catena, si sia fermato a verificarla.

Ma è anche per questo che vale la pena fermarsi adesso:

perché ogni volta che insegniamo qualcosa a chi sta imparando il mestiere, decidiamo — senza nemmeno accorgercene — per quanto ancora quella pratica sopravviverà.

Riferimenti

• Microsoft Learn — Active Directory Domain Services deployment and DNS naming guidance
• RFC 6762 — Multicast DNS (.local)
• CA/Browser Forum — Internal Names deprecation and publicly trusted certificates
• ICANN — Reservation of .internal for private-use applications (2024)