Prácticas recomendadas para el asesoramiento de diseño del dominio de Active Directory (AD) contra el uso de un nombre de dominio registrado como el nombre de un dominio de AD. Entre las alternativas viables se incluyen el uso de un sufijo de DNS no público (. local o . LAN, por ejemplo) en el nombre de dominio de ad, o hacer que el dominio de ad sea un subdominio del dominio registrado (por ejemplo,Corp.domain.com).
Sin embargo, no siempre tendrá ninguna opción en el asunto; es posible que obtenga soporte para un dominio de AD que tenga el mismo nombre que el dominio registrado de la empresa, y es posible que la administración no desee cambiar el nombre. Esto se conoce como un escenario de DNS dividido (o de DNS dividida), en el cual hay dos espacios de nombres distintos DNS: el espacio de nombres interno que utiliza ad y el espacio de nombres externo que utiliza el registro de dominio público con el mismo nombre. Este escenario puede presentarles algunos retos únicos. Este artículo analiza algunos problemas comunes que surgen de un ambiente de DNS dividido y lo que se puede hacer para mitigarlos.
En todos los ejemplos que aparecen a continuación, el dominio de AD y el dominio registrado se denominan Domain.comy hay un sitio web de la empresa llamado www.domain.com.
Problema 1: Sitio web de la empresa alojado externamente inaccesible desde dentro de la oficina
Este es el problema más común en un ambiente de DNS dividido: no se puede acceder al sitio web de la empresa o a otro recurso de la empresa conectado a Internet, pero las máquinas que se encuentran fuera de la oficina no tienen problemas para llegar al sitio Web. El motivo de esto se puede mostrar mediante el análisis de lo que sucede cuando un usuario interno intenta navegar por el sitio web de la empresa:
El problema se produce debido a que un servidor de DNS que tiene una zona de búsqueda específica en su base de datos, la zona Domain.com en este ejemplo, no envía consultas para los registros de esa zona en ningún otro lugar. simplemente devuelve una respuesta "not found" si no hay ningún registro que coincida con una consulta determinada. En este ejemplo, hay otro servidor de DNS con el registro correcto: el servidor de DNS que aloja la zona Domain.com pública que pertenece al registrador de dominio, como es evidente por el hecho de que las máquinas que se encuentran fuera de la oficina pueden acceder al sitio Web. Sin embargo, las consultas desde máquinas internas nunca llegan a ese servidor.
La solución a este problema es simple: cree un registro de host denominado www en la zona Domain.com en el DC y concédale ese registro de la dirección IP del sitio Web. Las máquinas que consultan que DNS servidor reciben la respuesta correcta y podrán navegar en el sitio Web.
Problema 2: Sitio web público alojado internamente inaccesible desde dentro de la oficina
Esto podría considerarse una variación del problema 1 anterior. La diferencia en este caso es que el sitio web está alojado internamente, ya sea detrás de un firewall en la red interna de la empresa o en una DMZ. Se supone que es accesible para los usuarios internos y externos, pero los usuarios internos no pueden comunicarse con él, mientras que los usuarios externos no informan problemas.
El motivo del problema es similar al del problema 1, pero los usuarios internos en este caso pueden resolver correctamente el nombre del sitio web en su dirección IP pública. Sin embargo, aún no pueden acceder al sitio web debido a la forma en que se configura el firewall. Espera que los usuarios de la red interna accedan al sitio web utilizando su dirección privada en lugar de su dirección pública.
Nuevamente, hay una solución simple: crear un registro de host denominado www en la zona de Domain.com en el DC, pero esta vez le da al registro la dirección IP privada del sitio Web. Las máquinas internas resuelven el nombre del sitio web a esa dirección privada, mientras que las máquinas externas continúan resolviendo el nombre a la dirección pública del sitio Web.
Problema 3: El sitio web se carga incompletamente o aún no se carga después de que se realizan
los cambios anteriores Esto puede ocurrir si el código del sitio web redirige los exploradores de www.domain.com a Domain.com o si los vínculos internos hacen referencia al sitio como Domain.com en lugar de www.domain.com. Se observan los mismos síntomas en las máquinas internas si el site se aloja internamente o externamente:
El problema en este caso es un poco más complejo. Para que las máquinas puedan resolver Domain.com en una dirección IP, debe haber un registro de host en blanco en la zona Domain.com en DNS. El nombre de este registro se muestra como (igual que la carpeta principal) en la consola de DNS de Windows. Sin embargo, en este caso hay un problema: AD utiliza registros de host en blanco en la zona Domain.com para representar DC para el dominio Domain.com . Los miembros del dominio utilizan esos registros cuando localizan un DC para la autenticación y, si hay registros de host en blanco adicionales en la zona de Domain.com , pueden producirse retrasos o problemas de autenticación.
Por el motivo anterior, este problema no se puede resolver únicamente en DNS. La creación de un registro de host en blanco con la dirección IP del sitio web solo resuelve intermitentemente el problema de acceso al sitio web para los usuarios internos, ya que ya existen otros registros de hosts en blanco con las direcciones IP de los DC en el dominio, y hacerlo provoca problemas de autenticación de dominio.
La manera más simple de resolver este problema es modificar el código del sitio web para eliminar el redireccionamiento o reparar los vínculos internos de modo que todo se refiere al site como www.domain.com en lugar de Domain.com. Si no es posible modificar el código, la única opción para resolver el problema es cambiar el nombre del dominio de AD. Esto puede ser una tarea compleja, según el tamaño y la complejidad del ambiente.