Могу ли я использовать политики DNS сервера 2016 для возврата альтернативных IP-адресов, но только для некоторых записей в домене?

Мне нужно предоставить своего рода сценарий разделения мозга DNS с двумя ключевыми целями:

«специальные» DNS-клиенты (в зависимости от их подсети) должны разрешать определенные записи A в одном домене на IP-адреса, отличные от IP-адресов остальных клиентов.
все другие записи в том же домене должны разрешаться одинаково, независимо от того, какой клиент запрашивает.

Другими словами, я хочу создать своего рода «перезапись DNS» или наложение, где несколько записей будут отличаться для некоторых клиентов. Я надеялся добиться этого с помощью политик DNS в Server 2016, которые описывают «разделение мозга / горизонта» как один из предполагаемых сценариев, например https://blogs.technet.microsoft.com/networking/2015/05/12/split-brain-dns-deployment-using-windows-dns-server-policies/ - но, похоже, я не могу достичь цели 2.

В своем тестировании я создал ZoneScope с альтернативными IP-адресами, которые должны быть возвращены согласованным клиентам, и политикой разрешения запросов на основе клиентской подсети, достигнув цели 1). НО, если соответствует клиенту из «специальной» подсети, он может разрешать ТОЛЬКО записи из специальной зоны ZoneScope, но не из области «по умолчанию» - так что не удается достичь цели 2.

Возможно, я пропустил шаг конфигурации, который позволил бы вернуться к ZoneScope по умолчанию в случае, если моя специальная zonecope не содержит соответствующей записи? Мне сказали, что это можно легко сделать с помощью BIND DNS с политикой зоны ответа, но я хотел бы придерживаться MS, если это вообще возможно. Также невозможно использовать файлы hosts, так как эти «специальные» серверы не полностью находятся под нашим контролем.

Действия по воспроизведению

#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"

Полученные результаты:

nslookup из "обычного" клиента:

> 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

Обе записи из зоны "по умолчанию" возвращаются правильно.

nslookup от клиента в "специальной" подсети:

> 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 разрешается с альтернативным IP-адресом из SpecialZoneScope, как и предполагалось, HostB не разрешается вообще.

Да, вы определенно сможете это сделать. Вы все сделали правильно, за исключением того, что забыли ограничить политику разрешения запросов конкретными записями, которые находятся в области действия зоны. Вы делаете это с помощью -FQDN параметр, как показано ниже.

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

Объяснение

Вы пытаетесь представить себе область видимости зоны как своего рода «прозрачность», наложенную на исходную зону, но на самом деле это не так.

Это непрозрачная альтернативная зона (вроде как альтернативный поток данных в файле). Запрос к области этой зоны никогда не «откатится» к зоне по умолчанию.

Следовательно, когда вы создаете политику разрешения запросов, вы определяете правила, по которым конкретный запрос выбирает область действия зоны.

Определив область зоны только с 1 записью HostA, а затем определяя QRP, который отправляет все запросы с определенных IP-адресов в эту зону, вы фактически говорите, что они могут видеть только эту запись.

Добавление FQDN в QRP означает, что только клиенты из указанных подсетей, которые также запрашивают HostA.test.local, будет отправлено в область действия альтернативной зоны.

Конечно, вам нужно указать несколько записей или сделать несколько QRP, если у вас их больше в зоне. Вы также можете использовать подстановочные знаки.