Posso usar as políticas de DNS do servidor 2016 para retornar IPs alternativos, mas apenas para alguns registros em um domínio?

Question

Eu preciso fornecer um tipo de cenário de divisão de DNS do DNS com dois objetivos principais:

1. clientes DNS "especiais" (com base em sua sub-rede) devem resolver determinados registros A em um domínio para endereços IP diferentes do que o restante dos clientes
2. todos os outros registros no mesmo domínio devem ser resolvidos igualmente, independentemente de qual cliente está perguntando.

Em outras palavras, quero criar uma espécie de "reescrita de DNS" ou sobreposição, em que poucos registros serão diferentes para alguns clientes. Eu esperava conseguir isso através de políticas de DNS no Server 2016, que descrevem "split brain / horizon" como um dos cenários pretendidos, por ex. link - mas parece que não consigo atingir o objetivo 2.

Em meus testes, criei um ZoneScope com endereços IP alternativos a serem retornados para clientes correspondidos e uma política de resolução de consulta baseada na sub-rede do cliente, atingindo a meta 1). MAS, se um cliente for combinado para ser da sub-rede "especial", ele é capaz de resolver APENAS registros do ZoneScope especial, mas não do escopo "padrão" - portanto, a meta de falha 2.

Existe talvez uma etapa de configuração que eu perdi que permitiria fallback para o ZoneScope padrão no caso de meu zonescope especial não conter um registro correspondente? Soube que isso pode ser feito facilmente com o DNS do BIND com a Política de Zona de Resposta, mas eu gostaria de manter o MS, se possível. Também não é possível usar arquivos hosts, pois esses servidores "especiais" não estão totalmente sob nosso controle.

Etapas para reproduzir

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

Resultados:

nslookup do cliente "regular":

> 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

Ambos os registros do zonescope "padrão" são retornados corretamente.

nslookup do cliente na sub-rede "especial":

> 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 é resolvido com o IP alternativo do SpecialZoneScope como pretendido, HostB não é resolvido de todo.

    

Answer 1

Sim, você pode definitivamente fazer isso. Você fez tudo certo, exceto que esqueceu de restringir a Política de Resolução de Consulta aos registros específicos que estão no Escopo da Zona. Você faz isso por meio do parâmetro -FQDN , conforme mostrado abaixo.

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

Explicação

Você está tentando pensar no escopo da zona como uma espécie de "transparência" sobreposta na zona original, mas na verdade não é.

É uma zona alternativa opaca (como um fluxo de dados alternativo em um arquivo). Uma consulta contra esse escopo de zona nunca "voltará" à zona padrão.

Portanto, quando você cria uma Política de Resolução de Consulta, está definindo as regras pelas quais uma consulta específica escolhe um escopo de zona.

Definindo um escopo de zona com apenas 1 registro HostA e, em seguida, definindo um QRP que envia todas as consultas de determinados IPs para essa zona, você está efetivamente dizendo que só pode ver esse registro.

Adicionar o FQDN ao QRP significa que apenas os clientes da (s) sub-rede (s) especificada (s) que também estão consultando HostA.test.local serão enviados para o escopo da zona alternativa.

É claro que você precisa especificar vários registros ou fazer múltiplos QRPs se tiver mais na zona. Você também pode usar curingas.