Jaka powinna być kolejność serwerów DNS dla kontrolera domeny AD i dlaczego?


40

To jest pytanie kanoniczne dotyczące ustawień DNS usługi Active Directory.

Związane z:

Zakładając, że środowisko składa się z wielu kontrolerów domeny (załóżmy, że wszystkie one również uruchamiają DNS):

  • w jakiej kolejności serwery DNS powinny być wymienione w kartach sieciowych dla każdego kontrolera domeny?
  • Czy 127.0.0.1 powinno być używane jako podstawowy serwer DNS dla każdego kontrolera domeny?
  • Czy robi to jakąkolwiek różnicę, jeśli tak, to na jakie wersje to wpływa iw jaki sposób?

Odpowiedzi:


35

Zgodnie z tym łączem i analizatorem najlepszych praktyk systemu Windows Server 2008 R2 adres sprzężenia zwrotnego powinien znajdować się na liście, ale nigdy jako podstawowy serwer DNS. W niektórych sytuacjach, takich jak zmiana topologii, może to przerwać replikację i spowodować, że serwer będzie „na wyspie”, jeśli chodzi o replikację.

Załóżmy, że masz dwa serwery: DC01 (10.1.1.1) i DC02 (10.1.1.2), które są kontrolerami domeny w tej samej domenie i oba przechowują kopie stref ADI dla tej domeny. Powinny być skonfigurowane w następujący sposób:

DC01
Primary DNS   10.1.1.2
Secondary DNS 127.0.0.1

DC02
Primary DNS   10.1.1.1
Secondary DNS 127.0.0.1

Co ze środowiskiem z kontrolerem domeny i serwerem DNS ze strefą ADI? Czy DC powinno być nadal skonfigurowane jako pierwotne do wtórnego?
George

@George Nie podążam za tym, o co prosisz. Czy pytasz o środowisko z tylko jednym kontrolerem domeny?
MD Marra

Tak, to jest poprawne. Przepraszam, myślałem o dodaniu tego, ale pomyślałem, że może to rozwiązać pytanie. (Poza tym - dla przypomnienia wiem, że pojedyncze środowisko DC nie jest „idealną konfiguracją”)
George

2
W pojedynczym środowisku DC powinieneś po prostu używać DC bez dodatkowej wartości. Ma to na celu zmniejszenie problemów z replikacją, ale jeśli masz tylko jeden kontroler domeny, replikacja nie istnieje. Ale tak ... nie rób tego. Mają dwa DC.
MDMarra

Tak. W tej chwili nie ma „świetnego” środowiska. Ale, jak zapewne zauważyłeś na moje inne pytanie, na które odpowiedziałeś, rozwój jest w drodze, więc nowe domeny AD i czas na robienie rzeczy właściwie zły śmiech . Dzięki.
George

16

From http://technet.microsoft.com/en-us/library/ff807362%28v=ws.10%29.aspx

Jeśli adres IP sprzężenia zwrotnego jest pierwszym wpisem na liście serwerów DNS, usługa Active Directory może nie być w stanie znaleźć partnerów replikacji.

Włączenie własnego adresu IP na listę serwerów DNS poprawia wydajność i zwiększa dostępność serwerów DNS. Jeśli jednak serwer DNS jest również kontrolerem domeny i wskazuje tylko na siebie lub najpierw wskazuje na siebie w celu rozpoznania nazwy, może to spowodować opóźnienie podczas uruchamiania. Z tego powodu należy zachować ostrożność podczas konfigurowania adresu sprzężenia zwrotnego na adapterze, jeśli serwer jest również kontrolerem domeny. Adres sprzężenia zwrotnego powinien być skonfigurowany tylko jako pomocniczy lub trzeciorzędny serwer DNS na kontrolerze domeny.

Chcę również udostępnić ten fragment kodu z książki Windows Server 2008 R2 Unleashed :

wprowadź opis zdjęcia tutaj

Jednak nawet jeśli problem „wyspy” nigdy nie dotyczy Ciebie, Twój kontroler domeny nadal będzie uruchamiać się ponownie znacznie szybciej i przy mniejszej liczbie błędów, jeśli użyje innego, już działającego kontrolera domeny, jako podstawowego programu rozpoznawania nazw DNS.


Woah, problem z wyspą został rozwiązany? Dokumentacja MS dla 2008 R2 używała go jako odnośnika, a teraz magicznie zniknęła (zacytowałem go w dokumencie dla klienta, więc wiem, że nie jestem szalony!)
MDMarra

3
Cóż, powiedziałbym, że głównie to złagodzili, ale jak pokazuje ten artykuł, nadal wydaje się, że można znaleźć się w złym miejscu, jeśli masz jakieś bardzo szczególne okoliczności: support.microsoft.com/kb/2001093 Więc na koniec tego dnia prawdopodobnie będzie Ci dobrze z 127.0.0.1 jako podstawowym DNS na twoich nowoczesnych DC w domenie multi-DC. Osobiście widziałem bardzo duże domeny, które działały czysto, mimo że wszystkie ich kontrolery domeny były ustawione na 127.0.0.1 jako podstawowy DNS. Ale nadal nie jest to najlepsza praktyka. Po prostu róbcie to, co mówi wasze BPA, ludzie. ;)
Ryan Ries

5

Nigdy, nigdy nie używaj DC jako głównego DNS.

Wszelkiego rodzaju spustoszenie może (a Murphy dyktuje: nastąpi), jeśli usługi AD staną się online, zanim usługa DNS będzie aktywna po ponownym uruchomieniu. (Lub DNS ulega awarii, dostaje DOSsed, cokolwiek.)
Istnieje również interakcja między DHCP (z dynamicznymi aktualizacjami DNS) a DNS, która zależy w dużym stopniu od prawidłowego działania DNS.

Zawsze umieszczaj wartość 127.0.0.1 na końcu. Ponadto: nie ulegaj pokusie używania prawdziwego adresu IP serwera LAN.
Dynamiczne aktualizacje DNS z DHCP są bardzo wrażliwe na to.
(127.0.0.1 zawsze istnieje i można uzyskać do niego szybszy dostęp. Rzeczywisty adres IP może nie zawsze być dostępny / być zajęty. W niektórych scenariuszach dynamiczne aktualizacje DNS mogą faktycznie DOS adapter LAN, jeśli występuje duża liczba jednoczesnych żądań DHCP z podrzędną kartą sieciową / sterownikami).


Chociaż masz rację w sprawie prawie wszystkiego i istnieje milion powodów, aby mieć więcej niż jeden DC, nie jest to jeden z nich. Ta konfiguracja zapobiega problemom z replikacją. Jeśli nie masz potrzeby replikacji, nie musisz się martwić o zapobieganie problemom z replikacją.
MDMarra

@MDMarra: Masz rację co do interakcji replikacja / DNS ... Ale pierwotne pytanie było pytaniem ogólnym, a nie specyficznym dla replikacji. Bardziej myślałem o problemach z DHCP-DNS. Zwykle co najmniej jeden z kontrolerów domeny zapewnia również DHCP dynamiczne aktualizacje DNS. Wszelkiego rodzaju dziwności mogą wystąpić, jeśli DNS nie zostanie poprawnie skonfigurowany. Zaktualizuję moją odpowiedź, aby to wyjaśnić.
Tonny

1
W rzeczywistości jest to problem bezpieczeństwa, jeśli DHCP jest wdrożony na DC. jeśli to w ogóle możliwe, nie powinno być.
MDMarra

„Zawsze umieszczaj wartość 127.0.0.1 jako ostatnią”. Czy możesz wyjaśnić przyczyny tego stanu rzeczy?
Bigbio2002
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.