View a markdown version of this page

Modernización de la zona DNS _msdcs - AWS Directory Service

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Modernización de la zona DNS _msdcs

La modernización de una _msdcs zona DNS es un requisito previo obligatorio antes de crear un directorio de AD híbrido. En los entornos modernos de Active Directory, _msdcs.<ForestRoot> se crea como una zona replicada independiente que abarca todo el bosque y se almacena en la partición de la aplicación. ForestDnsZones En los entornos heredados, creados originalmente en Windows NT 4.0 o Windows 2000 (y posteriormente actualizados), nunca _msdcs se separaba; simplemente existía como un subdominio estándar (subcarpeta) directamente dentro del archivo de zona del dominio principal.

Cuando se promociona un nuevo controlador de dominio con el DNS instalado, su proceso de instalación busca la partición de _msdcs.<ForestRoot> aplicación dedicada. Como no encuentra una zona independiente, crea automáticamente una nueva _msdcs zona vacía a nivel local y reclama la autoridad sobre ese espacio de nombres. Esto impide por completo que el nuevo DC lea los registros de subdominios heredados de la zona principal y actualiza la delegación NS para que apunte a sí misma.

El resultado es un conflicto arquitectónico. Todos los clientes unidos a un dominio ahora se denominan DC con una _msdcs zona vacía, mientras que los registros localizadores de DC reales (, registros del catálogo global _ldap._tcp.dc._msdcs_kerberos._tcp.dc._msdcs, CNAME GUID de DC) permanecen bloqueados en el antiguo subdominio de la zona principal, donde ningún cliente puede acceder a ellos. Esto interrumpe la autenticación de Kerberos, la detección de LDAP y la ubicación de los DC con reconocimiento del sitio en todo el bosque.

El diseño de zonas _msdcs tradicional y el moderno

Legacy (subdominio delegado)

Predeterminado en Windows Server 2000, 2003, 2008 y 2008 R2. En este diseño, _msdcs existe como un subdominio delegado en la zona principal. Los registros NS de la zona principal apuntan a DC específicos como autoritativos para el espacio de nombres. _msdcs

Moderno (zona independiente)

Predeterminado en Windows Server 2012 y versiones posteriores. En este diseño, _msdcs.<forest> existe como su propia AD-integrated zona, replicada en todos los DC del bosque a través de la partición de la ForestDnsZones aplicación. Todos los DC tienen autoridad y pueden grabar directamente. read/write

¿Cómo identificar el diseño de zona de _msdcs?

Puede identificar el diseño de su _msdcs zona ejecutando lo siguiente en cualquier controlador de dominio:

  1. Enumere todas las zonas de DNS y busque_msdcs:

    Get-DnsServerZone | Where-Object { $_.ZoneName -like "*_msdcs*" }

    Diseño moderno (no es necesario realizar ninguna acción): aparecerá _msdcs.<forest-name> en la lista como zona principal:

    ZoneName ZoneType IsAutoCreated IsDsIntegrated IsReverseLookupZone IsSigned -------- -------- ------------- -------------- ------------------- -------- _msdcs.premier.local Primary False True False False

    Diseño antiguo (requiere conversión): NO _msdcs.<forest-name> aparecerá en la lista de zonas. En su lugar, solo _msdcs existe como un subdominio delegado en su zona forestal. Puede confirmarlo comprobando los registros NS de la delegación:

    Get-DnsServerResourceRecord -ZoneName "<forest-name>" -Name "_msdcs" -RRType NS

    Si esto devuelve registros NS, su entorno utiliza el diseño de subdominio delegado heredado.

  2. Validación adicional: confirme el tipo de zona:

    # This will succeed on modern design Get-DnsServerZone -Name "_msdcs.<forest-name>" # If you get an error like "Zone _msdcs.<forest-name> was not found", you have the legacy design

Cómo modernizar la zona _msdcs de DNS

Estos pasos deben realizarse antes de iniciar la creación del directorio híbrido AWS administrado de Microsoft AD. Todos los pasos se llevan a cabo en los controladores de dominio autogestionados existentes con acceso al administrador de DNS con privilegios y DnsAdmins administrador de dominio.

  1. Cree la zona independiente _msdcs

    En un controlador de dominio autogestionado existente:

    dnscmd localhost /ZoneAdd "_msdcs.<forest-name>" /DsPrimary /dp /forest

    Esto se crea _msdcs.<forest-name> como una AD-integrated zona dedicada con alcance de Forest-wide replicación. Todos los DC del bosque recibirán una copia a través de la ForestDnsZones partición.

    Espere a que se propague la replicación de AD:

    repadmin /syncall /AeD

    Compruebe que la zona existe (ejecute en varios centros de distribución):

    Get-DnsServerZone -Name "_msdcs.<forest-name>"
  2. Elimine la delegación anterior de la zona principal

    El nodo de _msdcs subdominio anterior y sus registros siguen existiendo en la zona principal. Deben eliminarse para que las consultas de DNS se atiendan exclusivamente desde la nueva zona independiente.

    # Remove the _msdcs subtree (NS delegation + all child records) from the parent zone dnscmd localhost /NodeDelete <forest-name> _msdcs /tree /f
    importante

    Realice este paso únicamente después de confirmar que la zona independiente se creó correctamente en el paso 1. Si omite el paso 1, la eliminación de los registros antiguos provocará una interrupción inmediata.

  3. Obligue a todos los centros de distribución a volver a registrar los registros SRV

    Tras eliminar el subdominio anterior y establecer la nueva zona independiente, todos los centros de distribución deben volver a registrar sus registros de localización en la nueva zona.

    Ejecute lo siguiente en todos los controladores de dominio locales:

    # Flush DNS cache ipconfig /flushdns # Restart Netlogon — this triggers re-registration of all SRV, CNAME, and A records net stop netlogon net start netlogon # Force host record registration ipconfig /registerdns
  4. Verificar

    Espere de 5 a 10 minutos para que se realice la replicación y, a continuación, compruebe:

    Confirme los registros rellenados en la nueva zona independiente:

    Get-DnsServerResourceRecord -ZoneName "_msdcs.<forest-name>" -RRType SRV

    Debería ver _ldap._tcp.dc _kerberos._tcp.dc_ldap._tcp.gc, y los registros específicos del sitio para todos los centros de distribución locales.

    Confirme que la resolución de DNS funcione de principio a fin:

    Resolve-DnsName "_ldap._tcp.dc._msdcs.<forest-name>" -Type SRV Resolve-DnsName "_kerberos._tcp.dc._msdcs.<forest-name>" -Type SRV

    Todos los DC locales deberían aparecer en los resultados.

    Confirme que la antigua delegación ha desaparecido de la zona principal:

    Get-DnsServerResourceRecord -ZoneName "<forest-name>" -Name "_msdcs" -RRType NS -ErrorAction SilentlyContinue

    Esto no debería devolver nada.

    Para obtener más información sobre la modernización de _msdcs las zonas DNS, consulte Cómo dividir y migrar los registros DNS de dominios secundarios a una zona DNS dedicada en el sitio web del blog Microsoft Core Infrastructure and Security.

Resolución de problemas

Si la nueva zona independiente permanece vacía después del paso 3:

Es posible que Netlogon no se vuelva a registrar si cree que ya existen registros. Forzar una reinscripción limpia:

# Delete the Netlogon DNS registration cache Remove-Item "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DnsAvoidRegisterRecords" -ErrorAction SilentlyContinue # Restart Netlogon again net stop netlogon net start netlogon

Si los registros siguen sin aparecer, cree manualmente los registros críticos utilizando los valores de la zona principal anterior (disponibles en la copia de seguridad o en otros centros de control que los almacenaron en caché):

# Example: SRV record for LDAP DC locator Add-DnsServerResourceRecord -ZoneName "_msdcs.<forest-name>" -Name "_ldap._tcp.dc" -Srv -DomainName "dc1.<forest-name>" -Priority 0 -Weight 100 -Port 389 # Example: SRV record for Kerberos DC locator Add-DnsServerResourceRecord -ZoneName "_msdcs.<forest-name>" -Name "_kerberos._tcp.dc" -Srv -DomainName "dc1.<forest-name>" -Priority 0 -Weight 100 -Port 88

Si las aplicaciones siguen fallando después de la conversión:

Vacíe las cachés de DNS de los servidores de aplicaciones y máquinas cliente afectados:

ipconfig /flushdns

Las entradas negativas de la caché de DNS (del período de interrupción) pueden persistir hasta 900 segundos (15 minutos) antes de caducar.