3

I need to provide a kind of DNS split-brain scenario with two key goals:

  1. "special" DNS clients (based on their subnet) must resolve certain A records in one domain to different IP addresses than the rest of clients
  2. all other records in the same domain must be resolved equally regardless of which client is asking.

In other words, I want to create a kind of "DNS rewrite" or overlay, where few records will be different for some clients. I was hoping to accomplish this by DNS policies in Server 2016 which describe "split brain/horizon" as one of the intended scenarios e.g. https://blogs.technet.microsoft.com/networking/2015/05/12/split-brain-dns-deployment-using-windows-dns-server-policies/ - but it seems I can't achieve goal 2.

In my testing I created a ZoneScope with alternative IP addresses to be returned to matched clients and query resolution policy based on client subnet, achieving goal 1). BUT if a client is matched to be from the "special" subnet, it is able to resolve ONLY records from the special ZoneScope, but not from the "default" scope - so failing goal 2.

Is there perhaps a configuration step I missed that would allow fallback to the default ZoneScope in case my special zonescope does not contain a matching record? I'm told this can be done easily with BIND DNS with Response Zone Policy, but I would like to stick with MS if at all possible. Also using hosts files is not possible as those"special" servers are not fully under our control.

Steps to reproduce

#define subnet of restricted servers
Add-DnsServerClientSubnet -name SpecialServers -IPv4Subnet 192.168.0.0/24    
#define ZoneScope for the special records 
Add-DnsServerZoneScope -ZoneName "test.local" -Name "SpecialZoneScope" 

#Prepare some testing records in the default scope
Add-DnsServerResourceRecord -ZoneName "test.local" -A -Name HostA -IPv4Address 1.1.1.1
Add-DnsServerResourceRecord -ZoneName "test.local" -A -Name HostB -IPv4Address 1.1.1.2
#Prepare alternative record in SpecialZoneScope
Add-DnsServerResourceRecord -ZoneName "test.local" -ZoneScope "SpecialZoneScope" -A -Name HostA -IPv4Address 20.20.20.1

#Define query resolution policy 
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action ALLOW -ClientSubnet "eq,SpecialServers" -ZoneScope "SpecialZoneScope,1" -ZoneName "test.local"

Results:

nslookup from "regular" client:

> HostA.test.local
Server:  dns.test.local
Address:  ****

Name:    HostA.test.local
Address:  1.1.1.1

> HostB.test.local
Server:  dns.test.local
Address:  ****

Name:    HostB.test.local
Address:  1.1.1.1.2

Both records from the "default" zonescope are returned correctly.

nslookup from client in the "special" subnet:

> HostA.test.local
Server:  dns.test.local
Address:  ****

Name:    HostA.test.local
Address:  20.20.20.1

> HostB.test.local
Server:  dns.test.local
Address:  ****

*** dns.test.local can't find HostB.test.local: Non-existent domain

HostA is resolved with the alternative IP from the SpecialZoneScope as intended, HostB is not resolved at all.

2

Yes, you can definitely do this. You did everything right except that you forgot to restrict the Query Resolution Policy to the specific records that are in the Zone Scope. You do this by way of the -FQDN parameter as shown below.

Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action ALLOW -FQDN "eq,HostA.test.local" -ClientSubnet "eq,SpecialServers" -ZoneScope "SpecialZoneScope,1" -ZoneName "test.local"

Explanation

You're trying to think of the zone scope as a sort of "transparency" overlayed on the original zone, but in fact it is not.

It's an opaque alternative zone (kind of like an alternate data stream on a file). A query against that zone scope will never "fall back" onto the default zone.

Therefore, when you create a Query Resolution Policy, you are defining the rules by which a particular query chooses a zone scope.

By defining a zone scope with only 1 record HostA, and then defining a QRP that sends all queries from certain IPs to that zone, you are effectively saying they can only see that record.

Adding the FQDN to the QRP means that only clients from the specified subnet(s) who are also querying HostA.test.local, will be sent to the alternate zone scope.

Of course you need to specify multiple records or make multiple QRPs if you have more in the zone. You can also use wildcards.

| improve this answer | |
  • Thank you for great explanation, that filtering by FQDN solves my problem! – StepCZ Mar 6 '18 at 19:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.