As Políticas de DNS do Windows 2016 / DNS Dividido são possíveis em zonas integradas do AD com DCs mais antigos?

Question

O Windows Server 2016 suporta DNS Políticas , que fornecem suporte para o DNS com cérebro dividido entre outros cenários:

You can configure DNS policies to specify how a DNS server responds to DNS queries. DNS responses can be based on client IP address (location), time of the day, and several other parameters. DNS policies enable location-aware DNS, traffic management, load balancing, split-brain DNS, and other scenarios.

Eu li o Página Visão geral de políticas de DNS , mas parece que não consigo encontrar documentação em nenhum lugar sobre como isso funciona em uma zona integrada do AD quando nem todos os DCs ainda são servidores 2016.

Eu não posso imaginar que funcionaria muito bem, já que os servidores de nível inferior não sabem interpretar políticas e agir de acordo, mas como as informações são replicadas no AD, posso prever uma situação em que os DCs antigos ignoram o novo atribui e responde de alguma forma "padrão" (sem política aplicada), enquanto os novos DCs responderiam de acordo com a política.

Acho que seria aceitável em determinadas situações em que você pode (ou já faz) ter clientes apontando para um subconjunto de DCs, pois isso pode fornecer uma maneira de usar os recursos mais recentes sem atualizar todos os DCs de uma só vez.

Mas, não consigo encontrar nenhuma informação sobre se o que eu descrevi é como ele realmente funciona, ou se você não pode usar os novos recursos em um ambiente misto, ou algo entre os dois.

Aviso

Recentemente descobri que o Os parâmetros -WhatIf , -Verbose e -ErrorAction são divididos nos cmdlets da Diretiva de DNS; vote aqui para corrigir isso . E tenha cuidado!

    

Answer 1

Isso pegou minha curiosidade - e também o +1 por uma pergunta perspicaz - e criei um laboratório rápido para testar isso:

• Win2012-DC : Windows Server 2012 R2, promovido a controlador de domínio para um novo test.local forest / domain.
• Win2016-DC : Windows Server 2016, promovido como um segundo controlador de domínio para o domínio test.local acima.

Tudo está totalmente atualizado e atualizado até hoje (2016-10-29). O nível funcional para a floresta e o domínio é 2012 R2. Ambos os servidores também foram configurados como servidores DNS para esse domínio de teste.

Em resumo, os resultados parecem ser os que você previu mais tarde:

Older DCs ignore the new attributes and respond in some "default" way (no policy applied), while the new DCs would respond according to policy.

Corri a maioria dos cenários documentados em link . Por questões de brevidade, seguem os detalhes de dois cenários específicos:

Bloquear consultas para um domínio

• link

Isso é executado sem problemas no DC 2016 - mas o DC 2012 obviamente nem reconhece o comando:

Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicy" -Action IGNORE -FQDN "EQ,*.treyresearch.com"

Ao emitir uma consulta de DNS para www.treyresearch.com no DC 2016, nenhuma resposta é dada e o tempo limite da solicitação é excedido. Quando a mesma consulta é emitida contra o DC de 2012, ela não tem conhecimento da política e fornece uma resposta esperada que consiste no registro A do upstream.

Balanceamento de carga de aplicativos com reconhecimento geo-local

• link
  • (saiba que todos os escopos de zona diferentes de Dublin e Amsterdã foram criados em subpáginas anteriores de link - portanto, se começar nesta página, os escopos da zona ausente precisarão ser criados ou o último comando Add-DnsServerQueryResolutionPolicy será alterado para ignorá-los.)

Os comandos do PowerShell incluídos no artigo para referência:

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "DublinZoneScope"
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "AmsterdamZoneScope"
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "151.1.0.1" -ZoneScope "DublinZoneScope”
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "141.1.0.1" -ZoneScope "AmsterdamZoneScope"
Add-DnsServerQueryResolutionPolicy -Name "AmericaLBPolicy" -Action ALLOW -ClientSubnet "eq,AmericaSubnet" -ZoneScope "SeattleZoneScope,2;ChicagoZoneScope,1; TexasZoneScope,1" -ZoneName "contosogiftservices.com" –ProcessingOrder 1
Add-DnsServerQueryResolutionPolicy -Name "EuropeLBPolicy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -ZoneScope "DublinZoneScope,1;AmsterdamZoneScope,1" -ZoneName "contosogiftservices.com" -ProcessingOrder 2
Add-DnsServerQueryResolutionPolicy -Name "WorldWidePolicy" -Action ALLOW -FQDN "eq,*.contoso.com" -ZoneScope "SeattleZoneScope,1;ChicagoZoneScope,1; TexasZoneScope,1;DublinZoneScope,1;AmsterdamZoneScope,1" -ZoneName "contosogiftservices.com" -ProcessingOrder 3

Os resultados aqui são quase "piores" do que os acima: Com www.contosogiftservices.com efetivamente registrado apenas pela política, o DC 2012 não sabe nada sobre isso e retorna um NXDOMAIN. (Nenhum registro de www é visível no console de gerenciamento de DNS tradicional no servidor de 2012 ou 2016.) O servidor de 2016 responde conforme configurado pelas políticas acima.

Resumo

Não vejo nada aqui que impeça o uso dos recursos de 2016 em um domínio com um nível funcional menor. A opção mais simples e menos confusa provavelmente seria simplesmente parar de usar os DCs restantes de 2012 como servidores DNS, se possível. Com o risco de alguma complexidade adicional, você poderia direcionar os servidores de suporte a políticas de 2016 para necessidades específicas, como políticas de recursão para dar suporte a um cenário de implantação de cérebro dividido (limitado).