DHCP e DNS entre domínios: por que a atualização dinâmica falha (filho ⇄ pai) e como corrigir no Active Directory

Atualizações dinâmicas de DNS falhando entre um domínio filho e o domínio pai no Active Directory? Este guia mostra a causa real (permissões/autoridade) e a correção definitiva com credenciais de DDNS no DHCP, delegação de ACLs nas zonas e validações práticas.

Índice

Contexto do ambiente

Floresta yyy.com com um domínio filho xx.yyy.com. O servidor DHCP está no domínio filho e configurado para “sempre atualizar dinamicamente registros DNS”. Para máquinas unidas a xx.yyy.com funciona; para clientes de yyy.com, falha com frequência. Após configurar credenciais dedicadas de DDNS no DHCP (com permissão nas duas zonas), tudo voltou ao normal. A pergunta é: por que isso ocorre e como resolver corretamente?

Entendendo o que acontece “por baixo do capô”

Em zonas DNS integradas ao AD com “apenas atualizações seguras”, cada atualização é autorizada pelo Kerberos/ACLs do objeto da zona no AD. O “autor” do registro (conta que grava) se torna dono do objeto e passa a controlar a atualização/remoção subsequente.

Sem credenciais de DDNS: o serviço DHCP usa a conta de computador do servidor DHCP para tentar criar/atualizar A/PTR.
No mesmo domínio: essa conta de computador geralmente já tem as permissões necessárias na zona daquele domínio, então funciona.
Entre domínios (filho ⇄ pai): a confiança é transitiva, porém as ACLs da zona do domínio pai (yyy.com) não incluem automaticamente a conta de computador do DHCP do filho. Resultado: tentativas de atualização são negadas na zona pai.
Quando você define credenciais dedicadas: o DHCP passa a usar uma conta de serviço com permissões explícitas nas zonas de xx.yyy.com e yyy.com; as atualizações passam a ser aceitas.

Sinais típicos de que o problema é permissão/autoridade

Clientes de yyy.com obtêm lease normalmente, mas o nome não resolve no DNS do domínio pai (somente IP/sem registro A).
Eventos de falha de atualização segura nos logs do DHCP-Server e do DNS-Server (negação de acesso ou falha de autenticação Kerberos para atualizar o objeto da zona).
Executar ipconfig /registerdns em um cliente do domínio pai funciona quando o próprio cliente possui permissão para atualizar, mas falha quando a política é o DHCP realizar a atualização em nome dele.

Resumo da causa raiz

O agente que escreve o registro na zona yyy.com (o serviço DHCP do domínio filho) não tem direito de criação/atualização nessa zona. A solução correta é dar identidade e permissão explícitas ao agente que atualiza: uma conta de serviço para DDNS ou delegar ACLs à conta de computador do DHCP (menos flexível).

Fluxos de atualização A/PTR e quem deve ser o autor

Existem estratégias diferentes para definir quem atualiza cada tipo de registro. A tabela abaixo ajuda a decidir:

Estratégia	Registro A	Registro PTR	Prós	Contras	Quando usar
Cliente atualiza A; DHCP atualiza PTR	Cliente	DHCP	Evita conflitos de propriedade do A; bom alinhamento com GPO do Cliente DNS	Requer GPO/permite que cliente grave na zona; PTR ainda depende do DHCP	Ambientes com estações gerenciadas por GPO
DHCP atualiza A e PTR	DHCP	DHCP	Centraliza controle e limpeza com o lease	Exige credenciais/ACLs do DHCP nas zonas; risco de “dono” único	Redes com muitos dispositivos “burros” (IoT, thin clients)
Cliente atualiza tudo	Cliente	Cliente	Menos dependência do DHCP	Nível de suporte nos clientes varia; limpeza pode ficar deficiente	Ambientes pequenos ou homogêneos

Solução recomendada passo a passo

Criar conta de serviço dedicada para DDNS

Crie uma conta de usuário no AD (por exemplo, svc-dhcp-ddns) com senha longa, complexa e sem expiração (ou com processo controlado de rotação).
Não conceda privilégios administrativos. Essa conta só precisa de direitos nas zonas DNS a serem atualizadas.
Registre em inventário/segurança quem é responsável pela rotação da senha (e documente um plano de emergência).

Delegar permissões nas zonas DNS

No Gerenciador de DNS (em um DC que hospeda a zona integrada ao AD), abra as propriedades da zona xx.yyy.com e também da zona yyy.com.
Em Segurança, adicione a conta svc-dhcp-ddns com permissões:
- List contents / Read (leitura básica),
- Create all child objects (criar registros),
- Write nos tipos de registro relevantes (A, AAAA, PTR e DHCID),
- Delete (para limpeza quando o lease for removido).
Repita para as zonas reversas correspondentes (IPv4 in-addr.arpa e, se aplicável, IPv6 ip6.arpa).
Evite conceder “Controle total” na zona inteira se não for necessário; mantenha o princípio do menor privilégio.

Configurar as credenciais de DDNS no DHCP

Abra o console DHCP no servidor do domínio filho.
Clique com o botão direito no nome do servidor → Propriedades → aba DNS.
Clique em Credenciais… e informe yyy.com\svc-dhcp-ddns e a senha.
Aplique a mesma conta de serviço em todos os servidores DHCP do ambiente. Assim, qualquer um pode atualizar/limpar os mesmos registros sem disputas de propriedade.

Dica: após definir as credenciais, reinicie o serviço DHCP para garantir que o token Kerberos seja renovado com a nova identidade.

Revisar as opções do DHCP ligadas ao DNS

Em Propriedades → DNS do servidor DHCP:
- Marque Sempre atualizar dinamicamente registros DNS (ou “Atualizar se o cliente solicitar”, se deseja que o cliente tome a iniciativa).
- Ative Excluir os registros A e PTR quando o lease for excluído para reduzir registros obsoletos.
Valide as opções distribuídas aos clientes:
- Opção 006 – Servidores DNS apontando para servidores autoritativos da floresta.
- Opção 015 – Sufixo DNS apropriado ao FQDN esperado de cada escopo.
- Opção 081 (DHCP Client FQDN) – Ajuste conforme a sua política de “quem atualiza o quê”.

Garantir pré-requisitos de segurança e confiança

Sincronização de horário (Kerberos): garanta que DCs, DNS e servidores DHCP estejam sincronizados. Divergências causam falhas de autenticação.
Replicação: confirme que as zonas integradas ao AD estão replicando entre todos os DCs que hospedam DNS (inclusive no domínio pai).
Confiança entre domínios: em floresta única, a confiança pai⇄filho é transitiva, mas lembra: confiança não é permissão. ACLs na zona pai ainda precisam incluir a identidade que atualiza.

Validação e testes após a mudança

Em um cliente membro de yyy.com, rode ipconfig /release e ipconfig /renew, depois ipconfig /registerdns.
Monitore eventos nos logs de Microsoft-Windows-DHCP-Server/Operational e DNS-Server. Você deve ver confirmações de criação/atualização dos registros A/PTR ou, em caso de falha, mensagens explícitas de acesso negado.
Verifique a resolução com nslookup:
- nslookup hostname.yyy.com (A/AAAA)
- nslookup <IP> (PTR)
Valide a propriedade do registro no Gerenciador de DNS (Segurança do objeto). O “dono” deve ser a conta de serviço configurada ou o cliente, conforme sua estratégia.

Boas práticas que evitam dor de cabeça

Não use o grupo DNSUpdateProxy sem motivo explícito legado. Com credenciais dedicadas, esse grupo é desnecessário e pode enfraquecer a segurança de propriedade dos registros.
Defina Aging/Scavenging: habilite aging na zona (por exemplo, No-Refresh 7 dias, Refresh 7 dias) e scavenging no servidor DNS. Complementa a limpeza feita pelo DHCP.
Use nomes coerentes: padronize o FQDN de clientes por OU/escopo (ex.: dispositivos do domínio pai sempre com sufixo yyy.com).
Documente escopos multi-domínios: quando um mesmo servidor DHCP atende escopos para xx.yyy.com e yyy.com, garanta que ambas as zonas tenham as ACLs apropriadas.
Evite credenciais pessoais: a conta de DDNS deve ser técnica/impessoal, com controle formal de senha e sem direitos além do necessário.

Checklist rápido de diagnóstico

Verificação	Como checar	Resultado esperado
Credenciais de DDNS definidas no DHCP	Console DHCP → Propriedades → DNS → Credenciais	Conta `yyy.com\svc-dhcp-ddns` configurada
Permissões na zona `yyy.com`	Gerenciador de DNS → Zona → Segurança	Conta com Create/Write/Delete para A/AAAA/PTR/DHCID
Permissões na zona `xx.yyy.com`	Gerenciador de DNS → Zona → Segurança	Mesmas permissões aplicadas
Aging/Scavenging habilitados	Propriedades da zona e do servidor DNS	No-Refresh/Refresh configurados; scavenging ativo
Opções 006, 015 e 081	Console DHCP → Opções do Servidor/Escopo	Apontando para DNS corretos e sufixo adequado
Sincronização de horário	`w32tm /query /status` em DCs e servidores	Offsets dentro do tolerável

Configuração alternativa: cliente escreve o A, DHCP escreve o PTR

Se você preferir que o cliente controle o registro A (muito comum em notebooks), aplique GPOs no “Cliente DNS”:

Registrar endereços desta conexão no DNS: habilitado.
Registrar registros com o sufixo DNS específico da conexão: conforme política de sufixo por site.
No DHCP, mantenha “Atualizar registros PTR” habilitado e “Excluir A/PTR ao remover lease”.

Nesse desenho, a conta de DDNS no DHCP continua necessária para o PTR na zona reversa do domínio pai.

Erros comuns e como evitá-los

Supor que a confiança entre domínios dá permissão automática: não dá. ACLs na zona pai precisam incluir explicitamente a identidade que atualiza.
Delegar permissão só na zona direta e esquecer a reversa: PTRs falham silenciosamente, causando resoluções inversas inconsistentes.
Usar diferentes identidades de atualização em DHCPs distintos: competência de “dono” de registro; padronize uma única conta técnica.
Desabilitar a limpeza de registros ao excluir o lease: acumula lixo no DNS, gerando resultados erráticos ao longo do tempo.
Negligenciar replicação: um DC aceita a atualização, outro não replica a tempo; clientes em locais diferentes “veem” respostas distintas.

Checklist de implementação segura

Conta técnica criada, documentada e protegida (cofre de senhas, rotação planejada).
Permissões delegadas nas zonas xx.yyy.com, yyy.com e reversas correspondentes.
Credenciais aplicadas uniformemente em todos os servidores DHCP.
Opções DHCP revisadas (006, 015, 081) e política de quem atualiza A/PTR definida.
Aging/Scavenging revisados e habilitados.
Logs de DHCP/DNS acompanhados por alguns dias para garantir estabilidade.

Procedimento de teste ponta a ponta

Escolha um host de yyy.com que obtenha lease via o DHCP do domínio filho.
Limpe registros antigos no DNS (se existirem) para esse host (Delete do A/PTR).
No cliente, execute ipconfig /flushdns, depois ipconfig /renew.
Observe no log do DHCP a tentativa de atualização segura usando a conta svc-dhcp-ddns.
No Gerenciador de DNS, confirme que o A em yyy.com e o PTR em in-addr.arpa foram criados, com o owner correto.
Valide resolução direta e reversa a partir de sub-redes diferentes (para confirmar replicação).

Notas sobre registros DHCID e conflitos

Quando o DHCP atualiza o A, ele pode criar um registro DHCID associado ao FQDN. Esse registro ajuda a evitar que outra entidade sobrescreva o A sem a devida propriedade. Se você alternar a estratégia (p.ex., passar o A para o cliente), revise/limpe DHCIDs antigos para não bloquear atualizações legítimas.

Quando não preciso de credenciais dedicadas?

Em cenários simples, com o DHCP e a zona DNS no mesmo domínio e com a conta de computador do servidor DHCP já incluída nas ACLs da zona, as credenciais dedicadas são opcionalmente dispensáveis. Porém, ao cruzar fronteiras entre domínios (filho ⇄ pai), quase sempre você precisa de uma conta técnica ou de delegação explícita para que as atualizações seguras funcionem de forma confiável.

Modelo de decisão

Condição	Recomendação	Motivo
DHCP no filho atualiza zona no pai	Conta de serviço de DDNS + ACLs na zona pai	Conta de computador do filho não tem permissão na zona do pai
Clientes bem gerenciados por GPO	Cliente atualiza A; DHCP atualiza PTR	Evita disputas de propriedade; simplifica troubleshooting
Ambiente com dispositivos não Windows ou IoT	DHCP atualiza A e PTR com credenciais dedicadas	Clientes não sabem atualizar seguros; centralize no DHCP

Perguntas frequentes

Preciso colocar o servidor DHCP no grupo DNSUpdateProxy?
Na maioria dos ambientes modernos, não. Com credenciais dedicadas e ACLs corretas, o uso desse grupo é desnecessário e pode introduzir riscos de segurança de propriedade dos registros.

É possível delegar as permissões à conta de computador do DHCP ao invés de usar uma conta técnica?
É possível, mas menos flexível, especialmente se houver vários servidores DHCP. Uma conta técnica única simplifica a administração e a rotação de chaves.

Tenho múltiplos escopos que atendem subdomínios diferentes; preciso de várias contas?
Não necessariamente. Uma única conta de serviço pode ter permissão em todas as zonas relevantes (diretas e reversas) e ser usada por todos os servidores DHCP.

Como garantir que registros antigos sejam removidos?
Habilite “Excluir A e PTR ao remover lease” no DHCP e configure aging/scavenging nas zonas. Combine isso com janelas de lease coerentes com os intervalos de No-Refresh/Refresh.

Exemplo prático de implementação

Criar yyy.com\svc-dhcp-ddns com senha de 24+ caracteres, armazenada em cofre aprovado.
Na zona yyy.com e nas reversas correspondentes: conceder Read, Create, Write e Delete para a conta.
Repetir as permissões na zona xx.yyy.com.
Configurar as credenciais no DHCP do filho (aba DNS → Credenciais) e aplicar a todos os DHCPs.
Habilitar “Descartar registros A e PTR quando o lease for excluído”.
Validar com ipconfig /registerdns e nslookup.

Roteiro de rollback

Mantenha um snapshot/export das ACLs da zona antes da mudança.
Se houver problema, remova temporariamente as credenciais, revertendo o comportamento para a conta de computador — apenas para as zonas em que ela já funcionava — enquanto ajusta as permissões.
Reaplique as credenciais após corrigir as ACLs e reinicie o serviço DHCP.

Conclusão

O sintoma parecia “intermitência” do DDNS, mas a raiz do problema é previsível: quem escreve o registro precisa ter autoridade na zona de destino. Em estruturas pai⇄filho, essa autoridade não surge sozinha. Ao adotar uma conta de serviço dedicada de DDNS (usada por todos os DHCPs) e delegar as permissões nas zonas xx.yyy.com, yyy.com e reversas, você estabiliza as atualizações, padroniza a propriedade dos registros e simplifica a limpeza e o suporte.