W jaki sposób system Windows Server DNS korzysta z pliku hosts, aby rozpoznać określone nazwy hostów

[UWAGA: Rozwiązanie tego pytania jest idealne, ponieważ coś odbiega od tego, co wskazuje tytuł.]

Mam do czynienia z małym problemem Windows Server 2003 DNS service. W mojej korporacji korzystam z serwera Microsoft DNS ( 172.16.0.12), aby wykonać rozpoznawanie nazw w intranecie mojej firmy (nazwa domeny kończy się na dev.nls. Rozwiązuje się na IP 172.16 . ), A także jest skonfigurowana jako usługa przesyłania dalej DNS do przekazywania innych nazw domen ( np. * .google.com, * .sf.net) do Internet real DNS servers. Ten wewnętrzny serwer DNS nigdy nie obsługuje użytkowników spoza świata.

Ponadto obsługujemy serwer pocztowy (obsługujący pocztę przychodzącą dla prawdziwej domeny internetowej @nlscan.com) w zaporze firmowej, do której można uzyskać dostęp w dowolny sposób:

1. łącząc się 172.16.0.10z intranetem.
2. łącząc się z Internetem mail.nlscan.com(rozwiązany 202.101.116.9).

Zauważ, że 172.16.0.10i 202.101.116.9to nie jest ta sama fizyczna maszyna. Ten 202jest zaporą ogniową, która przekierowuje port 25i 110adres intranetowy 172.16.0.10.

Teraz moje pytanie: jeśli użytkownicy wewnątrz korporacyjnej sieci LAN chcą rozwiązać mail.nlscan.com, rozwiązuje to 202.101.116.9. Jest to poprawne i wykonalne, ALE NIE DOBRE, ponieważ ruch pocztowy dociera do maszyny zapory ogniowej, a następnie do niej podskakuje 172.16.0.10. Mam nadzieję, że internal DNS servermożemy przechwycić nazwę mail.nlscan.comi rozwiązać ją na 172.16.0.10. Mam więc nadzieję, że w tym celu mogę napisać wpis w pliku „hosts” 172.16.0.12. Ale jak Microsoft DNS serverrozpoznać ten plik „hostów”?

Może sugerujesz, dlaczego użytkownik intranetu nie korzysta 172.16.0.10z mojego serwera poczty? Muszę powiedzieć, że jest to niewygodne, załóżmy, że użytkownik (pracownik) pracuje na swoim laptopie, w dzień w biurze i w nocy w domu. Kiedy jest w domu, nie może korzystać 172.16.0.10.

Utworzenie strefy dla nlscan.comnaszego wewnętrznego DNS servernie jest możliwe, ponieważ serwer nazw dla nlscan.comdomeny znajduje się u naszego usługodawcy internetowego i jest odpowiedzialny za rozwiązywanie innych nazw hostów i subdomen pod nlscan.com.

[EDYTOWAĆ]

Jak WesleyDavidzasugerował, śledzę rozwiązanie wystarczy utworzyć strefę o nazwie mailserver.nlscan.comi umieścić zapis bezimienny A w tej strefie . Czas pokazuje, że to działa dobrze.

Druga część tego postu jest nieprawidłowa. Byłem pod wrażeniem, na podstawie niektórych rzeczy, które przeczytałem w Internecie (jeśli jest w Internecie, to musi być prawda!), Że częścią zadań Windows Server Server Service związanych z tworzeniem pamięci podręcznej było również załadowanie pliku hosta do pamięć podręczna wraz z danymi strefy lokalnej. Rozejrzałem się i nie mogłem znaleźć na to twardych dowodów. Testowałem teorię na moim własnym serwerze Server 2008 R2 i stwierdziłem, że plik hosts nie został użyty do zbudowania pamięci podręcznej serwera DNS.

Uważam jednak, że mam nieco bardziej eleganckie rozwiązanie niż Massimo. Zamiast tworzyć autorytatywną strefę dla całej strefy nlscan.com, po prostu utwórz strefę o nazwie mailserver.nlscan.com i umieść bezimienny rekord A w tej strefie. Rekord bezimienny A będzie miał taką samą nazwę jak sama strefa i możesz nadać mu pożądany adres IP. Wszystkie inne domeny pod nlscan.com, a także sama nlscan.com zostaną rozpoznane przez publiczny DNS.

Właśnie przetestowałem to na własnym serwerze DNS Server 2008 R2 i udało mi się rozwiązać witrynę mojego przyjaciela (nessus.nl) za pośrednictwem publicznych serwerów DNS, ale konkretna subdomena (blog.nessus.nl) rozwiązała adres IP Apple.com . Wypróbuj i sprawdź, czy to działa dla Ciebie.

Rozpoczyna się starszy, zły post:

Jeśli moje zrozumienie jest poprawne (EDYCJA: i nie jest), po wbudowaniu pamięci podręcznej DNS na komputerze z serwerem Server 2003 pobiera wpisy z pliku hosts, a także dane strefy. Umieszczenie 172.16.0.10 mailserver.nlscan.comw pliku hosts komputera serwera Server 2003 powinno rozwiązać problem. Uruchom ponownie usługi DNS po zmianie pliku hosts.

Użyj ipconfig / displaydns na dowolnym komputerze z systemem Windows (w szczególności na serwerze DNS Server 2003), aby zobaczyć wpisy plików hosta. Pamiętaj również, że negatywne odpowiedzi są buforowane w twoich klientach, więc zawsze uruchamiaj ipconfig / flushdns na klientach, z którymi eksperymentujesz. W przeciwnym razie skończysz nadużywanie różnych twardych obiektów, ponieważ zastanawiasz się, dlaczego Twoi klienci nie mogą rozwiązać nazwy, którą właśnie wprowadziłeś do pliku strefy / hostów. =)

Próbowałeś tego i nie udało ci się?

Pragnienie, aby użytkownicy wewnętrzni otrzymywali wewnętrzne adresy IP zasobów, podczas gdy użytkownicy zewnętrzni otrzymywali adresy IP tych samych zasobów, jest powszechne. Jest to określane jako DNS podzielonego mózgu. Masz jeden serwer DNS skierowany w stronę Internetu i inny wewnętrzny serwer DNS dla lokalnych użytkowników. Użytkownicy wewnętrzni używają DHCP w sieci, a na serwerze DHCP reklamujesz wewnętrzny serwer DNS. Gdy użytkownicy będą poza biurem, ich serwer DHCP przypisze ich do serwera DNS, który będzie wiedział tylko o strefie zewnętrznej.

Wydaje się, że chcesz podzielić DNS mózgu bez faktycznego hostowania strefy wewnętrznie. Sugerujesz, że wewnętrzne hostowanie strefy jest problematyczne, ponieważ nie chcesz, aby użytkownicy uzyskiwali wewnętrzny adres IP, gdy pracują z domu, ale to nie ma sensu, ponieważ kiedy są w domu, otrzymują adres IP z innego serwera DHCP które nie będą reklamować twojego wewnętrznego serwera DNS. Zamierza zareklamować serwer DNS swojego dostawcy ISP, który będzie wiedział tylko o twojej strefie zewnętrznej, a tym samym zapewni im tylko zewnętrzne adresy IP.

Wreszcie, nie sądzę, że odniesiesz sukces, prosząc serwer DNS o podanie rekordów z pliku hosts na serwerze DNS. Serwer DNS obsługuje rekordy z plików strefy. Plik hostów lokalnych na tym serwerze DNS propaguje wpisy do pamięci podręcznej rozwiązania klienta lokalnego, która ma zastosowanie tylko do wyszukiwania na tym komputerze. Wpisy te nie są obsługiwane przez serwer DNS, który jest innym mechanizmem.

Przeczytaj o podzielonym mózgu DNS - jest to normalny sposób radzenia sobie z tą sytuacją.

Wes: Nie jestem pewien, kto cię zadzwonił, ale chciałbym wyjaśnić sposób użycia pliku hosts: plik hosts jest używany przez komponent tłumaczący klienta DNS, a nie serwer DNS. Wpis w pliku hosts na serwerze DNS będzie używany przez serwer DNS, gdy działa on jako klient DNS. Na przykład wpis w pliku hostów mojego serwera DNS W2K8, taki jak ten:

1.1.1.1 test.test.com

jest ładowany do pamięci podręcznej klienta DNS serwera DNS (nie jest to pamięć podręczna serwera). Jeśli wyślę ping test.test.com z mojego serwera DNS, zwraca 1.1.1.1 zgodnie z oczekiwaniami. Jeśli następnie uruchomię nslookup na serwerze DNS i poproszę go o test.test.com, zwróci prawidłowy publiczny adres IP zarejestrowany dla test.test.com, ponieważ składnik klienta DNS na serwerze DNS prosi teraz składnik serwera DNS o rozstrzygnięcie (tak jak każdy inny klient DNS). Jest to mylący pomysł, aby owinąć głowę, ale serwer DNS jest również klientem DNS, a gdy składnik klienta DNS jest wywoływany do działania, działa jak każdy inny klient DNS, patrząc na swoją własną pamięć podręczną klienta DNS, w tym wszelkie wpisy wcześniej -loaded z pliku hosts. Tylko wtedy, gdy składnik klienta DNS korzysta ze składnika serwera DNS (poprzez zapytanie do skonfigurowanych w nim serwerów DNS)

Każdy klient DNS wysyłający zapytanie do serwera DNS zawsze otrzyma „prawdziwą” odpowiedź, a nie wpis hosta, ponieważ pamięć podręczna klienta DNS serwera DNS jest używana przez sam serwer (jako klient DNS), a nie przez składnik serwera DNS.

O ile mi wiadomo, nie ma sposobu, aby Windows DNS używał hostspliku do obsługi rozpoznawania nazw; ale to nie jest potrzebne.

Możesz bezpiecznie utworzyć strefę na wewnętrznym serwerze DNS o tej samej nazwie co publiczna strefa internetowa; co się stanie, Twój serwer będzie obsługiwał żądania nazw w tej strefie przy użyciu własnych danych, zamiast przekazywać te żądania do autorytatywnych serwerów nazw dla tej strefy; jest to czasami nazywane „shadowingiem”, ponieważ powoduje, że „prawdziwa” strefa publiczna jest niedostępna dla klienta wewnętrznego, odpowiadając zamiast tego „fałszywymi” danymi.

Należy uważać na to, aby wypełnić tę wewnętrzną strefę wszystkimi potrzebnymi nazwami, nawet w razie potrzeby używając publicznych adresów IP; w przeciwnym razie klienci wewnętrzni nie będą w stanie rozpoznać tych nazw.

Powiedzmy, że Twoja strefa publiczna wygląda następująco:

www.nlscan.com    202.101.116.8
mail.nlscan.com   202.101.116.9

Chcesz, aby klienci wewnętrzni rozpoznawali mail.nlscan.com jako 172.16.0.10; to dobrze, więc tworzysz strefę „nlscan.com” na wewnętrznym serwerze DNS i umieszczasz w niej „mail.nlscan.com -> 172.16.0.10”.
Ale teraz Twoi wewnętrzni klienci nie mogą rozpoznać „www.nlscan.com”, ponieważ serwer uważa, że ​​jest autorytatywny dla tej strefy, więc nie odpowie na zapytanie (ponieważ nie wie o tym hoście), ale także nie przekaże go nikomu.
Aby rozwiązać ten problem, musisz umieścić „www.nlscan.com” również w swojej strefie wewnętrznej; może wskazywać na swój prawdziwy publiczny adres IP, jeśli chcesz, aby Twoi klienci mieli do niego dostęp w ten sposób, lub możesz użyć tego samego przekierowania, którego używasz dla „mail.nlscan.com”, jeśli „www” jest również przekazywany przez zaporę ogniową na jakiś wewnętrzny serwer.
Ta sama zasada dotyczy każdej nazwy w strefie.

Ta konfiguracja nie będzie miała wpływu na klientów zewnętrznych ani na użytkowników, którzy tymczasowo znajdują się poza siecią, ponieważ ta wewnętrzna strefa „cienia” nigdy nie będzie widoczna z Internetu.

Niezależnie od pliku hosta, po prostu dodaj nową strefę w DNS mail.domain.com i dodaj hosta w strefie. pozostaw nazwę pustą (automatycznie użyje nazwy strefy) i wprowadź adres IP lokalnego serwera pocztowego ;-)