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

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

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

Другими словами, я хочу создать своего рода "перезапись 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 не разрешается вообще.

Источник

1 ответ

Решение

Да, вы определенно можете сделать это. Вы сделали все правильно, за исключением того, что вы забыли ограничить Политику разрешения запросов конкретными записями, которые находятся в области действия зоны. Вы делаете это посредством -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-адресов в эту зону, вы фактически говорите, что они могут видеть только эту запись.

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

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

Источник
Другие вопросы по тегам