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.Respuestas:
En el mundo de hoy, no recomiendo crear nuevas zonas con dominios arbitrarios de nivel superior , ya que podrían convertirse en "dns oficiales" en cualquier momento.
Personalmente, preferiría el escenario de delegación de subdominio, ya que parece ajustarse a lo que intentas hacer. (Consolidar pero dar control a la ingeniería)
Tal vez incluso pueda encontrar un front-end web para MS DNS donde la ingeniería podría agregar / eliminar registros, de modo que el servidor en sí todavía sea propiedad de TI de producción, y lo único que "administran" son las entradas DNS.
fuente
En primer lugar, asegúrese de poseer el dominio .tld que planea usar (mit.edu). Incluso si esto nunca se conecta a internet, ese no es el punto.
Hay enormes beneficios de tener una jerarquía de DNS que al menos un tanto coincide con la org. Solo he visto esto cuando hay alguien / personas para administrar ese departamento en términos de soporte de TI. Esto se refiere a tener zonas separadas para los fines de AD. Las direcciones web, etc. son un tema separado y esto no se aplicará a eso. No tengo ni conozco ninguna regla estricta y rápida para la jerarquía de DNS, creo que las necesidades de su organización lo dictarán. Algunas zonas pueden requerir un subdominio (eng.mit.edu) y otras no (hr.mit.edu, por ejemplo). Por supuesto, solo debe haber un dominio de nivel superior para la coherencia.
Dicho esto, ¿qué determina si un departamento necesita o no un subdominio o no? Si esto es para estaciones de trabajo, ¿tienen su propio soporte de TI o personas capaces de administrar dicho sistema? Si no, realmente no tiene sentido usar una zona dns para especificar que una máquina está en un determinado departamento, hay muchos otros métodos que harán bien el trabajo. Estas son solo preguntas que solo tendrá que hacerse.
Volvería a evaluar cada zona y determinaría
Si aún es relevante. ¿Hay servidores o estaciones de trabajo que todavía apuntan a algo en esa zona?
Quién administrará la nueva zona. No hace falta decir que la zona tendrá que migrarse a su nueva jerarquía, pero ¿simplemente implementa una dirección de reenvío / información de servidor de nombres para la zona, o administrará activamente la zona?
¿Qué sistemas están 'aislados' de AD? ¿No requerirán autenticación y / o administración de red? ¿Cuál es la razón para separarlos desde una perspectiva DNS? Para confirmar sus sospechas, se trata de la facilidad de administración. Si la ingeniería necesita que tanto la administración de DNS, que debe recibir a sí mismos un administrador de DNS.
Para agregar información basada en su actualización, personalmente también les daría su propio subdominio
eng.spacelysprockets.com
y subred. Debe ser cortafuegos del resto de la red con el tráfico apropiado permitido. Si quieren salir y creareng.eng.local
oeng.bikes
no puedes detenerlos, tampoco deberías estar obligado a apoyar eso *.Si juegan bien, use la subzona y decida que quieren separarse
lab.eng.spacelysprockets.com
y una parte de la subred, eso está en ellos. Probablemente debería ser una cortesía profesional informarle para que también pueda segmentar ese tráfico, pero no todos piensan así.Un nombre de dominio real para su infraestructura seriamente le daría una ventaja en la administración, debería considerarlo.
* En caso de que usted y tendrá que son dos cosas diferentes, pero estoy divagando.
fuente