Le best practice per la progettazione di domini Active Directory (AD) sconsigliano l'utilizzo di un nome di dominio registrato come nome di un dominio AD. Le alternative valide comprendono l'utilizzo di un suffisso di DNS non pubblico (ad esempio,local o . LAN) nel nome di dominio ad, oppure di rendere il dominio ad un sottodominio del dominio registrato (ad esempio,Corp.Domain.com).
Non avrete sempre una scelta in materia, tuttavia; l'utente potrebbe avere il supporto di un dominio AD con lo stesso nome del dominio registrato dell'azienda e la gestione potrebbe non voler modificare il nome. Si tratta di uno scenario di tipo split DNS (o split-brain DNS) in cui sono presenti due namespace DNS distinti: lo spazio dei nomi interno utilizzato da ad e lo spazio dei nomi esterno utilizzato dal registrar di Public Domain, con lo stesso nome. Questo scenario può presentare alcune sfide esclusive. In questo articolo vengono illustrati alcuni problemi comuni derivati da un ambiente di DNS suddiviso e ciò che può essere fatto per attenuarli.
In tutti gli esempi riportati di seguito, il dominio Active Directory e il dominio registrato sono entrambi denominati Domain.come vi è un sito Web aziendale denominato www.Domain.com.
Problema 1: Sito Web aziendale ospitato dall'esterno inaccessibile dall'interno dell'ufficio
Si tratta del problema più comune in un ambiente di DNS suddiviso: il sito Web aziendale, o un'altra risorsa collegata a Internet di proprietà dell'azienda, non può essere raggiunto dall'interno dell'ufficio da macchine unite al dominio AD, ma le macchine al di fuori dell'ufficio non hanno alcun problema a raggiungere il sito Web. Il motivo per cui si verifica questa operazione può essere visualizzato esaminando cosa accade quando un utente interno tenta di sfogliare il sito Web dell'azienda:
Il problema si verifica perché un server DNS che ha una particolare zona di ricerca nel proprio database-la zona Domain.com in questo esempio-non invia query per i record in tale zona in qualsiasi altro luogo; restituisce semplicemente una risposta "not found" se non è presente alcun record che corrisponde a una query specificata. In questo esempio, è disponibile un altro DNS server con il record corretto: il DNS server che ospita la zona Domain.com pubblica appartenente al registrar di dominio, come risulta evidente dal fatto che i computer che si trovano al di fuori dell'ufficio possono accedere al sito Web. Le query provenienti da macchine interne non raggiungono mai quel server.
La soluzione a questo problema è semplice: creare un record host denominato www nella zona Domain.com sul controller di stato e fornire al record l'indirizzo IP del sito Web. Le macchine che eseguono query che DNS server ricevono quindi la risposta corretta ed è possibile sfogliare il sito Web.
Problema 2: Sito Web pubblico ospitato internamente inaccessibile dall'interno dell'ufficio
Questa operazione può essere considerata una variante del problema 1. La differenza in questo caso è che il sito Web è ospitato internamente, sia dietro un firewall sulla rete interna dell'azienda sia in una DMZ. Si suppone che sia accessibile agli utenti interni ed esterni, ma gli utenti interni non sono in grado di raggiungerlo, mentre gli utenti esterni non segnalano alcun problema.
Il motivo del problema è simile a quello del problema 1, ma in questo caso gli utenti interni possono risolvere correttamente il nome del sito Web con l'indirizzo IP pubblico. Tuttavia, non sono ancora in grado di raggiungere il sito Web a causa del modo in cui è configurato il firewall. Si prevede che gli utenti sulla rete interna accedano al sito Web utilizzando il proprio indirizzo privato piuttosto che il suo indirizzo pubblico.
Ancora una volta, vi è una semplice correzione: creare un record host di nome www nella zona Domain.com sul controller di stato, ma questa volta fornire al record l'indirizzo IP privato del sito Web. Le macchine interne consentono di risolvere il nome del sito Web in quell'indirizzo privato, mentre le macchine esterne continuano a risolvere il nome dell'indirizzo pubblico del sito Web.
Problema 3: Il sito Web carica incompleto o ancora non viene caricato dopo che sono state
apportate le modifiche. Ciò può verificarsi se il codice del sito Web reindirizza i browser da www.Domain.com a Domain.com o se i link interni si riferiscono al sito come Domain.com anziché www.Domain.com. Gli stessi sintomi vengono visualizzati sui computer interni se il sito è ospitato internamente o esternamente:
Il problema in questo caso è un po' più complesso. Per consentire ai computer di risolvere Domain.com in un indirizzo IP, nel DNS deve essere presente un record host vuoto nella zona Domain.com . Il nome di questo record viene visualizzato come (come cartella padre) nella console di Windows DNS. In questo caso, tuttavia, si verifica un problema: AD usa record host vuoti nella zona Domain.com per rappresentare i DCS per il dominio Domain.com . I membri del dominio utilizzano tali record durante l'individuazione di un controller di dominio per l'autenticazione e, se sono presenti record host vuoti aggiuntivi nella zona Domain.com , potrebbero verificarsi ritardi o problemi di autenticazione.
Per il motivo precedente, questo problema non può essere risolto solo in DNS. La creazione di un record host vuoto con l'indirizzo IP del sito Web risolve solo in modo intermittente il problema di accesso al sito Web per gli utenti interni, in quanto vi sono già altri record host vuoti con gli indirizzi IP dei DCs nel dominio e ciò causa problemi di autenticazione di dominio.
Il modo più semplice per risolvere questo problema è quello di modificare il codice del sito Web per rimuovere il reindirizzamento o per risolvere i link interni in modo che tutto si riferisca al sito come www.Domain.com anziché Domain.com. Se non è possibile modificare il codice, l'unica altra opzione per risolvere il problema è quello di rinominare il dominio AD. Può trattarsi di un'attività complessa, a seconda delle dimensioni e della complessità dell'ambiente.