Situación:
- Tenemos un sitio de DR que necesita ser probado
Hay una combinación de hosts de Linux y Windows en el sitio de DR. En caso de desastre, si el SERVIDOR en el sitio de producción no está disponible, SERVER_DR en DR se activa y se une al mismo dominio de Windows. Esto se hace de esta manera en caso de que el sitio principal esté no está disponible y no queremos eliminar el registro original del SERVIDOR del formulario AD.
El problema que estoy tratando de resolver es una resolución de nombre en el sitio DR. Los procesos y scripts utilizan el nombre DNS SERVIDOR, por lo que en el sitio DR las solicitudes al SERVIDOR deben traducirse a SERVER_DR. No tenemos acceso para hacer nada en el DNS de Windows.
Mi idea es usar BIND para resolver este problema. Los hosts en DR deberían poder autenticarse con AD. El hecho de que no necesiten acceder a nada más fuera del sitio de DR en el dominio de Windows debería simplificar el problema.
Los servicios a los que deben acceder los hosts de DR son en su mayoría servidores SQL y de intercambio de archivos. Creo que los servidores SQL pueden ser un problema aquí, ya que usan SPN.
Esto me da una idea de usar BIND para nuestra zona.domain.com mantenida por BIND en el sitio de DR; sin embargo, puedo ver un posible problema cuando los hosts de Windows DR necesitan autenticarse contra AD, ya que necesitan usar registros sin marcar si no recuerdo mal. No podemos delegar zonas de AD debido a las razones que mencioné anteriormente.
¿Vale la pena resolver este problema? Uno de mis colegas sugirió usar un archivo hosts para cada host DR de Windows. Sin embargo, parece bastante feo, no hay muchos y es posible que desperdicie mi tiempo configurando BIND.
Respuesta1
Los archivos HOSTS no harán que la autenticación AD funcione correctamente. La autenticación AD necesita los RR SRV que solo un servidor DNS puede proporcionar (ya que un archivo HOSTS es solo un RR A).
Eche un vistazo aquí a: una respuesta anterior que di sobre el uso de BIND para admitir AD:Uso de BIND9 y DHCPD para admitir un dominio de Windows
Tendrá problemas con algún software que funcione correctamente si los nombres de la computadora de su servidor Windows son diferentes. Simplemente tratar de "alias" el nombre que no es DR a un servidor Windows con un conjunto de nombres de computadora diferente funcionará para algunos protocolos, pero otros fracasarán (los SPN en AD, por ejemplo, están "vinculados" a la computadora nombres).
No me queda claro por qué no se puede utilizar el DNS de Windows en el sitio de recuperación ante desastres. Creo que podría activar un servidor DNS de Windows y, en el caso de que sea peor, delegar la zona _msdcs.domain.com al servidor DNS de Windows en la infraestructura BIND existente.
Supongo que necesitaría entender un poco más acerca de lo que estás tratando de lograr y por qué tienes las restricciones que tienes, pero en general estaría trabajando para hacer que el entorno de recuperación ante desastres sea lo más cercano posible al entorno de producción, para que que tiene una cantidad mínima de trabajo por hacer al trasladar las operaciones al entorno de recuperación ante desastres.
Respuesta2
No existe una manera fácil de hacer que los hosts en el sitio DR resuelvan "SERVIDOR" en la dirección IP de SERVER_DR y al mismo tiempo mantener funcionando todo el DNS de AD. Lo que hay que hacer es utilizar un alias para todas las referencias del servidor.
Mi enfoque habitual es crear un nuevo dominio (por ejemplo, midominio.sitio) que no esté integrado en AD. Esto le permite utilizar archivos de zona separados y diferentes para diferentes servidores DNS. Luego cambie todas las referencias a sus servidores a server.mydomain.site. Esto permite a sus usuarios utilizar un único nombre de servidor que resuelva lo que sea apropiado para el sitio.
NB para que el uso compartido de archivos de Windows funcione con un alias CNAME, debe agregar una entrada de registro para el servicio LanManServer. Verhttp://support.microsoft.com/kb/281308para detalles. Esto funciona en W2k8, así como en 2k y 2k3.
Le recomiendo encarecidamente que utilice el DNS de Windows para alojar el dominio .site. Si realmente no puede convencer a sus administradores de sistemas para que le ayuden, puede utilizar BIND y configurar los servidores DNS de Windows como reenviadores. Luego, BIND resolvería el dominio .site mientras que Windows se usaría para todos los demás dominios, incluido el dominio AD. Sin embargo, esto hace que el mantenimiento sea más complejo, por lo que lo evitaría si es posible.
J.R.
PD sobre "NB, el uso compartido de archivos de Windows funciona con un alias CNAME"
El objetivo de utilizar el alias es que puede explorar recursos compartidos o asignar unidades de red utilizando nombres UNC como \myserver.mydomain.site\share, donde el nombre "myserver.mydomain.site" se resuelve en la dirección IP de su servidor de destino, y puede resolverse en diferentes direcciones IP en diferentes sitios. De forma predeterminada, el servicio LanManServer no permitirá la navegación a menos que el nombre del servidor coincida con el nombre real del servidor y recibirá un mensaje de error parecido a "Existe un nombre duplicado en la red". Esto se hace para aumentar la seguridad. El artículo de KB que mencioné describe cómo desactivar la verificación de nombres para que funcionen nombres UNC como el anterior.
En realidad, uso este truco de forma rutinaria porque facilita mover archivos compartidos a diferentes servidores. No reemplaza a DFS pero puede ser un truco útil.