DNS Query Resolution Policy

Question

DNS Query Resolution Policy

Philip Luke 20

QUERY RESOLUTION POLICY. Well, that's how I thought it might work. Let me explain. We have a need for queries from a specific subnet to return a different ip for the associated A record. But, if the record DOESN'T exist, then to carry out recursion to a Public DNS server, hosting a zone with the same name, but additional records. We could achieve the same if we added the fdqns into local Host files, as that would provide what we want, but that isn't a mature technical solution, and requires more management than hosting in local Dns. The issue I have is the recursion isn't working. It will only resolve records from local Dns. If someone could confirm If this is possible, and maybe even help out with the powershell. Thank you for any help.

Answer accepted by question author

1 additional answer

Your answer

Answer 1

Hello,

The behavior you are experiencing is the expected design of the DNS protocol, specifically regarding the concept of Authority. When you host a Forward Lookup Zone for a domain (e.g., company.com) on your DNS server to provide split-horizon records, your server declares itself Authoritative for that entire namespace. When a query comes in for a record that doesn't exist in your local zone (e.g., cloud.company.com), the server checks its local database, finds nothing, and correctly returns an NXDOMAIN (Name Not Found) response. It does not trigger recursion because, as the authority, it "knows" that if the record isn't in the local file, it doesn't exist anywhere.

To achieve your goal, resolving specific internal records locally while letting everything else recurse to public DNS, you must not host the root of the zone (the parent domain) on this server. Instead, you should use Pinpoint Zones (also known as FQDN Zones).

Rather than creating a zone for company.com (which kills recursion for the whole domain), you create zones only for the specific Fully Qualified Domain Names (FQDNs) you need to override.

For example, if you need intranet.company.com to resolve to 192.168.1.50, but want www.company.com to resolve publicly:

Delete the broad company.com zone from your internal server.

Create a new Forward Lookup Zone named exactly intranet.company.com.

Add an "A" record inside that zone with the name @ (Same as parent folder) pointing to 192.168.1.50.

How this fixes the logic: Query for intranet.company.com: The server sees it has a specific zone for this. It answers authoritatively with your local IP.

Query for www.company.com: The server checks its zones. It does not have a zone named www.company.com or company.com. It treats this as a standard external query and performs recursion (or forwarding) to the internet, successfully resolving the public IP.

PowerShell Implementation

Here is the PowerShell workflow to remove the blocking parent zone (if it exists) and create the specific Pinpoint Zone.

(Optional) Remove the broad authoritative zone that is blocking recursion

WARNING: Ensure you have backed up any other necessary records from this zone.

Remove-DnsServerZone -Name "yourdomain.com" -Force

Create the Pinpoint Zone for the specific FQDN

Replace "record.yourdomain.com" with the actual FQDN you want to override:

Add-DnsServerPrimaryZone -Name "record.yourdomain.com" -ReplicationScope "Forest" # Or "Domain" / "None" based on your setup

Add the A Record to the new Pinpoint Zone

We use "@" as the name to represent the zone root (the FQDN itself):

Add-DnsServerResourceRecordA -ZoneName "record.yourdomain.com" -Name "@" -IPv4Address "10.10.10.50"

Important: Using Pinpoint Zones solves the recursion issue perfectly. However, because a Zone is a global object on the server, this override will apply to all clients using this DNS server, not just a specific subnet.

If you strictly require that only Subnet A sees the internal IP while Subnet B (using the same DNS server) sees the public IP for the exact same FQDN, Pinpoint Zones alone won't suffice. That scenario requires complex DNS Policies or splitting clients onto different DNS servers. However, in most Split-Horizon scenarios, having the internal IP resolve for all internal clients is acceptable and preferred.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

VP

Philip Luke 20 Reputation points

2025-12-16T10:56:32.9966667+00:00

Thank you very much for this - it really helped figure the issue out. Pinpoint zone is the key. I was trying to create the root zone, and use Query Resolution and Recursion Policies to fix this..

Answer 2

To achieve the desired behavior of returning a different IP address for queries from a specific subnet while allowing recursion to a public DNS server when the record doesn't exist locally, you can use DNS Query Resolution Policies in Windows Server. Here’s a general approach you can take:

Create a Client Subnet for the specific subnet from which you want to direct queries.
```
   Add-DnsServerClientSubnet -Name "SpecificSubnet" -IPv4Subnet 192.0.2.0/24
```

Create a Zone Scope for the specific A record you want to resolve differently.

   Add-DnsServerZoneScope -ZoneName "yourdomain.com" -Name "SpecificScope"

Add the A Record in the specific zone scope with the desired IP address.

   Add-DnsServerResourceRecord -ZoneName "yourdomain.com" -ZoneScope "SpecificScope" -A -Name "www" -IPv4Address "192.0.2.1"

Create a DNS Query Resolution Policy that allows queries from the specific subnet to resolve using the zone scope you created.

   Add-DnsServerQueryResolutionPolicy -Name "SpecificSubnetPolicy" -Action ALLOW -ClientSubnet "eq,SpecificSubnet" -ZoneScope "SpecificScope" -ZoneName "yourdomain.com"

Set Up Recursion for queries that do not match any local records. You can create a recursion scope and set it to allow recursion for queries that do not match local records. This can be done using the following commands:
```
   Add-DnsServerRecursionScope -Name "PublicRecursion" -EnableRecursion $True
   Set-DnsServerRecursionScope -Name . -EnableRecursion $False
```

Create a Policy for Recursion that allows recursion for queries that do not match any records in the specific zone scope.

   Add-DnsServerQueryResolutionPolicy -Name "RecursionPolicy" -Action ALLOW -ApplyOnRecursion -RecursionScope "PublicRecursion" -ZoneName "yourdomain.com"

Make sure to replace yourdomain.com and the IP addresses with your actual domain and desired IPs. This setup should allow your DNS server to respond with the specific IP for the designated subnet while still performing recursion for other queries that do not match any local records.

If you continue to experience issues with recursion not working as expected, ensure that your DNS server is configured correctly to allow recursion and that there are no firewall rules blocking outbound DNS queries.

References:

Share via

DNS Query Resolution Policy

1 additional answer

Your answer