Abbiamo il dominio primario della nostra organizzazione (con AD) example.com. In passato, gli amministratori precedenti avevano creato diverse altre zone - come dmn.com, lab.example.com, dmn-geo.com ecc. - così come sottodomini e delegati, tutti per diversi gruppi di ingegneri. Il nostro DNS in questo momento è un po 'un casino. E, naturalmente, ciò causa problemi quando qualcuno in una stazione di lavoro in example.com deve connettersi a un sistema in una qualsiasi di queste altre zone / sottodomini o viceversa (parzialmente perché il trasferimento e la delega delle zone non sono configurati correttamente per la maggior parte di essi) .
Il nostro DNS di produzione è integrato con Active Directory, ma i sistemi di ingegneria dovrebbero essere isolati da AD.
Stiamo discutendo i modi per riorganizzare il DNS e consolidare tutte queste diverse voci. Vedo tre strade diverse che possiamo prendere:
- Crea una nuova zona, ad esempio "dmn.eng". Questo potrebbe essere gestito dall'IT, usando i nostri server DNS o ingegneria usando i loro nameserver.
- Crea un nuovo delegato eng.example.com, consolida il DNS di ingegneria in quel sottodominio e lascia che gli ingegneri gestiscano il nameserver per il delegato.
- Crea un nuovo sottodominio eng.example.com senza delega e gestisci noi stessi il DNS per il sottodominio.
Preferisco creare un sottodominio delegato e lasciare che gli ingegneri abbiano il pieno controllo della propria struttura DNS all'interno di quel sottodominio. Il vantaggio è che se il loro DNS non funziona, molto probabilmente non è colpa mia;). Tuttavia, c'è ancora qualche ambiguità riguardo alla responsabilità quando qualcosa non funziona e richiederà il coordinamento con l'ingegneria per impostare, configurare e amministrare.
Se non deleghiamo il sottodominio, ciò significa molto più lavoro per l'IT di produzione che gestisce DNS non di produzione (che essenzialmente abbiamo già fatto molto). Il vantaggio è che abbiamo il pieno controllo su tutti i DNS e quando qualcosa non funziona non vi è alcun dubbio sulla responsabilità di ripararlo. Possiamo anche aggiungere delegati, come geo.eng.example.com, per offrire maggiore flessibilità e controllo all'ingegneria quando ne hanno bisogno.
Sono davvero incerto sulla necessità o sui benefici della creazione di una nuova zona, dmn.eng.
Quali sono le migliori pratiche e raccomandazioni del settore per situazioni come questa? Quale soluzione sarebbe la più semplice da implementare e fornire una risoluzione dei nomi senza soluzione di continuità tra ingegneria e produzione? Quali sono alcuni potenziali benefici o insidie per ogni soluzione che potrei perdere?
Per aggiungere un po 'più di informazioni, siamo una società di produzione abbastanza grande. Questi ingegneri lavorano in ricerca e sviluppo, sviluppo e controllo qualità. I laboratori hanno spesso le proprie sottoreti o intere reti, DHCP, ecc. Per quanto riguarda l'organizzazione e la tecnologia, sono una specie di piccolo mondo.
Vogliamo mantenere un certo livello di isolamento della rete per i laboratori di ingegneria e le reti al fine di proteggere il nostro ambiente di produzione (fare riferimento a una domanda precedente relativa agli ingegneri che hanno aggiunto i server DHCP di ingegneria come server DHCP AD autorevoli - che non dovrebbe essere possibile). Tuttavia, un utente in una stazione di lavoro in un laboratorio dovrà accedere a una risorsa nella nostra rete di produzione, oppure un utente in una stazione di lavoro nella nostra rete di produzione dovrà connettersi a un sistema di laboratorio, e ciò accade con frequenza sufficiente per giustificare una sorta -di DNS unificato.
I delegati esistenti dispongono già di server DNS gestiti dall'ingegneria, ma non esiste comunicazione tra gli ingegneri nei diversi laboratori in cui sono installati questi server, quindi il problema più comune è la risoluzione dei nomi non riuscita tra sottodomini. Dato che gli ingegneri possiedono quei server delegati, non posso correggere le voci NS per farle dialogare, quindi il vantaggio del DNS non delegato interamente di proprietà dell'IT. Ma gestire il DNS per la produzione e l' ingegneria è un mal di testa, soprattutto perché l'ingegneria può apportare modifiche al DNS su base giornaliera. Ma come ha detto BigHomie nella sua risposta, questo probabilmente significa che l'ingegneria dovrà assumere (o designare) un vero amministratore DNS; e quella persona e io dovremo conoscere abbastanza bene.
Non mi piace necessariamente l'idea di creare una nuova zona con un nome di dominio o suffisso arbitrario di primo livello, ma abbiamo già altre 5 zone con nomi arbitrari, quindi il consolidamento in una singola è ancora un miglioramento. So che esistono altre società che dispongono di zone di livello superiore separate per diversi gruppi nella loro organizzazione, quindi sono curioso di sapere quando è appropriato e quali sono i vantaggi / gli svantaggi di tale approccio.
Cordiali saluti, sono stato in questa azienda solo per alcuni mesi e il precedente amministratore AD / DNS ha lasciato l'azienda, quindi non ho nulla da fare riferimento al perché esiste una delle strutture DNS esistenti.
Our production DNS is integrated with Active Directory, but engineering systems should be isolated from AD.Questo commento mi fa chiedere se forse dovresti considerare di avere una foresta AD separata per l'ingegneria, onestamente.