• Guide, Sistemi Operativi
• 1 Aprile 2026

Durante una migrazione di server o workstation capita spesso di dover mantenere attivo sia il vecchio hostname sia il nuovo nome del computer. Questo approccio consente di evitare interruzioni dei servizi mentre si aggiornano gradualmente script, mapping e configurazioni applicative. In pratica, il sistema deve rispondere a due nomi contemporaneamente, riducendo il rischio di downtime.

Il concetto è semplice: Windows può gestire nomi DNS alternativi associati allo stesso computer. Una delle modalità più corrette consiste nell’aggiungere un alias DNS o un nome alternativo gestito dal sistema, evitando soluzioni improvvisate che potrebbero causare problemi di autenticazione o risoluzione dei nomi.

Aggiungere un secondo nome ad un server tramite record CNAME

Quando dovete gestire una migrazione di server o spostare un servizio su una nuova macchina, una soluzione rapida consiste nel creare un nome alternativo utilizzando un record CNAME nel DNS. In questo modo il server continuerà a rispondere sia al vecchio nome sia al nuovo hostname.

Per creare un alias DNS (CNAME) aprite la console DNS Manager e posizionatevi nella Forward Lookup Zone del dominio. Fate clic con il tasto destro sulla zona e scegliete New Alias (CNAME).

Nel campo Alias name inserite il nome alternativo che volete assegnare. Nel campo Fully qualified domain name (FQDN) for target host indicate invece il server reale a cui l’alias deve puntare.

Confermate con OK per creare il record. Da questo momento il nuovo nome verrà risolto automaticamente verso il server specificato.

Da questo momento qualsiasi richiesta verso ROME-FS01.adatum.com verrà risolta automaticamente verso LON-SVR8.adatum.com con IP 172.16.0.28. Per i client di rete il servizio continuerà quindi a funzionare senza modificare configurazioni o script esistenti.

Questo approccio è particolarmente utile durante le migrazioni graduali, perché vi consente di mantenere attivo il nome storico del server mentre aggiornate progressivamente i riferimenti al nuovo hostname.

Figura 1: Configurazione di un record CNAME in DNS Manager per assegnare al server LON-SVR8 il nome alternativo ROME-FS01

Figura 2: Verifica del record CNAME ROME-FS01 che punta al server LON-SVR8 nella zona DNS adatum.com

Dopo aver configurato il record CNAME nel DNS, dovete verificare che il nuovo nome alternativo sia correttamente risolto anche dai client del dominio. Questa operazione consente di confermare che la migrazione può procedere senza problemi di risoluzione DNS.

Collegatevi ad una macchine del dominio e avviate quindi il test digitando il comando:

Il risultato mostra che la richiesta verso ROME-FS01.adatum.com viene risolta dal DNS e restituisce come nome reale LON-SVR8.adatum.com. Nella risposta compare infatti il campo Name con il server effettivo e il relativo indirizzo IP 172.16.0.28.

È particolarmente importante notare la presenza della voce Aliases, che riporta ROME-FS01.adatum.com. Questo conferma che il nome utilizzato dal client è un alias DNS e che il sistema lo sta correttamente associando al server di destinazione.

Questa verifica dimostra che il secondo nome del computer è operativo e che i client del dominio possono già utilizzare il nuovo alias senza modifiche ulteriori. A questo punto potete testare l’accesso ai servizi, ad esempio con condivisioni SMB o applicazioni che utilizzano il vecchio hostname.

Figura 3: Verifica da un client del dominio della risoluzione DNS dell’alias ROME-FS01 verso il server LON-SVR8 tramite nslookup

Che tipo di problemi posso avere con questa modalità?

Utilizzare un nome alternativo tramite record CNAME è molto comodo durante le migrazioni, ma dovete considerare alcune limitazioni tecniche che possono generare problemi operativi. Non sempre infatti questa modalità è trasparente per tutti i servizi Windows.

Il primo aspetto riguarda Kerberos e l’autenticazione. Quando accedete ad un server utilizzando un alias DNS, il ticket Kerberos potrebbe non corrispondere al Service Principal Name (SPN) registrato in Active Directory. In questi casi l’autenticazione può fallire oppure Windows effettua un fallback su NTLM, con possibili problemi di sicurezza o di compatibilità. Questo comportamento è tipico con file server, IIS o servizi che utilizzano autenticazione integrata.

Un’altra criticità frequente riguarda le condivisioni SMB. Se accedete ad uno stesso server sia con il nome reale sia con l’alias, Windows può considerare le connessioni come separate. Questo può causare errori come accessi negati, mapping duplicati oppure problemi con le credenziali memorizzate. In scenari con script di login o drive mapping automatici, questo effetto è abbastanza comune.

Dovete poi considerare i possibili problemi con applicazioni legacy. Alcuni software salvano il nome del server nelle configurazioni o nei database. Utilizzando un CNAME, l’applicazione potrebbe rilevare il nome reale della macchina e generare incongruenze, soprattutto nei servizi che validano l’hostname.

Un ulteriore aspetto riguarda i servizi clusterizzati o altamente disponibili. In questi casi l’uso di un semplice alias DNS non è sempre supportato. Alcuni ruoli Windows, come SQL Server o DFS, richiedono un nome di rete registrato correttamente in Active Directory e non funzionano in modo affidabile con un CNAME.

Potete inoltre incontrare problemi con la gestione dei certificati SSL. Se il server espone servizi HTTPS e utilizzate un alias DNS, il certificato deve includere anche il nome alternativo. In caso contrario otterrete errori di mismatch del certificato.

C’è anche il tema della registrazione dinamica DNS. Il record CNAME non viene aggiornato automaticamente dal server di destinazione. Se cambiate l’IP o spostate nuovamente il servizio, dovrete aggiornare manualmente la configurazione per evitare inconsistenze.

Di fatto, questa modalità è ideale per migrazioni temporanee, ma non sempre adatta come soluzione definitiva. Se prevedete un utilizzo prolungato, conviene valutare l’aggiunta degli SPN corretti oppure utilizzare metodi più strutturati come il rename del computer o un nome virtuale gestito.

Aggiungere un secondo nome al computer con Netdom

Quando volete evitare le limitazioni dei record CNAME, potete aggiungere direttamente un nome alternativo al computer utilizzando netdom. Questa modalità è più pulita perché il sistema registra il secondo nome anche in Active Directory, riducendo i problemi con Kerberos, SMB e servizi Windows.

In questo scenario il computer mantiene il nome principale, ma viene configurato per rispondere anche ad un hostname aggiuntivo. Dal punto di vista dei client, entrambi i nomi risultano validi e l’autenticazione funziona correttamente.

Per prima cosa aprite un Prompt dei comandi con privilegi amministrativi direttamente sul server oppure da una postazione con gli strumenti RSAT. A questo punto aggiungete il nome alternativo utilizzando il comando netdom.

Eseguite il comando indicando il nome attuale del computer e il nuovo hostname:

nel mio esempio sarà

Con questa operazione state registrando ROME-FS01 come nome secondario del server LON-SVR8.adatum.com. Il sistema aggiorna automaticamente Active Directory e i metadati necessari per l’autenticazione.

NOTA: Quando aggiungete un nome ad una macchina in dominio, è consigliabile utilizzare sempre il FQDN completo nei comandi netdom (ad esempio LON-DC3.adatum.com) invece del solo nome NetBIOS. L’uso dell’FQDN riduce il rischio di inconsistenze nei record DNS, negli SPN e nei metadati di Active Directory, soprattutto in ambienti con più siti o servizi che dipendono dalla risoluzione DNS.

Potete verificare la configurazione elencando i nomi associati al computer:

Nel mio caso il comandi sarà:

Se l’operazione è andata a buon fine vedrete il nome primario e il nome alternativo appena aggiunto. Da questo momento potete utilizzare entrambi gli hostname durante la migrazione.

Questa soluzione è particolarmente indicata quando dovete gestire la sostituzione di file server, migrazioni di applicazioni o cambi di naming mantenendo la piena compatibilità con l’infrastruttura Active Directory.

Figura 4:Aggiunta e verifica di un nome alternativo ROME-FS01 al server LON-SVR8 tramite il comando netdom

Registrare il nome alternativo nel DNS

Dopo aver aggiunto il secondo nome al computer con netdom, dovete assicurarvi che il server registri correttamente il nuovo hostname nel DNS. Questo passaggio è importante perché consente ai client del dominio di risolvere immediatamente il nome alternativo.

Eseguite il comando:

Con questa operazione forzate il computer a registrare nuovamente tutti i record DNS associati alle interfacce di rete. Windows avvia quindi la registrazione dinamica sia per il nome principale sia per il nome alternativo appena configurato.

Il messaggio restituito indica che la registrazione dei record DNS è stata avviata e che eventuali errori verranno riportati nel Visualizzatore eventi. Questo comportamento è normale: la registrazione avviene in modo asincrono e può richiedere qualche minuto.

Dopo questo passaggio il server sarà raggiungibile tramite entrambi gli hostname, senza dover creare manualmente record DNS o alias. È comunque buona pratica verificare la risoluzione dal DNS o da un client del dominio per confermare che il nuovo nome sia operativo.

Figura 5: Forzatura della registrazione DNS del nome alternativo tramite il comando ipconfig /registerdns

Verificare la registrazione del nome alternativo nel DNS

Dopo aver aggiunto il nome alternativo con netdom e aver forzato la registrazione con ipconfig /registerdns, potete verificare che il nuovo hostname sia stato pubblicato correttamente nel DNS.

Nella lista dei record compare ora la voce ROME-FS01 con tipo Host (A) e indirizzo IP 172.16.0.28.

Questo è un dettaglio importante: a differenza della modalità con CNAME, il nome alternativo viene registrato come record A reale. Significa che il DNS associa direttamente il nuovo hostname all’indirizzo IP del server, garantendo piena compatibilità con Kerberos, SMB e servizi Active Directory.

La presenza del record ROME-FS01 conferma quindi che il server LON-SVR8 è raggiungibile anche tramite il nuovo nome. I client del dominio potranno utilizzare indifferentemente LON-SVR8.adatum.com oppure ROME-FS01.adatum.com senza differenze operative.

Figura 6: Verifica nel DNS della registrazione del nome alternativo ROME-FS01 come record Host (A) associato all’IP del server LON-SVR8

Dopo aver confermato la presenza del record Host (A) nel DNS, potete eseguire un’ulteriore verifica direttamente da un client del dominio. Questo passaggio serve a controllare che il nuovo nome alternativo sia effettivamente risolvibile anche dalle workstation.

Eseguite quindi il comando:

Nel mio caso:

Il risultato mostra che il DNS risponde correttamente restituendo il nome richiesto e l’indirizzo IP 172.16.0.28. A differenza della modalità con CNAME, non compare alcun alias: il nome ROME-FS01 è ora registrato come record A diretto, quindi viene risolto immediatamente all’indirizzo del server.

Questo conferma che il server è raggiungibile con il nome alternativo anche dai client del dominio. Potete quindi utilizzare il nuovo hostname per accedere ai servizi, alle condivisioni o alle applicazioni senza differenze rispetto al nome originale.

Figura 7: Verifica da un client del dominio della risoluzione del nome alternativo ROME-FS01 registrato come record Host (A)

C’è un limite nel numero di nomi alternativi?

Esiste un limite, ma nella pratica è più teorico che reale. Quando aggiungete nomi alternativi con netdom, Windows non impone un numero fisso documentato e rigido, tuttavia ci sono vincoli tecnici che rendono sconsigliato aggiungerne troppi.

Il primo limite riguarda Active Directory e gli SPN. Ogni nome alternativo genera registrazioni aggiuntive e aumenta il numero di Service Principal Name associati al computer. Un numero elevato può complicare la gestione dell’autenticazione Kerberos e aumentare il rischio di conflitti.

Un altro aspetto è la dimensione degli attributi dell’oggetto computer in Active Directory. I nomi alternativi vengono salvati negli attributi del computer e, anche se il limite è piuttosto alto, non è pensato per decine o centinaia di hostname. Oltre una certa soglia potreste incontrare problemi di replica o di aggiornamento. Il limite dipende principalmente dall’attributo msDS-AdditionalDnsHostName dell’oggetto computer in Active Directory, dove vengono memorizzati i nomi alternativi aggiunti con netdom.

Questo attributo è multi-valore e ogni valore può avere una lunghezza massima di circa 255 caratteri (FQDN completo). Il vincolo reale però è dato dalla dimensione massima complessiva degli attributi non collegati in un oggetto AD, che è circa 1 MB.

Dovete poi considerare la gestione operativa. Più nomi alternativi aggiungete, più diventa complesso capire quale hostname sia effettivamente utilizzato da applicazioni, script e utenti. Questo aumenta il rischio di configurazioni incoerenti durante le migrazioni.

È da considerare anche l’impatto sulla registrazione DNS. Ogni nome alternativo genera un record A aggiuntivo. Un numero elevato non crea problemi immediati, ma rende più difficile la manutenzione e il troubleshooting.

Perciò, direi che se tecnicamente potete aggiungere diversi nomi alternativi, la raccomandazione è di limitarvi a pochi alias temporanei (tipicamente 2-5) e rimuoverli una volta completata la migrazione.

Conclusioni

L’aggiunta di un secondo nome ad un computer è una tecnica molto utile durante le migrazioni perché vi consente di mantenere attivi i riferimenti esistenti mentre aggiornate gradualmente servizi e configurazioni. In questo modo potete ridurre il rischio di interruzioni e gestire la transizione in modo controllato.

L’utilizzo di un record CNAME rappresenta la soluzione più veloce, ma può introdurre problemi di autenticazione e incompatibilità con alcuni servizi Windows. Per questo motivo è preferibile adottare la modalità con netdom, che registra il nome alternativo direttamente in Active Directory e garantisce maggiore compatibilità con Kerberos, SMB e applicazioni enterprise.

Ricordate però che i nomi alternativi devono essere temporanei. Anche se non esiste un limite rigido, è buona pratica mantenerne pochi e rimuoverli una volta completata la migrazione, per evitare complessità nella gestione e nel troubleshooting.