To wzbudziło moją ciekawość - a także +1 za wnikliwe pytanie - dlatego stworzyłem szybkie laboratorium, aby to sprawdzić:
Win2012-DC
: Windows Server 2012 R2, awansowany na kontroler domeny dla nowego test.local
lasu / domeny.
Win2016-DC
: Windows Server 2016, promowany jako 2. kontroler domeny dla powyższej test.local
domeny.
Na dzień dzisiejszy wszystko jest w pełni załatane i aktualne (29.10.2016). Poziom funkcjonalny zarówno lasu, jak i domeny to 2012 R2. Oba serwery zostały również skonfigurowane jako serwery DNS dla tej domeny testowej.
Podsumowując, wyniki wydają się być takie, jak później przewidziałeś:
Starsze kontrolery domeny ignorują nowe atrybuty i reagują w jakiś „domyślny” sposób (nie zastosowano zasad), podczas gdy nowe kontrolery reagują zgodnie z polityką.
Przeglądałem większość scenariuszy udokumentowanych pod https://technet.microsoft.com/en-us/windows-server-docs/networking/dns/deploy/dns-policies-overview . Dla zwięzłości, poniżej znajdują się szczegóły 2 konkretnych scenariuszy:
Blokuj zapytania dla domeny
To działa bez problemu na DC 2016 - ale DC 2012 oczywiście nawet nie rozpoznaje polecenia:
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicy" -Action IGNORE -FQDN "EQ,*.treyresearch.com"
Podczas wystawiania zapytania DNS dla www.treyresearch.com
DC 2016 nie udzielono odpowiedzi i upłynął limit czasu żądania. Gdy to samo zapytanie zostanie wydane przeciwko DC 2012, nie ma on wiedzy na temat zasad i zapewnia oczekiwaną odpowiedź składającą się z rekordu A.
Równoważenie obciążenia aplikacji z rozpoznaniem położenia geograficznego
Polecenia programu PowerShell zawarte w artykule w celach informacyjnych:
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
Wyniki tutaj są prawie „gorsze” niż powyższe: Po www.contosogiftservices.com
skutecznej rejestracji tylko przez polis, DC 2012 nic o tym nie wie i zwraca NXDOMAIN. (W www
tradycyjnej konsoli zarządzania DNS na serwerze 2012 lub 2016 nie widać żadnego rekordu.) Serwer 2016 odpowiada zgodnie z powyższymi zasadami.
Podsumowanie
Nie widzę tu nic, co uniemożliwia korzystanie z funkcji 2016 w domenie o niższym poziomie funkcjonalności. Najprostszą i najmniej mylącą opcją byłoby prawdopodobnie po prostu zaprzestanie używania pozostałych kontrolerów domeny 2012 jako serwerów DNS, jeśli to możliwe. W przypadku ryzyka dodatkowej złożoności możesz skierować serwery obsługujące zasady 2016 do określonych potrzeb, takich jak zasady rekurencyjne, aby wesprzeć (ograniczony) scenariusz wdrażania z podziałem mózgu.