• Guide, Sistemi Operativi
• 10 Agosto 2026

Quando durante i miei corsi parlo di Active Directory, c’è un concetto sul quale insisto sempre: se il DNS non è configurato correttamente, prima o poi avremo dei problemi.

Anzi, posso dirvi che nella mia esperienza sul campo, quando vengo chiamato da un cliente per analizzare problemi legati ad Active Directory, nel 90% dei casi trovo anche una configurazione DNS errata o comunque non ottimale.

E spesso il problema nasce da configurazioni apparentemente innocue.

Un DNS pubblico configurato direttamente su un Domain Controller, un client che utilizza il DNS del router, vecchi record rimasti nelle zone, Domain Controller che puntano ai DNS sbagliati. Sono tutte situazioni che ho incontrato più volte e che possono produrre problemi difficili da diagnosticare.

Il motivo è abbastanza semplice: Active Directory dipende dal DNS.

Quando un computer deve autenticarsi al dominio, applicare le Group Policy o semplicemente trovare un Domain Controller, non ha già un elenco magico dei server da contattare. Deve prima capire dove si trovano i servizi di Active Directory.

Il laboratorio che utilizzeremo

Per spiegare il funzionamento del DNS costruiremo progressivamente una piccola infrastruttura Active Directory. Partiremo da un solo Domain Controller e aggiungeremo nuovi componenti man mano che ci serviranno per introdurre i diversi concetti.

Il dominio principale sarà virtual.lab, dominio radice della foresta, con quattro Domain Controller distribuiti tra i Site Roma e Milano. Roma utilizzerà la subnet 10.10.10.0/24, mentre Milano utilizzerà 172.16.0.0/24.

Successivamente aggiungeremo il dominio figlio sviluppo.virtual.lab, che utilizzerà la rete 192.168.10.0/24.

Figura 1: Infrastruttura Active Directory utilizzata nel laboratorio. Il dominio virtual.lab è distribuito tra i Site Roma e Milano; sviluppo.virtual.lab rappresenta il dominio figlio della stessa foresta.

Questa infrastruttura ci permetterà di vedere come cambia il DNS passando da uno a più Domain Controller, cosa succede quando Active Directory viene distribuita tra più Site e, infine, come funzionano un dominio figlio e le deleghe DNS.

Non costruiremo tutto subito. Partiremo da RM-DC1 e arriveremo alla configurazione mostrata nella figura un passaggio alla volta.

Ed è proprio qui che entra in gioco il DNS.

Partiamo dalla configurazione più semplice

Per capire come Active Directory utilizza il DNS conviene partire da un’infrastruttura molto semplice.

Nel mio laboratorio ho inizialmente un solo dominio, chiamato virtual.lab, e un solo Domain Controller, RM-DC1, che ha indirizzo IP 10.10.10.10.

Durante la creazione della foresta ho installato sul Domain Controller anche il ruolo DNS Server. Aprendo DNS Manager possiamo già vedere diverse cose interessanti.

Nella figura seguente possiamo vedere le due zone virtual.lab e _msdcs.virtual.lab. All’interno della zona virtual.lab è presente anche il record Host (A) di rm-dc1, che associa il nome del server all’indirizzo IP 10.10.10.10.

Notiamo però anche diverse cartelle con nomi come _msdcs, _sites, _tcp e _udp.

Queste cartelle contengono alcuni dei record utilizzati da Active Directory per individuare i servizi del dominio. Non li abbiamo creati manualmente: vengono registrati automaticamente durante la configurazione di Active Directory.

Figura 2: La zona DNS virtual.lab dopo l’installazione del primo Domain Controller

Un normale record A permette di rispondere a una domanda molto semplice: qual è l’indirizzo IP di rm-dc1.virtual.lab?

Active Directory deve però rispondere anche a domande diverse. Ad esempio: quali sono i Domain Controller del dominio virtual.lab?

Per farlo utilizza soprattutto i record SRV (Service Record).

Un record SRV non associa semplicemente un nome a un indirizzo IP, ma permette di indicare quale server offre un determinato servizio.

Nel nostro caso abbiamo un solo Domain Controller, quindi la situazione è particolarmente semplice. Se chiediamo al DNS quali server offrono il servizio LDAP come Domain Controller di virtual.lab, la risposta non potrà che essere RM-DC1.

Possiamo verificarlo direttamente dal prompt dei comandi:

la query restituisce proprio rm-dc1.virtual.lab

Figura 3: Interrogazione del record SRV utilizzato per individuare i Domain Controller del dominio virtual.lab

Questo semplice test ci permette di iniziare a capire il rapporto tra DNS e Active Directory: un client utilizza il DNS non solo per risolvere i nomi, ma anche per trovare i servizi necessari al funzionamento del dominio.

Aggiungiamo un secondo Domain Controller

Una configurazione con un solo Domain Controller può andare bene per un laboratorio, ma difficilmente è una buona scelta in produzione. Aggiungiamo quindi RM-DC2 al dominio virtual.lab.

Anche RM-DC2 ospita il servizio DNS e, terminata la promozione a Domain Controller, inizierà a pubblicare nel DNS i record necessari per permettere agli altri computer del dominio di individuarlo.

Ed è qui che possiamo osservare un aspetto molto importante del funzionamento del DNS in Active Directory: non dobbiamo creare manualmente questi record.

I Domain Controller registrano dinamicamente nel DNS i record necessari al funzionamento di Active Directory.

Se ripetiamo la query utilizzata in precedenza:

adesso il DNS può indicarci entrambi i Domain Controller.

Nella figura seguente possiamo vedere che lo stesso record SRV che in precedenza ci indicava solamente RM-DC1 contiene ora anche RM-DC2.

Figura 4: Dopo l’aggiunta di RM-DC2, la query DNS restituisce entrambi i Domain Controller del dominio virtual.lab

Questo è un passaggio importante. I client non sono configurati per utilizzare RM-DC1 oppure RM-DC2 come Domain Controller. Utilizzano il DNS per scoprire quali Domain Controller sono disponibili.

Naturalmente il processo utilizzato da Windows è più articolato e prende il nome di DC Locator, ma il concetto fondamentale che ci interessa in questo momento è semplice:

Active Directory pubblica i propri servizi nel DNS e i client interrogano il DNS per trovarli.

Questo spiega anche perché una configurazione DNS errata può avere conseguenze così importanti. Un computer può comunicare perfettamente con la rete e navigare su Internet, ma se interroga un server DNS che non conosce i record di Active Directory, non sarà in grado di trovare correttamente i servizi del dominio.

Quale DNS devono utilizzare i computer del dominio?

A questo punto dovrebbe essere più semplice capire una delle regole più importanti quando configuriamo Active Directory: i computer del dominio devono utilizzare un DNS in grado di risolvere la zona di Active Directory.

Sembra una considerazione banale, ma vi assicuro che è una delle configurazioni errate che incontro più frequentemente.

Su un client del dominio trovo ad esempio configurato come DNS il router, il firewall oppure un DNS pubblico come 8.8.8.8 o 1.1.1.1.

Il problema è che questi server possono risolvere perfettamente www.microsoft.com, ma non conoscono il dominio virtual.lab e soprattutto non conoscono i suoi record SRV.

Il computer può quindi navigare tranquillamente su Internet e apparentemente la rete funziona, ma quando deve trovare un Domain Controller iniziano i problemi.

Nel nostro laboratorio i client del dominio virtual.lab devono quindi utilizzare come server DNS RM-DC1 e RM-DC2.

Questo non significa che i computer non potranno più risolvere i nomi Internet. Saranno i nostri DNS interni a occuparsi della risoluzione e, quando necessario, a inoltrare verso l’esterno le richieste che non possono risolvere direttamente.

Il percorso corretto diventa quindi:

Client –> DNS Active Directory –> DNS esterno

e non:

Client –> DNS pubblico

Questo vale anche per i Domain Controller. Non dobbiamo aggiungere un DNS pubblico alla configurazione della scheda di rete pensando di utilizzarlo come DNS “di backup”.

Un DNS secondario non è infatti un DNS che Windows utilizza solamente quando Internet non funziona. Il sistema può interrogarlo in determinate condizioni e, se quel server non conosce la nostra infrastruttura Active Directory, possiamo ottenere comportamenti difficili da diagnosticare.

Ed è proprio per questo che quando analizzo un problema di Active Directory una delle prime cose che controllo è sempre molto semplice:

Prima ancora di cercare problemi più complessi, voglio sapere quali server DNS sta realmente utilizzando quella macchina.

Nella figura sotto possiamo vedere la configurazione di un client del dominio. I server DNS configurati sono i Domain Controller RM-DC1 e RM-DC2. Non troviamo DNS pubblici configurati direttamente sulla scheda di rete.

Figura 5: Configurazione DNS di un computer appartenente al dominio virtual.lab. Il client utilizza esclusivamente i DNS dell’infrastruttura Active Directory

Ma allora chi risolve i nomi Internet?

Abbiamo detto che i computer del dominio devono utilizzare i DNS di Active Directory. A questo punto potrebbe sorgere spontanea una domanda: come fanno allora a risolvere nomi come www.microsoft.com?

La risposta è semplice: se il nostro DNS non conosce direttamente la risposta, può cercarla utilizzando altri server DNS.

Una possibilità è utilizzare i Root Hints, presenti per impostazione predefinita in Windows Server. Il DNS parte dai root server e segue la gerarchia DNS fino ad arrivare ai server autoritativi per il dominio che stiamo cercando.

In alternativa possiamo configurare uno o più Forwarder.

In questo caso diciamo al nostro DNS: quando ricevi una richiesta che non sei in grado di risolvere, inoltrala a questi server.

Ed è qui che possiamo eventualmente utilizzare il DNS del provider, quello del firewall oppure DNS pubblici.

La differenza è importante.

Non configuriamo 8.8.8.8 sul client del dominio. Configuriamo il client affinché utilizzi RM-DC1 e RM-DC2, e saranno questi ultimi, quando necessario, a inoltrare verso l’esterno le richieste DNS.

Il percorso rimane quindi:

Client –> DNS Active Directory –> Forwarder –> Internet

In questo modo il client utilizza sempre un DNS che conosce virtual.lab e tutti i record necessari ad Active Directory, ma continua comunque a poter risolvere i nomi Internet.

Vi consiglio di approfondire questo tema leggendo la mia guida Come funziona la risoluzione DNS nei sistemi operativi Windows – ICT Power

Configurare i Forwarder

Possiamo vedere la configurazione direttamente da DNS Manager.

Facciamo clic con il pulsante destro sul server DNS, scegliamo Properties e apriamo la scheda Forwarders.

Nella figura seguente possiamo vedere i server DNS verso i quali verranno inoltrate le richieste che il nostro DNS non è in grado di risolvere direttamente.

Figura 6: Configurazione dei Forwarder sul server DNS

Questo è un dettaglio che controllo praticamente sempre quando analizzo un’infrastruttura Active Directory: DNS utilizzati dalle schede di rete e Forwarder sono due cose completamente diverse.

Confonderli può significare avere una rete nella quale Internet funziona perfettamente, mentre Active Directory funziona male.

Zone DNS integrate in Active Directory

Abbiamo aggiunto RM-DC2 e abbiamo visto comparire automaticamente nel DNS i record necessari al nuovo Domain Controller.

Ma come vengono gestite queste informazioni?

Quando installiamo il servizio DNS insieme ad Active Directory possiamo utilizzare delle zone integrate in Active Directory. In questo caso i dati della zona DNS vengono memorizzati direttamente in Active Directory e possono essere replicati agli altri Domain Controller che ospitano DNS.

Nel nostro laboratorio sia RM-DC1 sia RM-DC2 possono quindi avere una copia della zona virtual.lab.

Questo offre un vantaggio importante: non abbiamo un unico server DNS che contiene la copia modificabile della zona. Le modifiche possono essere effettuate sui DNS che ospitano la zona e vengono poi replicate tramite Active Directory.

Possiamo verificarlo dalle proprietà della zona.

Come potete vedere dalla figura sotto, virtual.lab è configurata come Active Directory-Integrated.

Un’altra impostazione molto importante è Dynamic updates, configurata su Secure only.

Figura 7: Proprietà della zona virtual.lab. La zona è integrata in Active Directory e accetta solamente aggiornamenti dinamici sicuri

Aggiornamenti dinamici

Gli aggiornamenti dinamici sono particolarmente importanti in un ambiente Active Directory perché permettono ai computer e ai servizi del dominio di registrare e aggiornare automaticamente i propri record DNS.

È quello che abbiamo visto quando abbiamo aggiunto RM-DC2.

Non siamo entrati in DNS Manager per creare manualmente tutti i suoi record. Il Domain Controller ha provveduto a registrare i record necessari.

L’opzione Secure only aggiunge un altro elemento importante: l’aggiornamento non viene accettato semplicemente perché un computer invia una richiesta al DNS, ma viene utilizzata l’autenticazione di Active Directory per controllare chi può modificare i record.

In un dominio Active Directory, quindi, zone integrate in AD, replica e aggiornamenti dinamici sicuri lavorano insieme per mantenere le informazioni DNS disponibili e aggiornate sui Domain Controller.

DNS e Active Directory Sites

Fino a questo momento la nostra infrastruttura è stata abbastanza semplice. Abbiamo un dominio, virtual.lab, e due Domain Controller nella stessa sede.

Vediamo adesso cosa succede quando Active Directory è distribuita geograficamente.

Nel nostro laboratorio abbiamo creato due sedi, Roma e Milano. A Roma abbiamo RM-DC1 e RM-DC2, mentre a Milano abbiamo aggiunto MI-DC3 e MI-DC4.

Attraverso Active Directory Sites and Services abbiamo quindi creato due Site e associato a ciascuno le relative subnet.

Questo passaggio è molto importante. Active Directory utilizza infatti l’indirizzo IP di un computer e le subnet configurate nei Site per determinare a quale Site appartiene il computer.

Perché ci interessa? Immaginiamo un utente che accende il proprio computer nella sede di Milano. Nella nostra infrastruttura esistono quattro Domain Controller, ma non avrebbe molto senso utilizzare normalmente un Domain Controller di Roma, attraversando il collegamento geografico, quando ne abbiamo due disponibili nella rete locale.

Ed è qui che ritroviamo ancora una volta il DNS.

Quando abbiamo guardato per la prima volta la zona virtual.lab avevamo visto una cartella chiamata _sites. L’avevamo volutamente ignorata perché non ci serviva ancora.

Adesso possiamo finalmente capire a cosa serve. I Domain Controller registrano nel DNS anche dei record SRV specifici per il Site al quale appartengono. Questo permette ad Active Directory di individuare non soltanto i Domain Controller del dominio, ma anche quelli disponibili in uno specifico Site.

Possiamo verificarlo direttamente con nslookup.

Nel nostro esempio vogliamo sapere quali Domain Controller sono disponibili nel Site Milano:

La sintassi può sembrare complicata, ma quello che stiamo chiedendo al DNS è abbastanza semplice: “Quali Domain Controller offrono il servizio LDAP nel Site Milano per il dominio virtual.lab?”

Nella figura di seguito possiamo vedere sia la configurazione di Active Directory Sites and Services sia il risultato della query DNS.

A sinistra troviamo i due Site. Milano contiene MI-DC3 e MI-DC4, mentre Roma contiene RM-DC1 e RM-DC2.

La query DNS relativa al Site Milano restituisce infatti solamente MI-DC3 e MI-DC4, con i rispettivi indirizzi IP 172.16.0.13 e 172.16.0.14.

Figura 8: Active Directory è distribuita tra i Site Roma e Milano. Interrogando il record SRV relativo al Site Milano, il DNS restituisce MI-DC3 e MI-DC4

Questo ci permette di capire quanto sia importante configurare correttamente Site e subnet.

Non è sufficiente installare un Domain Controller nella sede di Milano per fare in modo che i computer di quella rete lo considerino automaticamente “vicino”. Active Directory deve sapere quali subnet appartengono a Milano e quali appartengono a Roma.

Una configurazione errata o incompleta delle subnet può quindi portare i client a utilizzare Domain Controller di altri Site, con autenticazioni e accesso ai servizi che attraversano inutilmente i collegamenti geografici.

Il DNS, ancora una volta, è una parte fondamentale del meccanismo. Non viene utilizzato solamente per trasformare mi-dc3.virtual.lab nell’indirizzo 172.16.0.13, ma permette ad Active Directory di pubblicare dove si trovano i propri servizi.

È questa la differenza fondamentale che dobbiamo ricordare quando parliamo di DNS in Active Directory: non stiamo semplicemente risolvendo nomi, stiamo trovando servizi.

Quali DNS utilizziamo nelle sedi remote?

Quando abbiamo più Site dobbiamo prestare attenzione anche all’ordine con cui configuriamo i server DNS.

Nella nostra infrastruttura la sede di Milano dispone di due Domain Controller che svolgono anche il ruolo di DNS Server. I server della sede utilizzano quindi come DNS primari quelli presenti localmente a Milano e, successivamente, quelli disponibili nella sede di Roma.

Nella figura sotto possiamo vedere la configurazione DNS di un server della sede di Milano. I primi server DNS configurati appartengono alla rete locale 172.16.0.0/24, mentre successivamente sono presenti anche i DNS della sede di Roma sulla rete 10.10.10.0/24.

Figura 9: Configurazione DNS di un server della sede di Milano. Vengono utilizzati prioritariamente i DNS locali e successivamente quelli disponibili nella sede di Roma

Perché utilizzare questo ordine?

Prima di tutto vogliamo che normalmente le richieste DNS vengano gestite all’interno della sede di Milano, senza attraversare inutilmente il collegamento geografico verso Roma.

C’è però un altro aspetto importante. Poiché stiamo utilizzando zone DNS integrate in Active Directory, i DNS di Milano e quelli di Roma dispongono delle informazioni necessarie per risolvere il dominio virtual.lab. Non stiamo quindi configurando quattro DNS differenti dal punto di vista logico: stiamo indicando più server DNS che possono ospitare e risolvere la stessa zona Active Directory.

Avere anche i DNS dell’altra sede ci offre inoltre un’ulteriore possibilità di risoluzione nel caso in cui quelli locali non siano raggiungibili.

La regola rimane comunque la stessa vista in precedenza: tutti i DNS configurati sulla scheda devono essere DNS in grado di risolvere correttamente Active Directory.

Non aggiungiamo quindi un DNS pubblico come ultima voce pensando che possa essere utilizzato come soluzione di emergenza per Internet. La risoluzione dei nomi esterni continuerà a essere gestita dai nostri DNS attraverso Forwarder o Root Hints.

Questa distinzione è fondamentale: la lista configurata sulla scheda di rete serve a garantire la risoluzione DNS interna, non a creare una lista di DNS interni ed esterni da provare in sequenza.

Come configurare il DNS sui Domain Controller

Finora abbiamo visto quale DNS devono utilizzare client e server del dominio, ma durante i corsi c’è una domanda che mi viene fatta molto spesso: quale DNS devo configurare sui Domain Controller?

Il principio rimane quello visto in precedenza: dobbiamo utilizzare esclusivamente DNS in grado di risolvere Active Directory, preferendo quelli presenti nello stesso Site. La differenza è che un Domain Controller che svolge anche il ruolo di DNS Server può utilizzare anche se stesso come resolver.

Nel nostro laboratorio abbiamo due Domain Controller nel Site Roma e due nel Site Milano. MI-DC3, ad esempio, può utilizzare prima MI-DC4, poi se stesso e successivamente i DNS presenti a Roma. Su MI-DC4 possiamo applicare la configurazione opposta. In questo modo le normali richieste DNS rimangono nel Site locale, ma possiamo comunque utilizzare gli altri DNS interni dell’infrastruttura.

Nota: sui Domain Controller è utile configurare i DNS in modo incrociato, facendo utilizzare come DNS preferito l’altro DC dello stesso Site e se stesso come alternativa. In questo modo il Domain Controller non dipende immediatamente dal proprio servizio DNS e, soprattutto durante l’avvio, può ottenere le informazioni di Active Directory da un DNS già operativo. La configurazione incrociata riduce quindi la dipendenza da se stessi e migliora la ridondanza del servizio DNS.

Una particolare attenzione va prestata quando installiamo un nuovo Domain Controller. Prima e durante la promozione deve utilizzare un DNS del dominio già funzionante, preferibilmente nello stesso Site. Non dobbiamo far dipendere un server che stiamo promuovendo esclusivamente dal proprio DNS.

Possiamo vedere cosa è successo nel nostro laboratorio con RM-DC2. Prima della promozione utilizzava RM-DC1, 10.10.10.10, come DNS. Dopo la promozione a Domain Controller e l’installazione del servizio DNS, RM-DC1 è rimasto il DNS preferito ed è comparso 127.0.0.1 come DNS alternativo.

Figura 10: Configurazione DNS di RM-DC2 dopo la promozione a Domain Controller. RM-DC1 è il DNS preferito, mentre 127.0.0.1 permette a RM-DC2 di interrogare il proprio servizio DNS

127.0.0.1 è l’indirizzo di loopback e identifica il computer stesso. RM-DC2, essendo adesso anche un DNS Server, può quindi utilizzare il proprio servizio DNS per effettuare le query.

Questo evidenzia un concetto importante: un Domain Controller che ospita DNS è contemporaneamente server DNS e client DNS. Offre il servizio agli altri computer, ma deve comunque avere una propria configurazione DNS.

Una volta verificato che Active Directory, DNS e replica funzionano correttamente, possiamo utilizzare anche il nuovo Domain Controller come resolver e applicare la stessa logica utilizzata sugli altri DC: preferire i DNS dello stesso Site e utilizzare solamente DNS interni che conoscano Active Directory.

Non configuriamo quindi mai 8.8.8.8, 1.1.1.1 o altri DNS pubblici direttamente sulla scheda di rete di un Domain Controller. Se vogliamo utilizzarli per la risoluzione Internet, rimangono configurati come Forwarder sui nostri DNS interni. È la terza volta che lo scrivo!

Maggiori informazioni sono disponibili alla pagina Recommendations for Domain Name System (DNS) client settings – Windows Server | Microsoft Learn

Aggiungiamo un dominio figlio

Finora abbiamo lavorato con un solo dominio, virtual.lab. Aggiungiamo adesso un dominio figlio chiamato sviluppo.virtual.lab, che farà parte della stessa foresta Active Directory ma avrà i propri Domain Controller.

Prima di procedere, voglio però tornare su un messaggio che probabilmente molti hanno già incontrato durante la promozione di un Domain Controller.

Quando creiamo una nuova foresta, nella pagina DNS Options compare il seguente avviso:

A delegation for this DNS server cannot be created because the authoritative parent zone cannot be found…

Molti interpretano questo messaggio come un errore del DNS. In realtà, nella maggior parte dei nostri scenari, non è un errore e non impedisce di proseguire con la promozione.

Per comprenderlo dobbiamo ricordare che il DNS utilizza una struttura gerarchica. Se stiamo creando, ad esempio, il dominio virtual.lab, il wizard verifica se esiste una zona DNS padre nella quale possa creare una delega verso i DNS che saranno autoritativi per virtual.lab.

Nel nostro laboratorio questa zona padre non esiste. Stiamo creando una nuova foresta e virtual.lab rappresenta l’inizio del nostro namespace Active Directory. Il wizard non trova quindi una zona padre nella quale creare automaticamente la delega e ci avvisa della situazione.

Figura 11: Durante la creazione di una nuova foresta il wizard può segnalare che non è possibile creare una delega DNS perché non è disponibile una zona padre autoritativa

Adesso però stiamo per fare qualcosa di diverso.

Creeremo sviluppo.virtual.lab e questa volta una zona padre esiste già: virtual.lab.

Il nuovo dominio farà parte della stessa foresta e i DNS autoritativi per virtual.lab sono già disponibili. Durante la creazione del dominio figlio il wizard può quindi proporci Create DNS delegation e utilizzare credenziali con i permessi necessari per creare la delega nella zona padre.

Nella figura possiamo vedere la stessa pagina del wizard durante la promozione di SW-DC1 come primo Domain Controller di sviluppo.virtual.lab. Questa volta è disponibile l’opzione Create DNS delegation.

Figura 12: Durante la creazione del dominio figlio sviluppo.virtual.lab è possibile creare una delega nella zona padre virtual.lab verso i DNS autoritativi del dominio figlio

Ed è proprio questo confronto che ci permette di capire finalmente che cosa sia una delega DNS.

La zona virtual.lab non deve contenere tutti i record di sviluppo.virtual.lab. Deve sapere quali DNS sono autoritativi per quella parte del namespace.

In termini molto semplici, la delega permette al DNS padre di dire:

“Per tutto ciò che riguarda sviluppo.virtual.lab, chiedi a questi DNS.”

Cosa è stato creato nel DNS?

Terminata la promozione di SW-DC1 possiamo tornare sul DNS del dominio padre virtual.lab e vedere cosa è realmente successo.

Dal DNS Manager possiamo notare che all’interno della zona virtual.lab è comparsa la delega sviluppo.

Aprendola troviamo un record NS (Name Server) che indica SW-DC1.sviluppo.virtual.lab come server DNS autoritativo per il namespace delegato.

Figura 13: La delega sviluppo nella zona DNS virtual.lab indica SW-DC1.sviluppo.virtual.lab come server DNS autoritativo per il dominio figlio

Questo è esattamente il risultato della delega che abbiamo richiesto durante la creazione del dominio figlio.

Il DNS di virtual.lab non diventa autoritativo per sviluppo.virtual.lab e non deve contenere tutti i record del nuovo dominio. Sa invece a quali DNS rivolgersi quando deve risolvere un nome appartenente a quel namespace.

In altre parole, quando un DNS autoritativo per virtual.lab riceve una richiesta relativa a sviluppo.virtual.lab, la delega gli permette di sapere quali server DNS sono autoritativi per quella parte del namespace.

È importante anche notare che quello che vediamo sotto virtual.lab non è la zona DNS sviluppo.virtual.lab: è la delega presente nella zona padre. La vera zona sviluppo.virtual.lab, con i record del dominio figlio, si trova sui DNS che la ospitano.

Ed è proprio questa distinzione che rende molto più semplice capire il concetto di delega: il padre non deve conoscere ciò che contiene il figlio, deve sapere dove trovarlo.

Figura 14: La zona sviluppo.virtual.lab ospitata da SW-DC1. A differenza della delega presente nel dominio padre, qui troviamo la vera zona DNS del dominio figlio e i relativi record

La zona _msdcs.virtual.lab

Fin dalle prime schermate di questa guida abbiamo visto comparire una zona dal nome un po’ particolare: _msdcs.virtual.lab.

Finora non ci siamo soffermati troppo sul suo contenuto. Adesso che la nostra infrastruttura comprende anche un dominio figlio vale la pena capire a cosa serve e perché è così importante per Active Directory.

Il nome ci dà già un’indicazione. _msdcs significa Microsoft Domain Controller Services e la zona è associata al nome del dominio radice della foresta, nel nostro caso virtual.lab.

A differenza della zona virtual.lab, che contiene i record relativi al dominio, _msdcs.virtual.lab contiene principalmente record utilizzati da Active Directory per individuare Domain Controller e servizi a livello di foresta.

Al suo interno troviamo, ad esempio, record utilizzati per individuare i Global Catalog, i Domain Controller e altri servizi necessari al funzionamento di Active Directory. Troviamo inoltre particolari record CNAME associati al GUID dei Domain, utilizzati anche nei meccanismi di replica tra DC.

Figura 15: La zona _msdcs.virtual.lab sul DNS di RM-DC1 contiene record utilizzati per individuare Domain Controller e servizi disponibili all’interno della foresta Active Directory

C’è però un aspetto importante da chiarire. _msdcs.virtual.lab non esiste solamente sui DNS del dominio radice.

La zona è normalmente integrata in Active Directory e viene replicata attraverso la partizione ForestDnsZones. Il suo ambito è quindi la foresta, non il singolo dominio.

Per questo motivo la stessa zona _msdcs.virtual.lab è disponibile anche su SW-DC1, nonostante quel Domain Controller appartenga a sviluppo.virtual.lab.

Non viene creata una nuova zona _msdcs.sviluppo.virtual.lab. Continuiamo a utilizzare _msdcs.virtual.lab, perché virtual.lab è il dominio radice della nostra foresta.

Questo ci permette di distinguere due concetti che ormai dovrebbero essere più chiari: sviluppo.virtual.lab contiene le informazioni DNS relative al dominio figlio, mentre _msdcs.virtual.lab contiene informazioni necessarie per individuare servizi e domini nell’ambito della foresta.

Un Domain Controller del dominio figlio appartiene a un dominio diverso, ma continua a far parte della stessa foresta. Ed è proprio per questo che anche lui deve poter accedere alle informazioni contenute in _msdcs.virtual.lab.

Figura 16: La zona _msdcs.virtual.lab vista dal DNS di SW-DC1. La zona contiene informazioni relative ai servizi disponibili nell’intera foresta, compresi Domain Controller appartenenti a domini diversi

Come verificare che il DNS di Active Directory funzioni correttamente

Abbiamo visto che Active Directory utilizza continuamente il DNS per individuare Domain Controller, Global Catalog, servizi Kerberos e LDAP. Quando qualcosa non funziona, quindi, il DNS è uno dei primi componenti che dobbiamo controllare.

La prima verifica che faccio è quasi sempre molto semplice:

Prima di cercare problemi più complessi voglio sapere quali DNS sta realmente utilizzando il computer.

Se trovo il DNS del router, del firewall oppure un DNS pubblico, abbiamo già qualcosa da correggere. Come abbiamo visto, un computer appartenente al dominio deve utilizzare DNS in grado di risolvere Active Directory.

Il secondo controllo consiste nel verificare che il computer riesca effettivamente a trovare un Domain Controller:

Il comando utilizza i meccanismi di DC Locator e ci permette di vedere quale Domain Controller viene individuato per il dominio.

Possiamo poi interrogare direttamente i record SRV che abbiamo utilizzato durante tutta la guida:

Se vogliamo verificare i Domain Controller pubblicati per uno specifico Site possiamo invece utilizzare, ad esempio:

Queste query sono particolarmente utili perché ci permettono di verificare ciò che il DNS sta realmente restituendo, invece di limitarci a guardare i record presenti nella console DNS.

Sui Domain Controller abbiamo poi uno strumento ancora più completo:

DCDiag esegue una serie di controlli sul DNS utilizzato da Active Directory e può aiutarci a individuare problemi di risoluzione, registrazione dei record e configurazione.

Non serve conoscere decine di comandi per iniziare a diagnosticare un problema DNS in Active Directory. Nella maggior parte dei casi parto da poche domande: quale DNS sto utilizzando? Riesco a trovare il dominio? Riesco a trovare un Domain Controller? I record SRV sono presenti e corretti?

Solo dopo aver risposto a queste domande ha senso cercare problemi più complessi.

Figura 17: Alcune semplici verifiche permettono di controllare che il DNS individui correttamente il dominio e i Domain Controller disponibili nel Site Milano

Gli errori DNS che incontro più spesso in Active Directory

All’inizio della guida ho scritto che circa il 90% dei problemi di Active Directory che incontro dai clienti ha in qualche modo a che fare con il DNS.

Può sembrare un’esagerazione, ma dopo aver visto come Active Directory utilizza il DNS dovrebbe essere più semplice comprenderne il motivo.

Uno degli errori più frequenti è sicuramente trovare sui client, sui server o addirittura sui Domain Controller DNS pubblici o DNS che non conoscono Active Directory. La navigazione Internet funziona e questo porta a pensare che anche il DNS stia funzionando correttamente. Come abbiamo visto, però, risolvere www.microsoft.com e trovare un Domain Controller sono due cose completamente diverse.

Un altro problema frequente riguarda le infrastrutture con più sedi. Vengono installati Domain Controller locali, ma Site e subnet non sono configurati correttamente. Il risultato può essere che i client continuino a individuare Domain Controller presenti in altre sedi, attraversando inutilmente i collegamenti geografici.

Anche la configurazione DNS dei Domain Controller merita particolare attenzione. Un DC che utilizza resolver non appropriati può avere problemi nella registrazione dei propri record DNS, nell’individuazione degli altri Domain Controller e, di conseguenza, anche nella replica di Active Directory.

Poi ci sono i record DNS stessi. Record vecchi, duplicati o mancanti possono raccontare al resto dell’infrastruttura una situazione diversa da quella reale. Prima di ricreare manualmente un record SRV, però, preferisco sempre capire perché il Domain Controller non lo ha registrato correttamente. La registrazione automatica dei record fa parte del normale funzionamento di Active Directory: se dobbiamo continuamente correggerli a mano, probabilmente stiamo intervenendo sul sintomo e non sulla causa.

Lo stesso vale per deleghe, Forwarder e zone DNS. Una configurazione diventata complessa nel corso degli anni, magari modificata da amministratori diversi, può rendere difficile capire quale server sia realmente responsabile di una zona e quale percorso segua una richiesta DNS.

Per questo motivo, quando devo analizzare un’infrastruttura Active Directory, cerco inizialmente di mantenere il troubleshooting molto semplice.

Parto dalla configurazione IP, controllo quali DNS vengono utilizzati, verifico la risoluzione dei nomi e poi controllo che attraverso i record SRV sia possibile individuare correttamente Domain Controller e servizi Active Directory.

Solo dopo passo ad analizzare problemi più complessi.

Molte volte il problema che sembrava riguardare autenticazione, Group Policy, replica o trust era iniziato molto prima, con una configurazione DNS sbagliata.

Ed è probabilmente questo il concetto più importante dell’intera guida:

se Active Directory non funziona correttamente, prima di cercare una causa complicata controllate il DNS.

Conclusioni

Il DNS in Active Directory non è semplicemente il servizio che permette di trasformare un nome in un indirizzo IP. È uno dei componenti fondamentali dell’intera infrastruttura.

Abbiamo visto come Active Directory utilizzi il DNS per individuare Domain Controller e servizi, come i record SRV permettano al DC Locator di trovare il DC più appropriato e come Site e subnet influenzino questo processo quando l’infrastruttura è distribuita geograficamente.

Abbiamo anche visto il ruolo delle zone integrate in Active Directory, degli aggiornamenti dinamici, delle deleghe DNS e della particolare zona _msdcs, utilizzata per pubblicare informazioni necessarie all’intera foresta.

Ma soprattutto abbiamo visto quanto sia importante partire da una configurazione corretta: client, server e Domain Controller devono utilizzare DNS che conoscano Active Directory. I DNS pubblici, se necessari, devono rimanere a valle dei nostri DNS interni attraverso i Forwarder.

Quando Active Directory presenta comportamenti strani, prima di cercare spiegazioni complicate vale quindi sempre la pena partire da una domanda molto semplice:

il DNS è configurato e sta funzionando correttamente?