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

10

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!

briantist
źródło

Odpowiedzi:

4

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

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

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.

ziesemer
źródło
2
To fantastyczne , ponad wszystko, dziękuję!
briantist
Jest to ważne, aby ograniczyć ataki wzmocnienia DNS na zewnętrzne serwery nazw. Jestem pewien, że administratorzy denerwują się tym, co by się stało, gdy dodamy serwer DNS 2016 do niższego poziomu domeny funkcjonalnej. Jak zwykle Microsoft ma bardzo mało informacji na ten temat.
Brain2000,