In a large enterprise network, DNS (Domain Name System) is usually viewed as a simple phonebook: a client asks for the IP address of intranet.company.com, and the DNS server returns a static IP. However, this basic setup fails when your company has multiple datacenters. If a user in the London office asks for the intranet server, you want them to connect to the local London server, not the server in New York, to minimize latency. Historically, this required buying expensive hardware load balancers. But with modern versions of Windows Server, you can achieve intelligent, location-based routing natively using DNS Policies.
What are DNS Policies?
DNS Policies allow the Windows Server DNS service to analyze incoming DNS requests and alter its response based on specific criteria. The most common criteria is the Client Subnet. The DNS server looks at the IP address of the computer asking the question, checks which geographic location that IP belongs to, and dynamically returns the IP address of the closest physical web server.
Step 1: Define the Client Subnets
Because DNS Policies are an advanced feature, they cannot be configured using the standard graphical DNS Manager console. You must use PowerShell.
First, you must teach the DNS server about your company’s network topology. You do this by creating Client Subnets.
Assume your New York office uses the 10.1.0.0/16 subnet, and your London office uses the 10.2.0.0/16 subnet. Open an elevated PowerShell prompt on the DNS Server:
Add-DnsServerClientSubnet -Name "NewYorkSubnet" -IPv4Subnet "10.1.0.0/16"
Add-DnsServerClientSubnet -Name "LondonSubnet" -IPv4Subnet "10.2.0.0/16"Step 2: Create Zone Scopes
Next, you must create “Scopes” within your existing DNS zone. A Scope is essentially a parallel universe inside your DNS zone. By default, every record lives in the default scope. We will create two new scopes for our locations.
Assuming your company’s internal domain is company.local:
Add-DnsServerZoneScope -ZoneName "company.local" -Name "NewYorkScope"
Add-DnsServerZoneScope -ZoneName "company.local" -Name "LondonScope"Step 3: Add Records to the Scopes
Now, you populate those scopes with the location-specific IP addresses. Both records will have the exact same name (intranet), but they will point to different IPs and live in different scopes.
Add the New York server (10.1.50.5) to the New York Scope:
Add-DnsServerResourceRecord -ZoneName "company.local" -A -Name "intranet" -IPv4Address "10.1.50.5" -ZoneScope "NewYorkScope"Add the London server (10.2.50.5) to the London Scope:
Add-DnsServerResourceRecord -ZoneName "company.local" -A -Name "intranet" -IPv4Address "10.2.50.5" -ZoneScope "LondonScope"Step 4: Create the Traffic Resolution Policies
Finally, you create the actual rules that tie the Subnets and the Scopes together. We will instruct the DNS server to match the incoming IP address against the Subnet, and if it matches, reply with the answer from the corresponding Scope.
Create the New York policy:
Add-DnsServerQueryResolutionPolicy -Name "NYPolicy" -Action ALLOW -ClientSubnet "eq,NewYorkSubnet" -ZoneScope "NewYorkScope,1" -ZoneName "company.local"Create the London policy:
Add-DnsServerQueryResolutionPolicy -Name "LondonPolicy" -Action ALLOW -ClientSubnet "eq,LondonSubnet" -ZoneScope "LondonScope,1" -ZoneName "company.local"(The ,1 after the scope name defines the weight, which is used if you are load-balancing across multiple scopes).
Step 5: Testing the Configuration
The configuration takes effect immediately without restarting the DNS service. If a laptop in New York (IP 10.1.x.x) pings intranet.company.local, the DNS server will evaluate the policy, match the NewYorkSubnet, and return 10.1.50.5. If a desktop in London (IP 10.2.x.x) pings the exact same hostname, the DNS server will dynamically return 10.2.50.5.
By leveraging DNS Policies, you eliminate cross-Atlantic WAN traffic, significantly improving the performance of internal applications without spending a dime on load balancing hardware.