Windows Server DNS com priorização de subnet e round-robin

Publicado por Alex Moura em

Subnet mal planejada não quebra na implantação. Quebra quando a empresa cresce.

Introdução

Olá!
Hoje vamos falar de um comportamento em redes Windows que você deveria SEMPRE levar em consideração ao projetar ou implementar o seu plano de subnets, principalmente em qualquer escopo que envolva pelo menos duas redes /24.

Dando um spoiler para os apressadinhos:

EVITE AO MÁXIMO USAR RANGES NÃO SEQUENCIAIS EM SUAS DEFINIÇÕES DE SUBNETS.

Isso não é apenas uma boa prática organizacional.
Trata-se de uma característica interna do DNS do Windows Server, pouco documentada, que impacta diretamente latência, autenticação, GPO, DFS, LDAP e a escalabilidade de ambientes com Active Directory distribuído.

Exemplos de planejamento de subnets

✅ Exemplos corretos (sequenciais)

  • 10.0.0.0/24 e 10.0.1.0/24
  • 172.20.0.0/24 e 172.20.1.0/24
  • 192.168.50.0/24 , 192.168.51.0/24, 192.168.52.0/24, 192.168.53.0/24

Esses modelos permitem:

  • continuidade binária
  • sumarização lógica
  • crescimento previsível
  • priorização correta de subnet no DNS

❌ Exemplos incorretos (não sequenciais)

  • 10.0.0.0/24 e 192.168.0.0/24
  • 172.40.0.0/24 e 10.5.0.0/24
  • 172.100.100.0/24 e 192.168.100.0/24

Esses cenários criam ilhas de endereçamento, que:

  • não podem ser representadas por uma única máscara
  • quebram a lógica de proximidade do DNS
  • forçam o uso de round-robin puro

Topologia de rede — por que este artigo existe?

Antes de entrar em configurações avançadas, é fundamental entender o problema que este artigo resolve.

Cenário 1 — Site único, subnet única

Você está em uma estação de trabalho em uma rede local, em um site único, e precisa realizar uma consulta DNS.

Fluxo:

  • A estação pergunta quais servidores DNS estão disponíveis
  • Existe apenas um servidor DNS
  • A resposta vem dele

✅ Tudo funciona corretamente.
Nesse cenário, qualquer erro estrutural fica mascarado.

Cenário 2 — Floresta com dois sites e subnet única em cada site

Agora a floresta possui dois sites, cada um com seu próprio DNS.

  • A estação está na mesma subnet do DNS local
  • O Active Directory associa corretamente a subnet ao site
  • O DNS local responde

✅ Baixa latência
✅ Comportamento previsível

Ainda assim, o problema não aparece.

Cenário 3 — Dois sites, subnets diferentes entre workstations e DNS local

Aqui está o cenário crítico.

Você está em uma estação de trabalho:

  • em uma subnet diferente da subnet do DNS local
  • em uma floresta com dois sites
  • cada site com seu próprio servidor DNS

Neste caso:

  • Ambos os servidores DNS são válidos
  • Pela configuração padrão do Windows, não existe garantia de prioridade

Resultado:

  • A resposta depende
  • A consulta pode ir para o DNS local
  • Ou pode ir para um DNS remoto
  • A decisão ocorre em round-robin, de forma aparentemente aleatória

👉 No cenário acima, o comportamento passa a ser este:

🔴 Quando o DNS responde fora do site correto

⚠️ Atenção: este não é um problema de falha, é um problema de previsibilidade

Quando o DNS em um ambiente Active Directory responde fora do site correto, o ambiente continua funcionando, porém passa a apresentar comportamento inconsistente, difícil de diagnosticar e cada vez mais custoso conforme a infraestrutura cresce.

Os impactos mais comuns são:

  • Logon de usuários lento ou variável
  • Autenticação inconsistente (ora local, ora remota)
  • Aplicação de GPOs demorando ou falhando intermitentemente
  • Falhas em encontrar recursos/hosts que só existem localmente
  • DC Locator imprevisível
  • DFS / aplicações sensíveis à latência
  • Problemas intermitentes difíceis de diagnosticar
  • Dificuldade de troubleshooting
  • Aumento injustificado de dependência da WAN
  • Perda do isolamento lógico entre sites
  • Necessidade de comunicação irrestrita entre todos os sites

👉 Nada quebra de vez — tudo fica imprevisível.

A característica pouco documentada do DNS do Windows

O DNS do Windows Server possui um mecanismo chamado DNS Subnet Prioritization, controlado pelas chaves:

HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\LocalNetPriority
HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters\LocalNetPriorityNetMask

⚠️ Importante:

  • Não utiliza Sites and Services
  • Não utiliza custo de link
  • Não utiliza subnet do AD
  • Utiliza apenas comparação binária de IP baseada em máscara

Configurando a priorização de subnet no DNS

1️⃣ Ativando LocalNetPriority

Chave: LocalNetPriority
Tipo:  REG_DWORD
Valor: 1

Ativa a tentativa do DNS de priorizar registros considerados locais antes do round-robin.

2️⃣ Configurando LocalNetPriorityNetMask

Chave: LocalNetPriorityNetMask
Tipo:  REG_DWORD
Valor: máscara em hexadecimal

Essa máscara define qual parte do endereço IP o DNS considera como rede local.

Como calcular a máscara LocalNetPriorityNetMask

A máscara não é a subnet mask tradicional.

O cálculo é feito assim:

  1. Comece com 255.255.255.255
  2. Subtraia a subnet mask desejada
  3. Converta o resultado para hexadecimal
  4. Remova os pontos

Exemplo /21 (255.255.248.0)

255 255 255 255
255 255 248   0
----------------
0   0   7   255

Hexadecimal:

000007ff

Exemplo /20 (255.255.240.0)

255 255 255 255
255 255 240   0
----------------
0   0   15  255

Hexadecimal:

00000fff

Exemplo /16 (255.255.0.0)

255 255 255 255
255 255   0   0
----------------
0   0   255 255

Hexadecimal:

0000ffff

Exemplo /22 (255.255.252.0)

255 255 255 255
255 255 252   0
----------------
0   0   3   255

Hexadecimal:

000003ff

Relação entre priorização de subnet e round-robin

O comportamento final do DNS é:

  1. Prioriza IPs considerados locais
  2. Dentro do conjunto local, aplica round-robin
  3. Se não houver IP local:
    • round-robin global
    • ordem imprevisível

Por que ranges não sequenciais quebram essa lógica?

Se você usa subnets como:

  • 10.0.10.0/24
  • 10.0.20.0/24
  • 10.0.30.0/24

👉 não existe máscara binária única que represente esse padrão, ou será necessário utilizar uma máscara excessivamente ampla, englobando endereços que não deveriam ser considerados locais.

Resultado:

  • LocalNetPriority perde efeito
  • DNS opera como round-robin puro
  • comportamento imprevisível aparece

✅ Checklist de sintomas — diagnóstico rápido em produção

Use este checklist como confirmação prática do problema descrito até aqui.

  • ☐ Logon de usuários demora mais em alguns dias do que em outros
  • ☐ gpupdate /force demora sem motivo aparente
  • ☐ nltest /dsgetdc retorna DCs de outros sites
  • ☐ Aplicações funcionam localmente, mas falham aleatoriamente
  • ☐ DFS Namespace aponta para servidores remotos
  • ☐ Replicações parecem lentas sem erro claro
  • ☐ Scripts e automações apresentam comportamento irregular
  • ☐ Ferramentas administrativas conectam em DCs errados
  • ☐ Firewalls precisam liberar tráfego excessivo entre sites
  • ☐ Diagnóstico sempre começa com “mas o DNS responde…”

👉 Se parece aleatório, geralmente não é.

🧠 Conclusão

O planejamento de subnets em ambientes Windows não é apenas roteamento.
É comportamento interno do DNS, baseado em máscaras binárias, e não em lógica administrativa.

O maior erro em Active Directory não é criar algo que não funcione.
É criar algo que funcione sem previsibilidade.

O DNS do Windows Server:

  • não entende intenção administrativa
  • não considera “proximidade lógica”
  • decide com base em subnet, máscara e priorização

Quando o planejamento de subnets é mal feito — especialmente com ranges não sequenciais — o DNS perde a capacidade de decidir corretamente quem está mais próximo, e o ambiente passa a depender de round-robin e sorte.

Arquitetura de Active Directory não é sobre fazer funcionar hoje.
É sobre garantir que continue previsível amanhã.

Planejar subnets corretamente e configurar a priorização de subnet no DNS não é otimização.
É fundação.

Subnet sequencial bem planejada + LocalNetPriority bem configurado = DNS previsível, rápido e escalável.

Ignorar isso é garantir:

  • crescimento problemático
  • troubleshooting complexo
  • e incidentes difíceis de reproduzir.

Nota do autor

Este artigo nasceu a partir de problemas reais observados em ambientes de produção, ao longo de projetos envolvendo Active Directory distribuído, múltiplos sites e DNS do Windows Server.

A motivação principal foi documentar um comportamento pouco explorado na documentação oficial, mas que impacta diretamente latência, previsibilidade e escalabilidade de ambientes Windows: a priorização de subnet no DNS.

O objetivo aqui não é apenas ensinar uma configuração, mas explicar o raciocínio técnico por trás dela, para que arquitetos e administradores consigam planejar corretamente suas redes antes que o problema apareça.

Se este artigo evitar um único ambiente imprevisível no futuro, ele já cumpriu seu papel.

Deixe uma resposta