Las mejoras de Windows Server 2008 R2 sobre la versión básica de BIND-DNS ayuda a ser al DNS más confiable y a tener una estrategia de resolución más robusta tanto para entornos Microsoft como No-Microsoft.
Quizás la más significativa de las características en la implementación de DNS en R2 sea que las zonas integradas de AD se almacenen en la partición de aplicación de AD. Para cada dominio en un bosque, una partición de aplicación separada se crea y se usa para almacenar los registros que existen en cada zona integrada de AD. Ya que esta partición no se incluye como parte del Catálogo global, las entradas del DNS no se incluyen como parte de la replicación de éste.
Con el concepto de partición de aplicación, la carga de replicación se ve reducida ahora mientras la información importante de la zona se delega a áreas de la red donde sea necesaria.
La configuración del DNS usando el asistente permite la creación automática de una zona DNS paso a paso. Esta característica es de agradecer, ya que facilita la creación de zonas, especialmente para AD.
En anteriores versiones del DNS de Microsoft existía cierta cuestión conocida y documentada, ‘la isla’, que se manifestaba por un DNS que se apuntaba a sí mismo como servidor DNS. Si la IP cambiaba el DNS actualizaba su propia entrada pero el resto de DNS del dominio eran incapaces de recuperar actualizaciones desde el servidor original ya que lo solicitaban a la IP anterior. Esto convertía al servidor en una isla. Microsoft lo arregló en Windows Server 2003 y posteriores. R2 primero cambia sus registros Host en un número suficiente de servidores DNS autoritativos dentro del DNS haciendo que la IP cambiada se replicase con éxito, eliminando el problema de ‘isla’. El resultado es que ya no se necesita apuntar un DNS raíz sobre otro para las actualizaciones, como se aconsejaba anteriormente.
En AD, todos los inicios de sesión y búsquedas de los clientes se redirigen a los servidores DC y Catálogos Global mediante referencias a los registros SRV del DNS. Estos registros se almacenaron en un subdominio del dominio AD que se conoce como _msdcs subdominio.
En R2, _msdcs es una zona separada en el DNS, como vemos en la imagen:
Esta zona, almacenada en la partición de aplicación, se replica a todos los DC que sean servidores DNS. Esta lista de registros SRV se movió principalmente para cumplir con las necesidades de sitios remotos. En Windows 2000, estos sitios remotos tenía que replicar el DNS completo para acceder a los registros de _msdcs, qué producía un mayor tiempo de replicación y una capacidad de respuesta reducida. Si delegamos los registros SRV a su propia zona, sólo ésta puede designarse para la replicación de DNS remotos, ganando tiempo en la replicación y obteniendo mayor capacidad de respuesta.
DNS y un entorno AD DS
DNS es inseparable de AD. De hecho ambos se confunden uno por otro con frecuencia, debido quizás a su estructura similar.
AD utiliza una estructura jerárquica basada en X.500 que se diseñó para mapearla dentro de la jerarquía DNS, de ahí las similitudes. Además, AD usa el DNS para todas las búsquedas internas, desde los inicios de sesión a las búsquedas en el catálogo global.
Problemas con DNS pueden suponer un desastre para un entorno de AD.Ya que todos, servidores y clientes, están constantemente realizando búsquedas de unos a otros, y un corte en la resolución de nombres afecta seriamente a la funcionalidad de AD. Por estas y otras razones, DNS redundante en AD es muy recomendable, aun en pequeños entornos de AD.
Las consideraciones de seguridad para la BD de DNS no deben darse por sentadas. Actualizaciones seguras para las zonas integradas-AD son altamente recomendadas, y mantener los servidores DHCP fuera de los DC también ayudan a mantener seguro el DNS. Además, limitar el acceso administrativo al DNS ayudará a reducir problemas de ‘monerías’ no autorizadas en el DNS.
AD DS se escribió especifícamente para ser capaz de coexistir y, de hecho, utilizar implementaciones DNS que no son de Microsoft siempre que sean compatibles con actualizaciones dinámicas y registros SRV. Por ejemplo, AD funcionará en versiones UNIX BIND 8.1.2 y superiores. Con esta idea en mente sin embargo, no deja de ser recomendable que una empresa con una inversión significativa en tecnologías de Microsoft considere tener el DNS para AD en un R2, ya que las mejoras en funcionalidad y seguridad es la mejor opción en estas situaciones.
En entornos que usen versiones antiguas de DNS no no pueden alojar a clientes AD en sus BD, AD DNS puede simplemente ser delegado a una zona separada en la que puede ser autoritativo. Los R2 pueden funcionar como simples reenvíadores en implementaciones foráneas de DNS para proporcionar resolución de recursos en la zona original.
Ciertas situaciones en AD requieren el uso de zonas secundarias para manejar resolución específica. En ciertos modelos de dominio donde árboles separados forman distintos espacios de nombres dentro de un mismo bosque, se necesitan zonas secundarias de cada raíz DNS en Windows 2000 para mantener una sincronización correcta del bosque. Ya que cada árbol en este modelo se compone de dominios independientes que pueden no tener privilegios de seguridad en los otros dominios, se necesitará un mecanismo en el lugar para permitir las búsquedas entre los dos árboles. La creación de zonas secundarias en cada entorno de DNS proporcionarán una solución. R2 dispone de la opción de replicar estos árboles separados a todos los DNS en el bosque, reduciendo la necesidad de las zonas secundarias. La replicación de zonas secundarias fuera del bosque es aun, algunas veces, necesarios sin embargo. El reenvío condicional y las zonas de rutas internas pueden también utilizarse en ciertos casos para obtener un resultado similar sin necesidad de replicación de los datos.
SRV y resolución de Sites
Todos los clientes de AD DS usan DNS para cualquier tipo de búsqueda basada en dominio. Inicios de sesión, por ejemplo, necesitan de una búsqueda dentro de AD para un SRV específico que indica la ubicación de los DC y Global Catalog. R2, como se ha dicho, divide la ubicación de los SRV dentro de zonas separadas, que se replican al resto de DCs que tienen DNS instalado.
Se crean subdominios para cada Site en esta zona; Indican que recursos están disponibles en quéllos Sites específicos. En dos palabras, si un SRV en un subdominio de un Site específico es incorrecto, u otro servidor de un Site distinto está en la lista, todos los clientes de ese Site están obligados a autentificarse en otros Sites. Esto es importante ya que un problema común es qué cuando los Sites se creaban antes se llenaban de servidores, un SRV desde la ubicación central se añade para este subdominio del Site en el DNS. Cuando se añade un nuevo servidor a estos Sites, sus SRV se unen a los otros SRV que se colocaron cuando se creó el Site. Estos registros no se eliminan automáticamente y ellos consecuentemente dirigen a los clientes a servidores a través de lentos enlaces WAN, y con ello hacen que los inicios de sesión sean lentos.
Además de los contenedores Site, la raíz de dichos contenedores contienen una lista de todos los DC en un dominio específico. Estas listas se usan para resolución cuando un servidor de Site no responde. Sí un DC de Site está caído, los clientes de forma aleatoria eligen un DC en este Site.
Zona GlobalNames
En algunos casos, no es conveniente el uso de nombre de dominio cualificado FQDN por los usuarios finales. Esto es especialmente cierto para los novatos o en el caso de nombres de dominio largos. Un usuario escribe una URL, http://intranet.r2.local y a veces es fácil equivocarse. WINS proporciona facilidad en esto, en que puede utilizarse etiquetas simples en su lugar. Esto permite que el usuario escriba sólo http://intranet para acceder al recurso.
Sin embargo, con la llegada de IPv6, WINS no será compatible con el nuevo direccionamiento. Hay otras ventajas de DNS sobre WINS, menor carga administrativa, repositorio único de resolución de nombres, seguridad y estándares abiertos.
R2 proporciona una característica que se introdujo en 2008 para tratar esto, la zona GlobalNames (GNZ). Esta zona proporciona una resolución de etiqueta simple via zona DNS, parecido a WINS. La zona es una zona de búsqueda directa normal, si bien es cierto que con un nombre especial (GlobalNames), y que se usa por el DNS de una manera especial. Si el DNS es incapaz de resolver una dirección en sus zonas locales, intentará resolver la etiqueta simple contra la zona GlobalNames.
GNZ ofrece la promesa, finalmente, de terminar con la resolución WINS y NetBIOS.
Si queremos configurar una zona GlobalNames:
- Administración del servidor
- Expandimos los Roles, Servidor DNS, nodo DNS, Servidor DNS.
- Seleccionamos el nodo de Zonas de búsqueda directa.
- Nueva Zona (clic derecho o desde Acción)
- Siguiente en la página de bienvenida.
- Seleccionamos Zona principal y marcamos la casilla de Almacenar la Zona en AD. Siguiente.
- Seleccionamos Para todos los servidores DNS que se ejecutan en controladores de dominio en este bosque, siguiente.
- Introducimos el nombre de la Zona, GlobalNames y siguiente.
- Dejamos la configuración predeterminada de actualizaciones dinámicas, siguiente.
- Finalizar para crear la zona.
- Abrimos una ventana de símbolo del sistema y ejecutamos el comando:
- dnscmd /config /EnableGlobalNamesSupport
- Debe recibirse el mensaje “Propiedad del Registro EnableGlobalNamesSupport restablecida correctamente”
El comando debe ejecutarse en cada DNS del que se espere que resuelva GlobalNames, a menos de que la zona se les replique ya.
Ahora la Zona GlobalNames está lista para responder consultas. Para cualquier servidor que necesite responder a una etiqueta simple, introducimos un registro CNAME en esta zona con el apropiado FQDN del recurso.
