Esto captó mi curiosidad, y también +1 para una pregunta perspicaz, así que construí un laboratorio rápido para probar esto:
Win2012-DC
: Windows Server 2012 R2, promovido a controlador de dominio para un nuevo test.local
bosque / dominio.
Win2016-DC
: Windows Server 2016, promovido como un segundo controlador de dominio para el test.local
dominio anterior .
Todo está totalmente actualizado y actualizado a partir de hoy (29/10/2016). El nivel funcional tanto para el bosque como para el dominio es 2012 R2. Ambos servidores también se configuraron como servidores DNS para este dominio de prueba.
En resumen, los resultados parecen ser como más adelante previó:
Los DC más antiguos ignoran los nuevos atributos y responden de alguna manera "predeterminada" (sin política aplicada), mientras que los nuevos DC responderían de acuerdo con la política.
Revisé la mayoría de los escenarios documentados en https://technet.microsoft.com/en-us/windows-server-docs/networking/dns/deploy/dns-policies-overview . Para abreviar, los siguientes son los detalles de 2 escenarios específicos:
Bloquear consultas para un dominio
Esto se ejecuta sin problemas en el DC 2016, pero el DC 2012 obviamente ni siquiera reconoce el comando:
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicy" -Action IGNORE -FQDN "EQ,*.treyresearch.com"
Al emitir una consulta DNS para www.treyresearch.com
el DC 2016, no se da respuesta y el tiempo de espera de la solicitud. Cuando se emite la misma consulta contra el DC 2012, no tiene conocimiento de la política y proporciona una respuesta esperada que consiste en el registro A ascendente.
Equilibrio de carga de aplicaciones con conciencia de ubicación geográfica
Los comandos de PowerShell que se incluyen en el artículo como referencia:
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
Los resultados aquí son casi "peores" que los anteriores: con www.contosogiftservices.com
un registro efectivo solo por póliza, el DC 2012 no sabe nada al respecto y devuelve un NXDOMAIN. (No hay www
registro visible en la consola de administración de DNS tradicional en el servidor 2012 o 2016). El servidor 2016 responde según lo configurado por las políticas anteriores.
Resumen
No veo nada aquí que impida el uso de las funciones de 2016 en un dominio con un nivel funcional menor. La opción más simple y menos confusa probablemente sería simplemente dejar de usar cualquier DC 2012 restante como servidores DNS, si es posible. A riesgo de una cierta complejidad adicional, podría apuntar a los servidores 2016 compatibles con políticas para necesidades específicas, como las políticas de recursión para admitir un escenario de implementación de cerebro dividido (limitado).