Denominazione di una nuova foresta di Active Directory: perché il DNS split-horizon non è consigliato?

Speriamo che sappiamo tutti quali sono i consigli per nominare una foresta di Active Directory e sono piuttosto semplici. Vale a dire, può essere riassunto in una sola frase.

Usa un sottodominio di un nome di dominio registrato esistente e scegline uno che non verrà utilizzato esternamente. Ad esempio, se dovessi incorporare e registrare il hopelessn00b.comdominio, la mia foresta AD interna dovrebbe essere denominata internal.hopelessn00b.como ad.hopelessn00b.como corp.hopelessn00b.com.

Ci sono ragioni straordinariamente convincenti per evitare l'uso di tlds "falsi" o nomi di dominio a etichetta singola , ma ho difficoltà a trovare ragioni altrettanto convincenti per evitare di usare il dominio root ( hopelessn00b.com) come nome del mio dominio e utilizzare un sottodominio come corp.hopelessn00b.cominvece . In realtà, l'unica giustificazione che riesco a trovare è che l'accesso al sito Web esterno da interno richiede un A namerecord DNS e la digitazione www.davanti al nome del sito Web in un browser, che è piuttosto "meh" per quanto riguarda i problemi.

Quindi, cosa mi sto perdendo? Perché è molto meglio usare ad.hopelessn00b.comcome nome della mia foresta di Active Directory hopelessn00b.com?

Solo per la cronaca, è davvero il mio datore di lavoro che ha bisogno di essere convincente: il capo uomo sta vendendo a fondo e, dopo avermi dato il via libera per creare una nuova foresta AD chiamata corp.hopelessn00b'semployer.comper la nostra rete interna, vuole restare con una foresta AD chiamata hopelessn00b'semployer.com( lo stesso del nostro dominio registrato esternamente). Spero di poter ottenere qualche motivo convincente o ragioni per cui la migliore pratica è l'opzione migliore, quindi posso convincerlo di questo ... perché sembra più facile che smettere di rabbia e / o trovare un nuovo lavoro, almeno per il momento. In questo momento, le "best practice di Microsoft" e l'accesso interno al sito Web pubblico per la nostra azienda non sembrano tagliarlo, e spero davvero , davvero , davvero che qualcuno qui abbia qualcosa di più convincente.

Così tanto rappresentante da avere. Vieni da me prezioso.

Ok, quindi è abbastanza ben documentato da Microsoft che non dovresti usare split-horizon o un TLD inventato come hai collegato molte volte (grida al mio blog!). Ci sono alcuni motivi per questo.

1. Il wwwproblema che hai sottolineato sopra. Fastidioso, ma non un rompicapo.

2. Ti obbliga a conservare record duplicati per tutti i server pubblici accessibili anche internamente, non solo www. mail.hopelessnoob.comè un esempio comune. In uno scenario ideale, avresti una rete perimetrale separata per cose come mail.hopelessnoob.como publicwebservice.hopelessnoob.com. Con alcune configurazioni, come un ASA con interfacce interne ed esterne , vi sia bisogno dentro-dentro NAT o split-horizon DNS in ogni caso , ma per le organizzazioni più grandi con una rete perimetrale legittima in cui le risorse web rivolta non sono dietro un confine NAT tornante - questo provoca lavoro inutile.

3. Immagina questo scenario: sei hopelessnoob.cominternamente ed esternamente. Hai una società con cui stai collaborando chiamato example.come fanno la stessa cosa - dividi l'orizzonte internamente con il loro annuncio e con il loro spazio dei nomi DNS accessibile al pubblico. Ora, si configura una VPN da sito a sito e si desidera che l'autenticazione interna attraversi il tunnel dalla fiducia mentre si ha accesso alle proprie risorse pubbliche esterne per uscire su Internet. È quasi impossibile senza instradamento delle politiche incredibilmente complicato o con la propria copia della propria zona DNS interna - ora hai appena creato un set aggiuntivo di record DNS da mantenere. Quindi devi fare i conti con la forcina alla fine ela loro fine, il routing delle politiche / NAT e tutti i tipi di altri trucchi. (In realtà ero in questa situazione con un annuncio che ho ereditato).

4. Se mai distribuisci DirectAccess , questo semplifica drasticamente i tuoi criteri di risoluzione dei nomi - questo è probabilmente vero anche per altre tecnologie VPN split-tunnel.

Alcuni di questi sono casi limite, altri no, ma sono tutti facilmente evitabili. Se hai la possibilità di farlo dall'inizio, potresti anche farlo nel modo giusto in modo da non incorrere in uno di questi in un decennio.

Questa affermazione: "Davvero, l'unica giustificazione che riesco a trovare è che per accedere al sito Web esterno da interno è necessario un record DNS SRV e digitare www. Davanti al nome del sito Web in un browser" non è vero.

Significa che devi conservare una copia di tutti i tuoi record pubblici nei tuoi server DNS AD, il che potrebbe causare problemi, in particolare se non lo fai correttamente - perdere alcuni, ecc. Se qualcuno vuole raggiungere ftp.company. com ma ti dimentichi di creare l'alias nel DNS interno (o non lo ha automatizzato correttamente), le persone interne non possono assolutamente raggiungere il sito FTP pubblico.

Questo è abbastanza ben definito nella domanda a cui hai collegato: Best practice per la denominazione di Windows Active Directory?

Se mantenere più copie delle tue zone DNS è un problema facile da risolvere correttamente, per sempre, allora suppongo che tu possa fare quello che vuoi. Fino a quando MS non cambia qualcosa che lo rompe. Si poteva solo seguire le loro raccomandazioni.

Non mi interessa abbastanza il rappresentante per creare una risposta lunga oggi ... quindi la terrò breve.

Stavo bene con split-dns e lo implementavo più volte fino a quando Evan e Mark non mi convinsero diversamente. Onestamente NON è che non si può fare ... può, e alcuni potrebbero andare bene (nonostante le spese generali e il lavoro svolto per questo).

2 cose specifiche sono emerse anni fa per me che si sono solidificate NON utilizzandolo:

1. Come hai sottolineato nella tua domanda, semplicemente non puoi consentire agli utenti interni di accedere al tuo sito Web esterno solo tramite il nome di dominio. Non chiederti perché è stato un grosso problema, ma avevamo utenti interni che si sarebbero resi conto che digitando solo il nome di dominio in un browser senza wwwaprire il sito Web reale, poiché il record di dominio corrisponde al dominio AD e non è un problema per arrivare wwwe NON PUO 'ESSERE internamente.
2. Problemi di Exchange: Exchange AutoDiscover non riesce a ottenere i certificati e richiederà un errore. Questo può accadere sia internamente che esternamente. Ciò è diventato ancora più evidente quando abbiamo iniziato a disporre di "cassette postali forestali esterne" nella nostra organizzazione di Exchange e non vedevano lo stesso DNS interno che avevamo.

Spero che sia d'aiuto.