Tenemos el dominio principal de nuestra organización (con AD) example.com. En el pasado, los administradores anteriores habían creado varias otras zonas, como dmn.com, lab.example.com, dmn-geo.com, etc., así como subdominios y delegados, todos ellos para diferentes grupos de ingeniería. Nuestro DNS en este momento es un poco complicado. Y, por supuesto, esto causa problemas cuando alguien en una estación de trabajo en example.com necesita conectarse a un sistema en cualquiera de estas otras zonas / subdominios, o viceversa (en parte porque la transferencia de zona y la delegación no están configuradas correctamente para la mayoría de ellas) .
Nuestro DNS de producción está integrado con Active Directory, pero los sistemas de ingeniería deben aislarse de AD.
Estamos discutiendo formas de reorganizar DNS y consolidar todas estas entradas diferentes. Veo tres caminos diferentes que podemos tomar:
- Cree una nueva zona, es decir, 'dmn.eng'. Esto podría ser administrado por TI, utilizando nuestros servidores DNS o ingeniería utilizando sus servidores de nombres.
- Cree un nuevo delegado eng.example.com, consolide DNS de ingeniería en ese subdominio y deje que los ingenieros administren el servidor de nombres para el delegado.
- Cree un nuevo subdominio eng.example.com sin delegación y administre DNS para el subdominio nosotros mismos.
Estoy a favor de crear un subdominio delegado y dejar que los ingenieros tengan control total sobre su propia estructura DNS dentro de ese subdominio. La ventaja es que si su DNS no funciona, lo más probable es que no sea mi culpa;). Sin embargo, todavía existe cierta ambigüedad sobre la responsabilidad cuando algo no funciona y requerirá coordinación con la ingeniería para configurar, configurar y administrar.
Si no delegamos el subdominio, eso significa mucho más trabajo para la producción de TI que maneja DNS que no es de producción (que esencialmente ya hemos estado haciendo mucho). La ventaja es que tenemos control total sobre todos los DNS y cuando algo no funciona, no hay dudas sobre de quién es la responsabilidad de solucionarlo. También podemos agregar delegados, como geo.eng.example.com, para dar a la ingeniería más flexibilidad y control cuando lo necesiten.
No estoy seguro de la necesidad o los beneficios de crear una nueva zona, dmn.eng.
¿Cuáles son las mejores prácticas y recomendaciones de la industria para situaciones como esta? ¿Qué solución sería la más sencilla de implementar y proporcionaría una resolución de nombre perfecta entre ingeniería y producción? ¿Cuáles son algunos de los posibles beneficios o dificultades para cada solución que me puede faltar?
Para agregar un poco más de información, somos una empresa de fabricación bastante grande. Estos ingenieros trabajan en I + D, desarrollo y control de calidad. Los laboratorios con frecuencia tienen sus propias subredes o redes completas, DHCP, etc. En lo que respecta a la organización y la tecnología, son una especie de pequeño mundo.
Queremos mantener un cierto nivel de aislamiento de red para laboratorios de ingeniería y redes para proteger nuestro entorno de producción (consulte una pregunta anterior sobre ingenieros que agregaron servidores DHCP de ingeniería como servidores AD DHCP autorizados, eso no debería ser posible). Sin embargo, un usuario en una estación de trabajo en un laboratorio necesitará acceder a un recurso en nuestra red de producción, o un usuario en una estación de trabajo en nuestra red de producción necesitará conectarse a un sistema de laboratorio, y esto sucede con suficiente frecuencia para justificar un tipo -de DNS unificado.
Los delegados existentes ya tienen servidores DNS administrados por ingeniería, pero no hay comunicación entre los ingenieros en los diferentes laboratorios donde se configuran estos servidores, por lo que el problema más común es la resolución de nombres fallida entre subdominios. Dado que los ingenieros son dueños de esos servidores delegados, no puedo corregir las entradas NS para que hablen entre sí, de ahí la ventaja de que los DNS no delegados son propiedad exclusiva de TI. Pero administrar DNS para producción e ingeniería es un dolor de cabeza, especialmente porque la ingeniería puede realizar cambios de DNS a diario. Pero como BigHomie mencionó en su respuesta, esto probablemente significa que la ingeniería tendrá que contratar (o designar) un verdadero administrador de DNS; y esa persona y yo tendremos que conocernos bastante bien.
No necesariamente me gusta la idea de crear una nueva zona con un nombre de dominio o sufijo arbitrario de nivel superior, pero ya tenemos otras 5 zonas con nombres arbitrarios, por lo que consolidar en una sola sigue siendo una mejora. Sé que existen otras compañías que tienen zonas separadas de nivel superior para diferentes grupos en su organización, por lo que tengo curiosidad acerca de cuándo es apropiado y cuáles son las ventajas / desventajas de ese enfoque.
Para su información, solo he estado en esta compañía durante unos meses y el administrador anterior de AD / DNS dejó la compañía, por lo que no tengo nada que hacer referencia a por qué existe alguna de las estructuras DNS existentes.
Our production DNS is integrated with Active Directory, but engineering systems should be isolated from AD.Este comentario me hace preguntarme si honestamente debería considerar tener un bosque AD separado para la ingeniería.