DNS – Dominios y la Zona “_msdcs”

Estoy notando hace un tiempo que muchos administradores de Active Directory no tienen el conocimiento necesario respecto de la resolución de nombres DNS que hace la zona “_msdcs”

Aunque creo que a esta altura ya todos conocemos que el funcionamiento correcto de un ambiente Active Directory se basa en la resolución de nombres de DNS, este servicio no sólo es utilizado para la resolución de nombres, sino también para que las máquinas puedan encontrar qué equipos proveen determinados servicios, y en este caso específico veremos algunos de los de un ambiente de Dominio Active Directory

Problemas en los registros de esta zona, son los que provocan que clientes no se pueden unir al Dominio, errores en la replicación, fallas de autenticación, etc.

Haré sólo una breve descripción de los registros más importantes de esta zona y su utilidad

Para quien quiera ver con un poco más de detalle el funcionamiento de DNS, en este blog he hecho muchas notas al respecto, y anoto abajo algunos enlaces específicos:

Cómo funciona DNS – Parte 1 | WindowServer:
https://windowserver.wordpress.com/2011/05/07/cmo-funciona-dns-parte-1-2/

Cómo funciona DNS – Parte 2 | WindowServer:
https://windowserver.wordpress.com/2011/05/26/cmo-funciona-dns-parte-2/

Cómo Funciona DNS – Parte 3 – Integración con Active Directory | WindowServer:
https://windowserver.wordpress.com/2011/06/24/cmo-funciona-dns-parte-3-integracin-con-active-directory/

DNS: Delegación de Dominios | WindowServer:
https://windowserver.wordpress.com/2016/02/09/dns-delegacin-de-dominios/

DNS: Resolución de Nombres Mediante Zonas Secundarias | WindowServer:
https://windowserver.wordpress.com/2014/02/06/dns-resolucin-de-nombres-mediante-zonas-secundarias/

DNS: Resolución de Nombres Mediante Reenviadores Condicionales | WindowServer:
https://windowserver.wordpress.com/2014/02/11/dns-resolucin-de-nombres-mediante-reenviadores-condicionales/

DNS: Resolución de Nombres Mediante “Stub Zones” | WindowServer:
https://windowserver.wordpress.com/2014/02/18/dns-resolucin-de-nombres-mediante-stub-zones/

Además hay una serie de cinco notas mostrando prácticas de configuración que comienzan en el siguiente enlace

El Servicio DNS: Demostración y Prácticas de Funcionamiento (Nota 1) | WindowServer:
https://windowserver.wordpress.com/2017/02/21/el-servicio-dns-demostracin-y-prcticas-de-funcionamiento-nota-1/

El servicio DNS es fundamentalmente para el proceso llamado “Resolución de Nombres”, esto es, que se le pueda preguntar “¿Qué dirección IP tiene una máquina que se llama ‘así’?” pero no es lo único

También se puede usar para la llamada “Resolución inversa” que es para que conociendo la dirección IP, se pueda resolver el nombre de la máquina

Los primeros corresponden a los registros “A” para IPv4, y “AAAA” para IPv6, llamados también registros “Host”

Los segundos corresponden a los registro “PTR” o “Pointer”

Pero en esta ocasión nos referiremos a los registros de tipo SRV o “Service Locator” cuyo objetivo es poder resolver a través de DNS qué máquinas proveen determinado servicio en la red, siempre y cuando este servicio se registre en DNS

Los registros SRV, proveen información sólo del nombre de máquina, aunque no su dirección IP, para esto debe existir no sólo un registro “Host”, sino además en qué protocolo y puerto atiende el servicio, y además dos campos (“Priority” y Weight”) usados para distribuir la carga en los servicios en caso de existir más de una máquina que provea el servicio, y por supuesto el nombre del servicio

El uso del caracter “_” en los nombres es algo que se ha discutido mucho sobre si es aceptable o no, pero en el caso de Microsoft lo justifica como forma de diferenciar el protocolo y el servicio, como por ejemplo “LDAP” y “_ldap”. Hay varias RFCs respecto al tema

Aprovecho para aclarar a qué se refiere LDAP: es un protocolo estandarizado para acceder a directorios en general y son las siglas “Lightweight Directory Access Protocol”, que deriva de otro llamado DAP (“Directory Access Protocol”)

Resmiendo, luego de esta explicación y para que quede claro, los registros SRV sirven para identificar los nombres de máquinas que proveen determinado servicio en la red

El caso más fácil de ver en un ambiente de Dominio Active Directory, es que las máquinas clientes puedan conocer a través de DNS cuáles son los Controladores de Dominio, para poner sólo un ejemplo básico

Pero no es solamente ese ejemplo anterior, y para nombrar sólo algunos

• Cuáles son los Controladores de Dominio de un determinado Dominio, tanto en la red, como en el “Site”
• Cuáles de los Controladores de Dominio son “Catálogo Global”
• Qué máquina es “Emulador PDC”
• Qué otros Controladores de Dominio del propio Dominio existen para configurar la replicación entre los mismos
• Y como si lo anterior fuera poco, si se tiene un Bosque con más de un Dominio es necesario averiguar todo lo anterior, pero a través del Bosque de Dominios

Esto último, es de vital importancia por la relación que existe entre los Dominios de un Bosque, ya que los Dominios se deben poder comunicar entre sí y mantienen relaciones de confianza

Y toda esta importante información que permite responder a todos los pedidos antes nombrados está en la zona “_msdcs”, por lo tanto esta importante zona debe poder ser accedida a todas las máquinas del Bosque, y no sólo a las del propio Dominio

Y esto es lo que justifica que “_msdcs” sea una zona separada de la del Dominio. No era así en Windows Server 2000 y se pagó un alto “troubleshooting” para solucionar ese inconveniente. Con un poco de humor, personalmente yo la llamaba la “zona mágica” :)

Veamos un poco la configuración de la zona en una instalación simple que he hecho de un único Controlador de Dominio, en un Bosque de un único Dominio, y dejo a los lectores para que investiguen en su propio entorno

En las propiedades de la zona con el nombre de Dominio podemos ver que, dejando los valores por omisión, la misma está integrada en Active Directory permitiendo únicamente actualizaciones seguras, pero lo importante: se replica únicamente a todos los Controladores de Dominio con el servicio DNS en el propio Dominio

Y podemos observar en la siguiente captura de pantalla que la zona “_msdcs” está delegada, como si fuera a otro DNS, pero en realidad a sí mismo

En cambio, si vemos la configuración de la zona “_msdcs”, aunque tiene las mismas características de seguridad su ámbito de replicación es a todos los Controladores de Dominio con DNS en el Bosque

Reitero, la zona “domino.sufijo” se replica en el Dominio, en cambio la zona “_msdcs.dominio.sufijo” se replica en el Bosque. Y esto es así por la necesidad antes expresada. Para ser más claro, aunque los Controladores de Domino son de un Dominio, los Catálogo Global son del Bosque

Mostraré algunos registros típicos en esta zona. Recuerdo que corresponden a un único Dominio, con un único Controlador de Dominio, y sin haber configurado “Sites” por lo cual existe únicamente el “Default-First-Site-Name”

Los Controladores de Dominio se ubican preguntando qué máquinas proveen el servicio “_LDAP”, y la autenticación Kerberos

Comenzamos a abrir las “carpetas” de esta zona y podemos observar que existen los registros anteriores que indican qué máquinas proveen el servicio en el “Site”. Si se hubieran definidos varios «Sites» cada uno tendría su correspondiente «carpeta»

Si fuera el caso de una máquina que se va a unir al Dominio, esta no conoce en qué “Site” está, y por lo tanto preguntará sólo por los Controladores de Dominio (DC) del Dominio, y por lo tanto está el siguiente registro que no indica “Site”

También podemos ver los Controladores de Dominio de cada Dominio, si hubiera más de uno

Y además cuáles son los “Catálogo Global” (GC), tanto en el “Site” como en todo el Bosque

Y por último qué Controlador de Dominio tiene el “FSMO Role” “Emulador PDC” ya que esto es necesario por varios motivos, como son por ejemplo algunos: el encargado de sincronizar la fecha y hora del resto de las máquinas del Dominio, donde pone foco, por omisión, el editor de GPOs, recibir los cambios urgentes, etc.

Es importante aclarar que todos estos registros SRV los hace el servicio NETLOGON en cada Controlador de Dominio, así que uno de los comandos más utilizados cuando uno está “peleando” con esta zona es reiniciar el servicio, ya que “IPCONFIG /REGISTERDNS” sólo trabaja con los registros “A”, “AAAA” y “PTR”

 

Resumiendo, no pretende ser una descripción completa y exhaustiva de todos los registros pero creo que ayudará a comprender la importancia de esta zona y los errores que se pueden producir si no está adecuadamente configurada