As diretivas DNS do Windows 2016 / DNS dividido são possíveis em zonas integradas ao AD com controladores de domínio antigos?

10

O Windows Server 2016 oferece suporte a diretivas DNS , que fornecem suporte para DNS de cérebro dividido entre outros cenários:

Você pode configurar políticas de DNS para especificar como um servidor DNS responde às consultas de DNS. As respostas DNS podem se basear no endereço IP do cliente (local), hora do dia e vários outros parâmetros. As políticas de DNS permitem DNS com reconhecimento de local, gerenciamento de tráfego, balanceamento de carga, DNS de cérebro dividido e outros cenários.

Li a página Visão geral das políticas de DNS, mas não consigo encontrar documentação em nenhum lugar sobre como isso funciona em uma zona integrada ao AD, quando nem todos os controladores de domínio ainda são o Server 2016.

Não posso imaginar que funcionaria tão bem, pois 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 controladores de domínio mais antigos ignoram os novos atributos e respondem de alguma maneira "padrão" (nenhuma política aplicada), enquanto os novos CDs responderiam de acordo com a política.

Eu acho que seria bom em certas situações em que você pode (ou já possui) clientes apontando para um subconjunto de controladores de domínio, pois isso pode fornecer uma maneira de usar os recursos mais novos sem atualizar todos os controladores de domínio de uma só vez.

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


Aviso

Eu descobri recentemente que os -WhatIf, -Verbose, e -ErrorActionparâmetros são quebrados nos cmdlets Política de DNS; vote aqui para consertar isso . E tenha cuidado!

briantist
fonte

Respostas:

4

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

  • Win2012-DC: Windows Server 2012 R2, promovido ao controlador de domínio para uma nova test.localfloresta / domínio.
  • Win2016-DC: Windows Server 2016, promovido como um segundo controlador de domínio para o test.localdomínio acima .

Tudo está totalmente corrigido e atualizado a partir de hoje (29/10/2016). O nível funcional para a floresta e o domínio é 2012 R2. Os dois servidores também foram configurados como servidores DNS para este domínio de teste.

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

DCs mais antigos ignoram os novos atributos e respondem de alguma maneira "padrão" (nenhuma política é aplicada), enquanto os novos DCs respondem de acordo com a política.

Passei pela maioria dos cenários documentados em https://technet.microsoft.com/en-us/windows-server-docs/networking/dns/deploy/dns-policies-overview . Por uma questão de brevidade, a seguir estão os detalhes de 2 cenários específicos:

Bloquear consultas para um domínio

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

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

Ao emitir uma consulta DNS www.treyresearch.comcontra o CD de 2016, nenhuma resposta é fornecida e a solicitação atinge o tempo limite. Quando a mesma consulta é emitida no CD de 2012, ela não tem conhecimento da diretiva e fornece uma resposta esperada que consiste no registro A upstream.

Balanceamento de carga de aplicativos com reconhecimento de localização geográfica

Os comandos do PowerShell, conforme incluído 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" que o acima: Com www.contosogiftservices.comefetivamente registrado apenas pela política, o CD de 2012 não sabe nada sobre isso e retorna um NXDOMAIN. (Nenhum wwwregistro é visível no console de gerenciamento DNS tradicional no servidor de 2012 ou 2016.) O servidor de 2016 responde conforme configurado pelas políticas acima.

Sumário

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 parar de usar os DCs restantes de 2012 como servidores DNS, se possível. Correndo o risco de uma complexidade adicional, você pode direcionar os servidores de 2016 para suporte a políticas 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).

ziesemer
fonte
2
Isso é fantástico , acima e além, obrigado!
Briantist
Isso é importante para limitar ataques de amplificação de DNS em servidores de nomes externos. Tenho certeza de que há administradores nervosos com o que aconteceria ao adicionar um servidor DNS de 2016 em um nível de domínio funcional mais baixo. Como de costume, a Microsoft tem muito pouca informação sobre isso.
Brain2000