15 votos

Debe de ingeniería tienen su propia zona DNS, delegado, o un subdominio?

Hemos principal de nuestra organización de dominio (con ANUNCIOS) example.com. En el pasado, los anteriores administradores han creado muchas otras zonas - como dmn.com, lab.example.com, dmn-geo.com etc - así como los subdominios y todos los delegados, los que son para diferentes grupos de ingeniería. Nuestros DNS en este momento es un poco de un desastre. Y, por supuesto, esto causa problemas cuando alguien en una estación de trabajo en example.com debe conectarse a un sistema en cualquiera de estas otras zonas/subdominios, o viceversa (parcialmente debido a que la zona de transferencia y delegación no está configurado correctamente para la mayoría de ellos).

Nuestro DNS de producción está integrado con Active Directory, pero de ingeniería de sistemas debe estar aislado de AD.

Estamos hablando de formas de reorganización de DNS y la consolidación de todos estos diferentes entradas. Veo tres diferentes caminos que podemos tomar:

  • Crear una nueva zona de decir 'dmn.esp'. Esta bien podría ser gestionados por ELLA, usando nuestros servidores de DNS o de ingeniería en uso de sus servidores de nombres.
  • Crear un nuevo delegado eng.example.com, consolidar la ingeniería de DNS en ese subdominio, y dejar que los ingenieros de administrar el servidor de nombres para el delegado.
  • Crear un nuevo subdominio eng.example.com sin delegación y gestionar el DNS para el subdominio de nosotros mismos.

Estoy a favor de la creación de un subdominio delegado y dejar que los ingenieros tienen control total sobre sus propios DNS estructura dentro de ese subdominio. La ventaja es que si el DNS no funciona, lo más probable es que no es mi culpa ;). Sin embargo, todavía hay cierta ambigüedad acerca de la responsabilidad cuando algo no funciona, y requerirá de la coordinación con el departamento de ingeniería para establecer, configurar y administrar.

Si no nos delegado del subdominio, que significa mucho más trabajo para la producción ES el manejo de la no-producción de DNS (que esencialmente hemos de hacer un montón de ya). La ventaja es que tenemos control total sobre todos los DNS y cuando algo no funciona no hay duda acerca de quién es la responsabilidad de solucionarlo. También podemos agregar a los delegados, tales como geo.eng.example.com para dar de ingeniería más flexibilidad y control cuando la necesitan.

Estoy muy seguro acerca de la necesidad o de los beneficios de la creación de una nueva zona, dmn.ing.

Entonces, ¿cuáles son las mejores prácticas de la industria y las recomendaciones para este tipo de situaciones? ¿Qué solución sería la más sencilla de implementar y dar transparente de resolución de nombres entre ingeniería y producción? ¿Cuáles son algunos de los posibles beneficios o peligros a cada solución que me puede estar faltando?


Para agregar un poco más de información, estamos bastante grande de la fabricación de la empresa. Estos ingenieros trabajan en I + D, de Desarrollo y de control de calidad. Los laboratorios frecuentemente tienen sus propias subredes o el conjunto de las redes, DHCP, etc. En lo que respecta a la organización y a la tecnología, que son una especie de su propio pequeño mundo.

Queremos mantener un cierto nivel de aislamiento de la red de laboratorios de ingeniería y redes con el fin de proteger nuestro entorno de producción (se hace referencia a una pregunta anterior respecto a los ingenieros, que añadió ingeniería de servidores DHCP como autoridad AD servidores DHCP - que no debería ser capaz de suceder). Sin embargo, un usuario en una estación de trabajo en un laboratorio tendrá acceso a un recurso en nuestra red de producción, o de un usuario en una estación de trabajo en nuestra red de producción se necesita para conectarse a un laboratorio de sistema, y esto sucede con bastante frecuencia para justificar una especie de unificado de DNS.

Los delegados existentes ya han DNS servidores gestionados por la ingeniería, pero no hay comunicación entre los ingenieros en los diferentes laboratorios donde estos servidores se configuran, por lo que el problema más común es error de la resolución de nombres entre los subdominios. Desde que los ingenieros de la propia aquellos delegado servidores, no puedo corregir el NS entradas para llegar a ellos hablando el uno al otro, de ahí la ventaja de no-DNS delegado propiedad exclusiva de ÉSTA. Pero la administración de DNS para la producción y la ingeniería es un dolor de cabeza, especialmente a medida que la ingeniería puede hacer cambios de DNS sobre una base diaria. Pero como BigHomie mencionó en su respuesta, esto probablemente significa que la ingeniería tendrán que contratar (o designado) un verdadero administrador de DNS; y que la persona y voy a tener que ser bastante familiarizado.

Yo no necesariamente me gusta la idea de la creación de una nueva zona con arbitraria de un dominio de nivel superior nombre o sufijo, pero ya tenemos 5 otras zonas con nombres arbitrarios para consolidar en una sola es todavía una mejora. Sé que otras empresas existentes que no han separado de nivel superior en zonas para los diferentes grupos en su organización, así que tengo curiosidad acerca de cuándo es apropiado y lo que las ventajas/desventajas de este enfoque son.

FYI, sólo he estado en esta empresa por un par de meses y la anterior AD/administrador de DNS a la izquierda de la empresa, por lo que no tienen nada que haga referencia a ¿por qué ninguno de los DNS existente existe una estructura.

14voto

MichelZ Puntos 8960

En el mundo de hoy, no recomiendo la creación de nuevas zonas con diferentes dominios de nivel superior, ya que estos podrían hacer en "oficial dns" en cualquier punto en el tiempo.

Yo, personalmente, estaría a favor de la subdominio escenario de delegación, como parece acertado lo que intenta hacer. (Consolidar, pero dar el control a la ingeniería)

Tal vez incluso se puede encontrar en la web front-end para MS DNS donde la ingeniería podría añadir/eliminar registros, por lo que el servidor sigue siendo propiedad de la producción, y la única cosa "que" administrar es a las entradas DNS.

14voto

BigHomie Puntos 3983

Primero y ante todo, asegúrese de que usted propio dominio.tld usted planea usar (mit.edu). Aunque esto nunca se conecta a internet, que no es el punto.

Hay enormes beneficios de tener una jerarquía de dns que al menos un poco los partidos de la org. Sólo he visto a este hecho cuando hay algún/a las personas a gestionar ese departamento en términos de soporte de TI. Esto es en lo que respecta a tener zonas separadas para los propósitos de la EA. Direcciones Web y etc, son un tema aparte y esto no aplica a eso. No tengo ni conozco a ningún reglas duras y rápidas para la jerarquía de dns, yo creo que su org necesidades que dictan. Algunas zonas pueden requerir un subdominio (eng.mit.edu) y otros no (hr.mit.edu, por ejemplo). Por supuesto, no debe ser sólo un dominio de nivel superior para la consistencia.

Dicho esto, lo que determina si es o no un departamento necesita un subdominio o no? Si esto es para estaciones de trabajo, tienen su propio soporte de TI, o de personas capaces de gestionar dicho sistema? Si no, realmente no hay punto en el uso de una zona dns para especificar que una máquina está en un determinado departamento, hay muchos otros métodos que va a hacer el trabajo igual de bien. Estos son sólo preguntas que usted sólo tendrá que preguntarse a sí mismo.

Me gustaría volver a evaluar cada zona y determinar

  1. Si es aún relevante. Hay servidores o estaciones de trabajo sigue apuntando a nada en esa zona?

  2. Quién será la gestión de la nueva zona. Va sin decir que la zona tendrá que ser migrados a la nueva jerarquía, pero no acaba de implementar una dirección de reenvío/información del servidor para la zona, o la gestión activa de la zona?

¿Qué son los sistemas "aislados" de AD? Estos no requieren autenticación de red y/o de gestión? ¿Cuál es la razón para que los separa de un DNS perspectiva? Para confirmar sus sospechas, es todo acerca de la facilidad de gestión. Si la ingeniería de las necesidades que tanto la administración de dns, deben darse a sí mismos un administrador de DNS.

Para agregar información basada en su actualización, a continuación, yo personalmente les daría su propio subdominio, eng.spacelysprockets.com, y la subred así. Debe estar detrás de un firewall desde el resto de la red con el tráfico correspondientes. Si quieren ir y crear eng.eng.local o eng.bikes que no puede dejar de ellos, ni debe ser obligados a apoyar que*.

Si se juega bonito el uso de la subzona y deciden que quieren romper lab.eng.spacelysprockets.com y una parte de la subred, que está en ellos. Probablemente debe ser de cortesía profesional para hacerle saber lo que usted puede segmento que el tráfico así, pero no todos piensan de esa manera.

Un nombre de dominio real de su infraestructura seriamente en darle una ventaja en la gestión, usted debe considerar.

*En caso de que usted y se que son dos cosas diferentes, pero estoy divagando.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X