Windows Server DNS with Subnet Prioritization and Round-Robin

A poorly planned subnet does not break during deployment. It breaks when the company grows.

Introduction

Hello!
Today we're going to talk about a behavior in Windows networks that you should ALWAYS take into consideration when designing or implementing your subnet plan, especially in any scope that involves at least two /24 networks.

Giving a spoiler for those in a hurry:

AVOID USING NON-SEQUENTIAL RANGES IN YOUR SUBNET DEFINITIONS AS MUCH AS POSSIBLE.

This is not just a good organizational practice. It is a poorly documented internal characteristic of Windows Server DNS that directly impacts latency, authentication, GPO, DFS, LDAP, and the scalability of environments with distributed Active Directory.

---

Exemplos de planejamento de subnets

✅ Exemplos corretos (sequenciais)

• 10.0.0.0/24 and 10.0.1.0/24
• 172.20.0.0/24 and 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

These models allow:

• binary continuity
• logical summarization
• predictable growth
• correct subnet prioritization in DNS

---

❌ Exemplos incorretos (não sequenciais)

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

These scenarios create addressing islands, which:

• They cannot be represented by a single mask.
• They break the logic of proximity in DNS.
• force the use of pure round-robin

---

Network topology — why does this article exist?

Before delving into advanced settings, it's essential to understand the problem this article solves.

---

Scenario 1 — Single site, single subnet

You are at a workstation on a local network, at a single site, and you need to perform a DNS query.

Fluxo:

• The station asks which DNS servers are available.
• There is only one DNS server.
• The answer comes from him.

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

---

Scenario 2 — Forest with two sites and a single subnet in each site.

Now the forest has two sites, each with its own DNS.

• The station is on the same subnet as the local DNS
• Active Directory correctly associates the subnet with the site.
• The local DNS responds

✅ Baixa latência
✅ Comportamento previsível

Still, the problem doesn't appear.

---

Scenario 3 — Two sites, different subnets between workstations, and local DNS.

Here is the critical scenario.

You are at a workstation:

• in a different subnet than the local DNS subnet
• in a forest with two sites
• each website with its own DNS server

In this case:

• Both DNS servers are valid.
• By default, Windows configuration does not guarantee priority.

Result:

• The answer depends.
• The query can go to the local DNS.
• Or you can go to a remote DNS server.
• The decision is made in a round-robin format, seemingly at random.

👉 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

When DNS in an Active Directory environment responds outside the correct site, the environment continues to function, but it begins to exhibit inconsistent behavior, which is difficult to diagnose and becomes increasingly costly as the infrastructure grows.

The most common impacts are:

• Slow or inconsistent user logins
• Inconsistent authentication (sometimes local, sometimes remote)
• GPO application taking too long or failing intermittently.
• Failures to find resources/hosts that only exist locally.
• DC Locator unpredictable
• DFS / latency-sensitive applications
• Intermittent problems that are difficult to diagnose.
• Difficulty in troubleshooting
• Unjustified increase in WAN dependency
• Loss of logical isolation between sites
• The need for unrestricted communication between all sites.

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

---

The poorly documented feature of Windows DNS

Windows Server DNS has a mechanism called DNS Subnet Prioritization, controlled by the following keys:

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

⚠️ Importante:

• Does not use Sites and Services
• It does not use link costs.
• It does not use an AD subnet.
• Uses only binary IP mask comparison

---

Configuring subnet prioritization in DNS

1️⃣ Ativando LocalNetPriority

Chave: LocalNetPriority
Tipo:  REG_DWORD
Valor: 1

Enables DNS to prioritize records considered local before round-robin.

---

2️⃣ Configurando LocalNetPriorityNetMask

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

This mask defines which part of the IP address the DNS considers to be the local network.

---

How to calculate the LocalNetPriorityNetMask mask

The mask is not the traditional subnet mask.

The calculation is done like this:

1. Start with 255.255.255.255
2. Subtract the desired subnet mask.
3. Convert the result to hexadecimal.
4. Remove the stitches

---

Example /21 (255.255.248.0)

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

Hexadecimal:

000007ff

---

Example /20 (255.255.240.0)

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

Hexadecimal:

00000fff

---

Example /16 (255.255.0.0)

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

Hexadecimal:

0000ffff

---

Example /22 (255.255.252.0)

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

Hexadecimal:

000003ff

---

Relationship between subnet prioritization and round-robin

The final behavior of DNS is:

1. Prioritizes IPs considered local
2. Within the local set, apply round-robin
3. Se não houver IP local:
   • round-robin global
   • ordem imprevisível

---

Why do non-sequential ranges break this logic?

If you use subnets like:

• 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.

Result:

• LocalNetPriority loses effect.
• DNS operates as pure round-robin.
• unpredictable behavior appears

---

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

Use this checklist as a practical confirmation of the problem described so far.

• ☐ User login takes longer on some days than on others.
• ☐ gpupdate /force delay for no apparent reason
• ☐ nltest /dsgetdc returns DCs from other sites
• ☐ Applications work locally, but fail randomly.
• ☐ DFS Namespace points to remote servers
• ☐ Replications seem slow with no clear error.
• ☐ Scripts and automations are exhibiting erratic behavior.
• ☐ Administrative tools connect to incorrect DCs
• ☐ Firewalls need to allow excessive traffic between websites.
• ☐ Diagnosis always begins with “but the DNS responds…”

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

🧠 Conclusão

Subnet planning in Windows environments is not just routing. It's internal DNS behavior, based on binary masks, and not on administrative logic.

The biggest mistake in Active Directory is not creating something that doesn't work.
It's creating something that works without predictability.

Windows Server DNS:

• does not understand administrative intent
• does not consider "logical proximity"
• decides based on subnet, mask, and prioritization

When subnet planning is poorly done — especially with non-sequential ranges — the DNS loses the ability to correctly decide who is closest, and the environment becomes dependent on round-robin and luck.

Active Directory architecture isn't about making it work today.
It's about ensuring it remains predictable tomorrow.

Planning subnets correctly and configuring subnet prioritization in DNS is not optimization. .
It's the foundation..

A well-planned sequential subnet + a well-configured LocalNetPriority = predictable, fast, and scalable DNS.

Ignoring this is a sure way to guarantee:

• problematic growth
• complex troubleshooting
• and incidents that are difficult to reproduce.

Author's note

This article originated from real-world problems observed in production environments, throughout projects involving distributed Active Directory, multiple sites, and Windows Server DNS.

The main motivation was to document a behavior that is underexplored in the official documentation, but which directly impacts the latency, predictability, and scalability of Windows environments: subnet prioritization in DNS.

The goal here is not just to teach a configuration, but to explain the technical reasoning behind it, so that architects and administrators can correctly plan their networks before the problem arises.

If this article prevents even a single unpredictable environment in the future, it has already fulfilled its purpose.