Могу ли я использовать политики 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"
Объяснение
Вы пытаетесь представить себе область действия зоны как своего рода «прозрачность», наложенную на исходную зону, но на самом деле это не так.
Это непрозрачная альтернативная зона (вроде как альтернативный поток данных в файле). Запрос к этой области зоны никогда не «откатится» к зоне по умолчанию.
Следовательно, когда вы создаете политику разрешения запросов, вы определяете правила, по которым конкретный запрос выбирает область зоны .
Определяя область зоны только с одной записью HostA , а затем определяя QRP, который отправляет все запросы с определенных IP-адресов в эту зону, вы фактически говорите, что они могут видеть только эту запись.
Добавление FQDN к QRP означает, что только клиенты из указанных подсетей, которые также запрашивают HostA.test.local , будут отправлены в область альтернативной зоны.
Of Конечно, вам нужно указать несколько записей или сделать несколько QRP, если у вас их больше в зоне. Вы также можете использовать подстановочные знаки.