MENU
  1. Início
  2. Windows
  3. troubleshooting
  4. Como diagnosticar e corrigir bloqueios de zona DNS (zone lock) em Windows Server e BIND

Como diagnosticar e corrigir bloqueios de zona DNS (zone lock) em Windows Server e BIND

troubleshooting

Uma zona DNS que entra em estado de “zone lock” pode paralisar delegações, causar falhas de resolução e prejudicar serviços críticos em minutos. Este guia de referência detalha como reconhecer, diagnosticar e eliminar bloqueios—seja em Windows Server ou em BIND—e, sobretudo, como preveni‑los.

Índice

O que é um bloqueio de zona?

Em servidores modernos, sempre que uma alteração ocorre na zona (inclusão, exclusão ou edição de registo), o serviço DNS aplica um bloqueio de escrita temporário para garantir consistência durante a gravação e a replicação. Esse bloqueio deveria durar milissegundos, mas problemas de replicação, permissões, ficheiros de jornal (.jnl) corrompidos ou políticas mal definidas podem prolongá‑lo indefinidamente, impedindo novas alterações e o transfer‑out para segundos.

Sintomas clássicos de uma zona travada

  • Mensagens recorrentes de “Zone transfer failed”, “Zone write lock exceeded” ou “Access is denied” nos registos de eventos.
  • Número de série (SOA Serial) que permanece estático mesmo após várias alterações.
  • Comandos como dnscmd /EnumRecords ou rndc status mostram a zona como “loading” ou “journal in progress” sem concluir.
  • Servidores secundários exibem registos desatualizados ou não conseguem completar uma AXFR/IXFR.
  • Novas entradas criadas pela consola DNS simplesmente desaparecem após alguns segundos.

Passo a passo para diagnosticar e corrigir

EtapaAção recomendadaObservações práticas
1. Analisar logsRevise o Event Viewer › DNS Server em busca de erros como “Zone transfer failed”, “Zone write lock” ou tempos‑limite de replicação.Confirma se há bloqueio de escrita, falha de transferência (AXFR/IXFR) ou problema de replicação do AD.
2. Conferir definições de transferênciaEm Propriedades da zona › Transferências de zona, verifique:
• Allow zone transfers habilitado apenas para servidores autorizados
• Notify configurado para os mesmos segundos		Se as listas não coincidirem, o primário recusa alterações ou falha ao notificar segundos.
3. Rever propriedades da zonaConfirme:
• Tipo de zona (Primária, Secundária, AD‑integrada)
• Atualizações dinâmicas (seguras/não seguras)
• Zone Write Locking (Windows Server 2012 R2+)—valor predefinido 15 %.
Comando: dnscmd /Config <zona> /ZoneWriteLockingPercent <n>		Reduza temporariamente para 5 % se a replicação for lenta ou se a zona contiver milhares de registos.
4. Verificar permissões• ACLs NTFS dos ficheiros *.dns (zonas não integradas)
• ACEs em CN=MicrosoftDNS (AD‑DS)
• Políticas de Grupo que possam estar negando dnsZoneChange		“Access is denied” mantém o bloqueio ativo até que a ACL seja corrigida.
5. Reiniciar o serviço DNSnet stop dns && net start dns ou Services.mscLiberta locks residuais em memória ou sessões RPC presas.
6. Eliminar registos em conflitoListe registos: dnscmd /EnumRecords <zona>; remova duplicados (A, CNAME, SRV, TXT) com o mesmo nome.Conflitos podem acionar um ciclo de rollback contínuo e segurar o lock.
7. Forçar replicação/transferência• repadmin /syncall (AD)
• dnscmd /ZoneReload <zona> (Windows)
• rndc reload (BIND)		Garante que todos os primários/segundos sincronizem o mesmo serial.
8. Monitorizar serial e SOAConfirme que o campo Serial aumenta após cada alteração de conteúdo.Serial estático + bloqueio = alterações que nunca chegam a downstreams.

Debug na prática

Para capturar detalhes de baixo nível, habilite Debug Logging em DNS › Propriedades › Depuração. Deixe ativo o mínimo possível—o volume de log cresce depressa. Em BIND, use rndc trace 2 por alguns minutos e depois rndc notrace.

Verificação avançada em Windows Server

Zone Write Locking em detalhe

A partir do Windows Server 2012 R2, o serviço implementa write throttling; enquanto mais de n% dos registos estão em replicação, a zona fica bloqueada para novas escritas. Em ambientes com muitos controladores de domínio distantes, esse limiar pode ser atingido com frequência.

Boas práticas:

  • Ajuste ZoneWriteLockingPercent para 5–10 % apenas enquanto corrige a replicação.
  • Configure Intervalo de Refresh do SOA (Refresh) para um valor realista (ex.: 15 min) de modo a evitar storms de IXFR.
  • Use repadmin /showrepl para confirmar latência entre DCs. Mais de 15 min indica gargalo que pode manter o lock por horas.

Problemas com zonas integradas no AD

Se a zona for armazenada em Application Partition, verifique:

  • Abra o Adsiedit.msc em CN=MicrosoftDNS, CN=System, DC=.... Certifique‑se de que os grupos DnsAdmins e Domain Controllers têm Write.
  • Busque atributos “dNSTombstoned”. Objetos marcados como tombstone bloquearão atualizações até que expirem.
  • No Event Viewer, erros 4521 e 4523 indicam corrupção no Application Partition. Fazer ndcutil cleanup (em DCs baseados em Windows Server 2022) remove blobs órfãos.

Verificação avançada em BIND/Linux

Journal Locks

Quando named grava uma alteração, ele usa um ficheiro zone.jnl. Interrupções abruptas (queda de energia, kill -9) podem deixar um lockfile ou o próprio journal inconsistente, impedindo a inicialização da zona.

  1. Pare o serviço: systemctl stop named ou service named stop.
  2. Apague ou renomeie /var/named/<zona>.jnl.
  3. Opcional: execute named-checkzone <zona> /var/named/<zona>.db para validar sintaxe.
  4. Inicie o serviço e aplique rndc sync -clean para gerar um novo journal coerente.

Pontos de ajuste em named.conf

  • max-journal-size: limita o tamanho do journal para evitar que discos cheios causem bloqueios.
  • serial-update-method increment: instruir o BIND a incrementar sempre o serial evita divergência silenciosa.
  • notify explicit; com also-notify garante que apenas segundos listados receberão NOTIFY, prevenindo loops.

Boas práticas para evitar bloqueios futuros

  • Planeamento de manutenção: sempre que possível, aplique grandes alterações fora do horário de pico.
  • Automatização com scripts: use PowerShell ou nsupdate para aplicar lotes, monitorando logs em tempo real.
  • Versionamento de zona: mantenha as .db num VCS (Git) e utilize pipelines para validar o serial antes do deploy.
  • Acompanhamento de KPI: registe MTTR, número de registos, tempo médio de replicação; se tendências crescerem mais de 20 % em 30 dias, investigue.
  • Auditoria: registe quem alterou, quando e qual era o serial. Isso acelera rollback se um bloqueio for causado por erro humano.

Checklist rápido

Antes de declarar vitória, confirme:

  1. Logs limpos—nenhuma ocorrência de erro em 30 min.
  2. SOA Serial idêntico entre primário e todos os segundos.
  3. AXFR/IXFR concluindo em <60 s.
  4. Nenhum .jnl excedendo valor de max-journal-size.
  5. Teste de resolução (dig @segundo registo.zona) retorna valores atualizados.

Conclusão

Bloqueios de zona são mais sintomas do que causas. Eles revelam gargalos de replicação, conflitos de permissões ou processos de alteração não controlados. Seguindo o roteiro apresentado—dos logs à análise de journal—você elimina o estado de bloqueio e cria bases sólidas para uma infraestrutura DNS resiliente.

Ao finalizar o processo, documente cada passo, ajuste limiares de write locking de acordo com o seu perfil de tráfego e mantenha observabilidade contínua. Assim, mesmo em ambientes híbridos com Windows Server e BIND, suas zonas permanecerão ágeis, seguras e livres de deadlocks.

troubleshooting
BIND DNS Troubleshooting Windows Server zone lock
Índice