As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Modernização da zona DNS `_msdcs` A modernização de uma `_msdcs` zona DNS é um pré-requisito obrigatório antes da criação do diretório Hybrid AD. Em ambientes modernos do Active Directory, `_msdcs.` é criado como uma zona replicada separada em toda a floresta armazenada na partição do ForestDnsZones aplicativo. Em ambientes legados originalmente criados no Windows NT 4.0 ou no Windows 2000 (e posteriormente atualizados), nunca `_msdcs` foi separado; ele existe simplesmente como um subdomínio padrão (subpasta) diretamente dentro do arquivo de zona do domínio pai. Quando um novo controlador de domínio é promovido com o DNS instalado, seu processo de instalação procura a partição dedicada do `_msdcs.` aplicativo. Como ele não encontra uma zona autônoma, ele cria automaticamente uma nova `_msdcs` zona em branco localmente e reivindica autoridade sobre esse namespace. Isso impede completamente que o novo DC leia os registros do subdomínio legado na zona principal e atualiza a delegação do NS para apontar para si mesma. O resultado é um conflito arquitetônico. Todos os clientes associados ao domínio agora são referenciados a um DC que tem uma `_msdcs` zona vazia, enquanto os registros reais do localizador de DC (`_ldap._tcp.dc._msdcs`,, registros do Catálogo Global`_kerberos._tcp.dc._msdcs`, CNAMEs do DC GUID) permanecem isolados no antigo subdomínio da zona principal, onde nenhum cliente pode acessá-los. Isso interrompe a autenticação Kerberos, a descoberta do LDAP e a localização do DC com reconhecimento do site em toda a floresta. ## Design de zona `_msdcs` antigo versus moderno Legado (subdomínio delegado) Padrão no Windows Server 2000, 2003, 2008 e 2008 R2. Nesse design, `_msdcs` existe como um subdomínio delegado na zona principal. Os registros NS na zona principal apontam para DCs específicos como autoritativos para o namespace. `_msdcs` Moderno (zona autônoma) Padrão no Windows Server 2012 e versões posteriores. Nesse design, `_msdcs.` existe como sua própria AD-integrated zona, replicada para todos os DCs na floresta por meio da partição do ForestDnsZones aplicativo. Todos os DCs são autorizados e podem read/write gravar diretamente. ## Como identificar o design da `zona _msdcs` Você pode identificar o design `_msdcs` da sua zona executando o seguinte em qualquer controlador de domínio: 1. **Liste todas as zonas DNS e procure`_msdcs`:** ``` Get-DnsServerZone | Where-Object { $_.ZoneName -like "*_msdcs*" } ``` **Design moderno (nenhuma ação é necessária)** — você verá uma `_msdcs.` lista como zona primária: ``` ZoneName ZoneType IsAutoCreated IsDsIntegrated IsReverseLookupZone IsSigned -------- -------- ------------- -------------- ------------------- -------- _msdcs.premier.local Primary False True False False ``` **Design antigo (conversão necessária)** — NÃO `_msdcs.` aparecerá na lista de zonas. Em vez disso, `_msdcs` existe somente como um subdomínio delegado na sua zona florestal. Você pode confirmar isso verificando os registros NS da delegação: ``` Get-DnsServerResourceRecord -ZoneName "" -Name "_msdcs" -RRType NS ``` Se isso retornar registros NS, seu ambiente usará o design de subdomínio delegado legado. 1. **Validação adicional — confirme o tipo de zona:** ``` # This will succeed on modern design Get-DnsServerZone -Name "_msdcs." # If you get an error like "Zone _msdcs. was not found", you have the legacy design ``` ## `Como modernizar a zona DNS _msdcs` Essas etapas devem ser executadas antes de iniciar a criação do diretório AWS Managed Microsoft AD Hybrid. Todas as etapas são executadas em controladores de domínio autogerenciados existentes com acesso ao Gerenciador de DNS com administrador de domínio e privilégios. DnsAdmins 1. **Crie a zona autônoma `_msdcs`** Em um controlador de domínio autogerenciado existente: ``` dnscmd localhost /ZoneAdd "_msdcs." /DsPrimary /dp /forest ``` Isso é criado `_msdcs.` como uma AD-integrated zona dedicada com escopo de Forest-wide replicação. Todos os DCs na floresta receberão uma cópia por meio da ForestDnsZones partição. Aguarde a propagação da replicação do AD: ``` repadmin /syncall /AeD ``` Verifique se a zona existe (executada em vários DCs): ``` Get-DnsServerZone -Name "_msdcs." ``` 1. **Remova a delegação antiga da zona principal** O antigo nó do `_msdcs` subdomínio e seus registros ainda existem na zona principal. Eles devem ser removidos para que as consultas de DNS sejam atendidas exclusivamente da nova zona autônoma. ``` # Remove the _msdcs subtree (NS delegation + all child records) from the parent zone dnscmd localhost /NodeDelete _msdcs /tree /f ``` **Importante** Execute essa etapa somente após confirmar que a zona autônoma foi criada com êxito na Etapa 1. Se você pular a Etapa 1, a exclusão dos registros antigos causará uma interrupção imediata. 1. **Forçar todos os DCs a registrar novamente os registros SRV** Com o subdomínio antigo removido e a nova zona autônoma estabelecida, todos os DCs devem registrar novamente seus registros localizadores na nova zona. Execute o seguinte em cada controlador de domínio local: ``` # 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 ``` 1. **Verificar** Aguarde de 5 a 10 minutos pela replicação e, em seguida, verifique: Confirme os registros preenchidos na nova zona autônoma: ``` Get-DnsServerResourceRecord -ZoneName "_msdcs." -RRType SRV ``` Você deve ver`_ldap._tcp.dc`,, `_kerberos._tcp.dc``_ldap._tcp.gc`, e registros específicos do site para todos os DCs locais. Confirme se a resolução de DNS funciona de ponta a ponta: ``` Resolve-DnsName "_ldap._tcp.dc._msdcs." -Type SRV Resolve-DnsName "_kerberos._tcp.dc._msdcs." -Type SRV ``` Todos os DCs locais devem aparecer nos resultados. Confirme se a delegação antiga saiu da zona principal: ``` Get-DnsServerResourceRecord -ZoneName "" -Name "_msdcs" -RRType NS -ErrorAction SilentlyContinue ``` Isso não deve retornar nada. Para obter mais informações sobre a modernização de `_msdcs` zonas DNS, consulte [Como dividir e migrar registros DNS de domínio secundário para uma zona DNS dedicada no](https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/how-to-split-and-migrate-child-domain-dns-records-to-a-dedicated-dns-zone/255534) site do blog Microsoft Core Infrastructure and Security. ## Solução de problemas Se a nova zona autônoma permanecer vazia após a Etapa 3: O Netlogon não pode se registrar novamente se acreditar que os registros já existem. Forçar um novo registro limpo: ``` # 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 ``` Se os registros ainda não aparecerem, crie manualmente os registros críticos usando os valores da zona principal antiga (disponíveis no backup ou em outros DCs que os armazenaram em cache): ``` # Example: SRV record for LDAP DC locator Add-DnsServerResourceRecord -ZoneName "_msdcs." -Name "_ldap._tcp.dc" -Srv -DomainName "dc1." -Priority 0 -Weight 100 -Port 389 # Example: SRV record for Kerberos DC locator Add-DnsServerResourceRecord -ZoneName "_msdcs." -Name "_kerberos._tcp.dc" -Srv -DomainName "dc1." -Priority 0 -Weight 100 -Port 88 ``` Se os aplicativos continuarem falhando após a conversão: Limpe os caches de DNS nos servidores de aplicativos e máquinas clientes afetados: ``` ipconfig /flushdns ``` As entradas negativas do cache DNS (do período de interrupção) podem persistir por até 900 segundos (15 minutos) antes de expirar.