Czy zasady DNS systemu Windows 2016 / podział DNS są możliwe w strefach zintegrowanych AD ze starszymi kontrolerami domeny?

Windows Server 2016 obsługuje zasady DNS , które zapewniają obsługę DNS typu split-brain wśród innych scenariuszy:

Można skonfigurować zasady DNS, aby określić sposób, w jaki serwer DNS odpowiada na zapytania DNS. Odpowiedzi DNS mogą być oparte na adresie IP klienta (lokalizacji), porze dnia i kilku innych parametrach. Zasady DNS umożliwiają rozpoznawanie lokalizacji DNS, zarządzanie ruchem, równoważenie obciążenia, DNS z podziałem mózgu i inne scenariusze.

Przeczytałem stronę Przegląd zasad DNS, ale nigdzie nie mogę znaleźć dokumentacji na temat tego, jak to działa w strefie zintegrowanej z usługą AD, gdy nie wszystkie kontrolery domeny są jeszcze na serwerze 2016.

Nie wyobrażam sobie, aby działało to tak dobrze, ponieważ serwery niższego poziomu nie wiedzą, jak interpretować zasady i odpowiednio działać, ale ponieważ informacje są replikowane w AD, mogę przewidzieć sytuację, w której starsze kontrolery domeny ignorują nowe atrybuty i reagują w jakiś „domyślny” sposób (bez zastosowania polityki), podczas gdy nowe kontrolery domeny zareagują zgodnie z polityką.

Myślę, że byłoby to odpowiednie w niektórych sytuacjach, w których możesz (lub już) mieć klientów wskazujących na podzbiór kontrolerów domeny, ponieważ może to zapewnić sposób korzystania z nowszych funkcji bez uaktualniania wszystkich kontrolerów domeny jednocześnie.

Ale nie mogę znaleźć żadnych informacji na temat tego, czy opisałem, jak to naprawdę działa, czy nie możesz w ogóle korzystać z nowych funkcji w mieszanym środowisku, czy coś pomiędzy.

Ostrzeżenie

I niedawno odkryto, że -WhatIf, -Verbose, oraz -ErrorActionparametry są podzielone na cmdlets Ochrona DNS; głosuj tutaj, aby to naprawić . I bądź ostrożny!

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.locallasu / domeny.
• Win2016-DC: Windows Server 2016, promowany jako 2. kontroler domeny dla powyższej test.localdomeny.

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

• https://technet.microsoft.com/en-us/windows-server-docs/networking/dns/deploy/dns-policies-overview?#block-queries-for-a-domain

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.comDC 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

• https://technet.microsoft.com/en-us/windows-server-docs/networking/dns/deploy/app-lb-geo
  • (Uwaga: wszystkie zakresy stref inne niż Dublin i Amsterdam zostały utworzone na poprzednich podstronach https://technet.microsoft.com/en-us/windows-server-docs/networking/dns/deploy/dns-policy -scenario-guide - jeśli więc zaczniesz od tej strony, konieczne będzie utworzenie brakujących zakresów stref lub zmiana ostatniego Add-DnsServerQueryResolutionPolicypolecenia w celu ich zignorowania).

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.comskutecznej rejestracji tylko przez polis, DC 2012 nic o tym nie wie i zwraca NXDOMAIN. (W wwwtradycyjnej 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.