Poniższy rozdział opisuje:
§ Podstawowe serwery nazw. Serwery te są upoważnione do odpowiedzi na zapytania dotyczące strefy oraz stanowią źródło wszystkich danych adresowych strefy. Podrozdział ten opisuje cechy wyróżniające serwer podstawowy. Należy zwrócić uwagę, że podstawowy serwer nazw czasami nazywany jest również nadrzędnym (master). Nowa nazwa pochodzi ze zmian w pliku konfiguracyjnym BIND w wersji 8. We wszystkich miejscach w tym rozdziale, gdzie wymieniany jest serwer podstawowy, zamiennie można użyć określenia „serwer nadrzędny” (master).
§ Wtórne serwery nazw. Serwery wtórne są serwerami zapasowymi. Nie służą do składowania oryginalnych danych strefy, lecz mogą autorytatywnie odpowiadać na zapytania dotyczące domeny. Serwery wtórne zazwyczaj otrzymują dane strefy z podstawowego serwera DNS domeny. Serwer wtórny może być również nazywany podrzędnym (slave).
§ Buforujące serwery nazw. Jak wynika z nazwy, przechowują podręczne (buforowe) dane adresowe. Buforowanie jest typowym zachowaniem większości serwerów. Serwery takie przeznaczone są jedynie do buforowania zapytań. Nie posiadają pliku strefy zawierającego mnóstwa hostów i nie dokonują przesyłu strefy z innych serwerów DNS. Buforujące serwery nazw odpowiadają na zapytania, lecz nie w sposób autorytatywny. Podrozdział ten opisuje buforujące serwery nazw i przyczyny dla których są one wartościowe.
§ Przekazywanie zapytań: serwery przekazowe (forwarders) i podporządkowane (slaves). Serwery przekazowe i podporządkowane w bardzo specyficzny sposób współpracują z innymi serwerami DNS w podziale obowiązków w obsłudze zapytań. W tym podrozdziale opisane zostały serwery przekazowe i podporządkowane oraz możliwości projektowe jakie dają administratorom. Uwaga: pojęcie „serwerów podporządkowanych” nie ma nic wspólnego z uprzednio wspomnianymi serwerami podrzędnymi. Mówi się tutaj o opcji a nie rodzaju serwera.
§ Określanie typu serwera DNS. Jeśli czytelnik napotka serwer DNS którego roli nie zna, w tym podrozdziale przedstawione zostały metody rozróżnienia serwerów podstawowych, wtórnych, przekazowych, podporządkowanych i buforujących.
Serwer nazw w domenie może pełnić jedną rolę lub kilka naraz. Rozdział ten przedstawia przegląd możliwych ról. Należy pamiętać, że pojedynczy serwer DNS może obsługiwać równocześnie wiele domen, grając inną rolę w każdej z nich. Niektóre role, jak np. buforowanie, ustanawiane są z konieczności dla całego serwera. Wobec tego, typ serwera DNS określany jest według wyboru konfiguracji dla każdej domeny którą on obsługuje.
Oprócz opisu potencjalnych ról serwerów DNS, w rozdziale tym przedstawiono i przedyskutowano kilka możliwości architektur aby zilustrować różnice między serwerami podstawowymi, wtórnymi, przekazowymi, podporządkowanymi i buforującymi. Znacznie łatwiej jest zrozumieć je wszystkie w kontekście praktycznych problemów i zastosowań. Jedyną koniecznością jest ustanowienie podstawowego serwera DNS w każdej domenie. Reszta jest dowolna.
Podstawowe (nadrzędne) serwery są siłą napędową DNS, czynnikiem sprawczym dystrybucji i poszukiwania danych nazw w całym Internecie. Serwery podstawowe są zawsze oryginalnym źródłem danych adresowych. Posiadają absolutny autorytet jeśli chodzi o nazwy we własnej domenie, a ponieważ są pierwotnym źródłem plików strefy dla jej przesyłów, jedynie serwery podstawowe mogą określać informacje o domenie przekazywane do innych serwerów DNS potrzebujących ich. Serwer wtórny może również być „nadrzędnym” w przesyle strefy do innego wtórnego, lecz oryginalne pliki zawsze znajdują się na podstawowym. Ta niejasność nazewnicza została uporządkowana w RFC 2136, który rozróżnia serwery slave (podrzędny), master (nadrzędny) i primary master (podstawowy nadrzędny):
· Podrzędny. Serwer autorytatywny otrzymujący przesyły strefy i zapisany w strefie za pomocą rekordu NS.
· Nadrzędny. Serwer autorytatywny skonfigurowany jako źródło przesyłu danych dla jednego lub więcej serwerów podrzędnych.
· Podstawowy nadrzędny. Serwer nadrzędny w korzeniu grafu zależności przesyłów strefy. Serwer podstawowy nadrzędny określony jest w rekordzie SOA strefy. Z definicji, na jedną strefę przypada tylko jeden serwer podstawowy nadrzędny.
Proces publikacji rozpoczyna się w momencie gdy administrator ręcznie tworzy startowy plik konfiguracyjny (configuration boot file), kopiuje go z implementacji BIND DNS na hoście w systemie UNIX, albo, co jest bardziej prawdopodobne, wpisuje wszystkie startowe dane konfiguracyjne potrzebne serwerowi DNS za pomocą interfejsu zarządzania serwerem. Serwer DNS Windows 2000 automatycznie umieszcza wszelkie pliki konfiguracyjne w katalogu %windir%\system32\dns.
Informacje niezbędne do ręcznego skonfigurowania DNS-u to:
§ Nazwa domeny (musi być wstępnie zaakceptowana przez InterNIC jeśli musi być rozwiązywalna na zewnątrz naszej organizacji)
§ Adres IP i nazwa dla każdego serwera którego nazwa ma być rozwiązywalna
§ Nazwy hostów i adresy IP samych serwerów DNS
§ Nazwy hostów i adresy wszystkich komputerów które mają znaleźć się w strefie serwera DNS.
Rozdział 11 zawiera instrukcje instalacji i konfiguracji krok po kroku serwera DNS Windows 2000.
Startowe dane konfiguracyjne DNS mogą być zapisane w Windows na więcej niż jeden sposób: w pliku startowym lub w Rejestrze. Domyślnie, usługa uruchamiana jest z Rejestru. Aby zamiast tego skorzystać z pliku startowego, należy wybrać metodę uruchomienia Z pliku w menu Serwer DNS — Właściwości — Zaawansowane — [Ładuj dane strefy].
W przeciwieństwie do poprzednich wersji, serwer DNS Windows 2000 automatycznie uaktualnia Rejestr i plik startowy podczas wyboru lub zmiany metody uruchomienia (w poprzednich wersjach, synchronizacja była bardziej pracochłonna i często okazywała się bardziej męcząca niż przydatna). Odpowiadający klucz Rejestru to HKLM\System\CurrentControlSet\services\DNS. Efekty zmiany metody przechowywania danych opisane są w rozdziale 11.
W przypadku Windows 2000 możliwy jest dodatkowo wybór stref zintegrowanych z Active Directory, lecz jedynie dla stref podstawowych. Ponieważ serwery wtórne nie modyfikują danych, nie mają potrzeby bezpośredniego dostępu do podstawowego składu danych; wystarczą im tradycyjne przesyły danych. W przypadku stref podstawowych integracja z Active Directory oznacza, że dane strefy są przechowywane w samej pamięci Active Directory. Daje to bardziej solidne środki przechowywania i replikowania (przesyłu) danych. Jeśli korzysta się ze stref zintegrowanych z AD, wiele kontrolerów domeny może dzielić rolę serwera nadrzędnego dla danych strefy podstawowej. Integracja taka pozwala również na przydział uprawnień do czegokolwiek, zaczynając od kompletnych danych a kończąc na pojedynczym rekordzie zasobów (RR), co zwiększa bezpieczeństwo danych strefy.
Microsoft DNS Server może udostępnić pliki konfiguracyjne dla ograniczonej kompatybilności z plikami pochodzącymi z BIND-u pod systemem UNIX, głównie po to, aby ułatwić migrację do programu Microsoft DNS Server. Domyślną nazwą pliku buforowego (pamięci podręcznej DNS) w Windows 2000 jest CACHE.DNS.
Dane konfiguracyjne nie tylko określają katalog w którym serwer przechowuje dane – pliki strefy i podręczne. Zawierają również listę domen które obsługiwać ma serwer oraz wskazanie jakiego typu serwerem będzie on dla każdej domeny: podstawowym, wtórnym czy buforującym. Jeśli serwer korzysta z Active Directory, tam składowane będą dane strefy. Jeśli serwer jest typu podstawowego, startowe dane konfiguracji obejmują plik strefy dla każdej z domen tak określonej. Jeśli jest typu wtórnego, zawierają adres IP serwera nadrzędnego aby wiadomo było, skąd czerpać uaktualnienia.
W trakcie pracy serwera podstawowego, zmiany w domenie obejmują dodawanie i usuwanie hostów, poddomen, komputerów wymieniających pocztę, serwerów nazw i tak dalej. Jeśli do uruchamiania i użytkowania serwera stosowany jest plik startowy, zmian należy dokonywać jedynie w plikach źródłowych serwera podstawowego. Pliki startowe serwerów nazw są skonstruowane w sposób opisany poniżej (linie komentarza, zaczynające się od średnika [;], wstawiono aby objaśnić zapisy w pliku startowym):
; Katalog w którym backup.exe zapisuje pliki zapasowe
directory c:\winnt\system32\dns
; Wytyczne działania serwera nazw
; Typ serweraDomena Źródło
primary example.net hosts.db ; Do wyszukiwana w przód (nazwa na IP)
primary 1.168.192.in-addr.arpa hosts.rev; Do wyszukiwania w tył (IP na nazwę)
primary 0.0.127.in-addr.arpa hosts.local ; Dla komunikacji wewnętrznej
cache . cache ; Plik buforowy (nazwy i IP serwerów poz. głównego)
Powyższy przykład ma formę znajomą dla administratorów Uniksa. DNS Windows 2000 ignoruje w nim zmienną directory. W systemie Windows pliki, włącznie z plikiem podręcznym, zwykle mają rozszerzenie .DNS, o ile nie podano inaczej. Na razie proszę nie martwić się opcjami konfiguracji. Rozdział 11, zajmujący się instalacją, zawiera informacje potrzebne do zrozumienia tych opcji i podjęcia decyzji. Na szczęście, wiele ustawień wybieranych jest automatycznie za użytkownika.
Zmienna cache odnosi się do domeny głównej (.) a plik z danymi podręcznymi zwiera wpisy adresów podstawowych serwerów poziomu głównego. Plik ten jest instalowany z DNS Windows 2000, lecz najbardziej aktualną wersję można zawsze pobrać z serwera InterNIC pod adresem ftp://rs.internic.net/domain/named.root. Proszę pamiętać aby zmienić nazwę pliku na cache (poza tym, nie mylić pliku podręcznego poziomu głównego, root cache file z serwerami buforującymi, caching-only servers). Podany adres FTP jest miejscem z którego prawdopodobnie najłatwiej pobrać informacje.
Jedyną okazją przy której plik ten wymaga modyfikacji jest dodanie przez organizacje zarządzające Intenetem nowego serwera poziomu głównego (prawie nigdy), lub w przypadku gdy serwer DNS używany jest do użytku prywatnego w izolowanej sieci. Pliki te potrzebne są tylko w przypadku publicznego używania serwera dla szukania hostów w Internecie. Niektóre przedsiębiorstwa używają ustawień wewnętrznych i zewnętrznych dla potrzeb wewnętrznego rozwiązywania nazw i adresów internetowych; służą do tego często osobne serwery – zewnętrzne i wewnętrzne, na oddzielnych komputerach.
W poprzednim przykładzie przedstawiającym strukturę pliku startowego serwera nazw, plik host.db zawiera tablicę tekstową dla domeny example.net. Pik hosts.rev zawiera tablicę tekstową dla domeny 1.168.192.in-addr.arpa, w której znajdują się odwzorowania adresów internetowych (in-addr) z IP na nazwę hosta dla podsieci 192.168.1.0. Zapis directory — ignorowany — informuje uniksowy serwer nazw BIND o ścieżce dostępu do plików, c:\winnt\system32\dns.
Serwer wtórny zawiera autorytatywne dane adresowe domeny, lecz otrzymuje je od serwera podstawowego w trybie przesyłu strefy. Serwery wtórne są doskonałymi kopiami zapasowymi danych i odciążają serwer podstawowy przez odpowiadanie na zapytania. Wtórny serwer nazw spełnia następujące funkcje:
§ Rozkład obciążenia zadaniami na kilka komputerów. Ponieważ zapytania w domenie mogą być obsługiwane przez wiele komputerów, czas odpowiedzi przy rozwiązywaniu zapytań zmniejsza się. Rozkład obciążenia jest wynikiem zapamiętywania przez resolwery używanych w przeszłości serwerów nazw i ich czasów odpowiedzi na każde zapytanie.
§ Zależnie od położenia geograficznego, rutingu itp., niektóre serwery działają sprawniej od innych. Inteligentny resolwer wykorzystuje te informacje aby wybrać konkretny serwer nazw dla obsługi konkretnego zapytania.
§ Nadmiarowość. Jeśli posiadamy wtórne serwery nazw, odwołania w domenie mogą być obsługiwane a nazwy rozwiązywane nawet w wypadku awarii lub odłączenia serwera podstawowego. Przydatne jest zwłaszcza lokowanie serwerów wtórnych w oddzielnych sieciach fizycznych, nawet w odległych od siebie częściach kraju.
Lokalne rozwiązywanie hostów w domenie odwrotnej i buforowanej domenie głównej
Wskazania i zawartość pliku domeny 0.0.127.in-addr.arpa i pliku bufora domeny głównej są zwykle identyczne dla wszystkich komputerów, ponieważ każda maszyna posiada port pseudosieci (loopback) z adresem 127.0.0.1. Loopback, często nazywany localhost, jest stosowany do komunikacji wewnętrznej usług sieciowych,
Serwer nazw może rozwiązywać nazwy odwołując się do samego siebie pod nazwą localhost. Przyspiesza to działanie serwera, ponieważ nie jest wtedy potrzebna komunikacja z siecią, w której opóźnienia są większe.
Oczywiście jeżeli przyjrzeć się dokładnie powyższej liście, można stwierdzić że model strefy zintegrowanej z Active Directory zawierającej wiele serwerów głównych (multi-master) może zostać wykorzystany aby spełnić wszystkie postulaty, nawet nie stosując serwerów wtórnych.
Przydatność nadmiarowości łatwo uzasadnić korzystając z przykładu poczty elektronicznej. Przyjmijmy, że xyz.com posiada serwer podstawowy w San Jose w Kalifornii. Administratorzy decydują się umieścić serwer wtórny w innej podsieci, lecz w tym samym budynku. Jeśli xyz.com utraci łączność z Internetem, natychmiast straci możliwość odpowiadania na zewnętrzne zapytania DNS dotyczące swojej domeny. Gdy w takiej sytuacji ktoś na przykład chciał wysłać list pocztą elektroniczną do xyz.com, wiadomość powróci (odbije się), najprawdopodobniej z błędem unknown host (host nieanany).
Przyjmijmy teraz, że xyz.com zdecyduje się na umieszczenie serwera wtórnego na wschodnim wybrzeżu Stanów Zjednoczonych, korzystając z usług dostawcy abc.com. Teraz jeśli xyz.com utraci łączność, zapytania nadal obsługiwane będą przez serwer wtórny utrzymywany przez abc.com. Dodatkowo, obsługa zewnętrznych zapytań w xyz.com może się stać ogólnie szybsza, ponieważ rozproszona konfiguracja pozwoli na przyjmowanie zapytań z różnych regionów kraju [? – przyp. tłum.] Na przykład, list elektroniczny wysłany do xyz.com zostanie zwrócony do kolejki z powodów problemów z dostarczeniem a nie zawrócony do nadawcy.
Poniższy przykład pokazuje jak może wyglądać plik startowy dla serwera wtórnego:
; Katalog w którym backup.exe wyszukuje lub zapisuje pliki zapasowe
; Typ serwera Domena Źródło Zapas
secondary example.net 192.168.1.220 hosts.db
secondary 1.168.192.in-addr.arpa 192.168.1.220 hosts.rev
primary 0.0.127.in-addr.arpa hosts.local
cache . cache
Proszę zwrócić uwagę, że w tym przykładzie źródłem danych jest host 192.168.1.220 a serwer nazw przechowuje kopię pliku strefy, nazywając ją hosts.db. Serwer wtórny ma takie samo skierowanie do pliku buforowego jak podstawowy. Ponadto, serwer ten jest podstawowym dla domeny 0.0.127.in-addr.arpa, ponieważ adres pseudosieci jest dla każdej maszyny prywatny, wobec czego każdy serwer jest podstawowym dla własnej pseudosieci.
Od serwera wtórnego nie wymaga się zapisywania kopii zapasowej danych domeny, chociaż jest to zalecane. Posiadanie lokalnej kopii zapasowej oznacza szybszy rozruch serwera, ponieważ nie musi on natychmiast po uruchomieniu kontaktować się z podstawowym dla pobrania informacji o strefie, a jeśli dane są aktualne, nie potrzebuje przesyłu danych poza sprawdzaniem czy dane strefy nie zmieniły się. Nie gwarantuje to aktualności początkowego zestawu danych, lecz serwer nazw może przynajmniej rozpocząć odpowiadać na zapytania na podstawie danych które posiada.
Serwery buforujące mogą posłużyć do poprawy osiągów serwerów DNS w sieciach lokalnych. Tam, gdzie zapytania DNS często dotyczą tych samych hostów docelowych, można zainstalować serwer buforujący aby przyspieszyć odpowiedzi na zapytania bez obciążania się problemami administracyjnymi związanymi z serwerami podstawowymi i wtórnymi, czy też dodatkowego obciążenia sieci przesyłami stref. Uruchomienie i działanie serwera buforującego wymaga niewielkich nakładów pracy, co przedstawia poniższy przykład:
; Katalog w którym [named] wyszukuje i zapisuje pliki zapasowe
; [Wytyczn]e działania serwera nazw
; Typ serwera Domena Źródło
Plik konfiguracyjny buforującego serwera nazw wymaga jedynie podania katalogu, domeny pseudosieci loopback (0.0.127.in-addr.arpa) i pamięci podręcznej.
Jedynym wymogiem dla serwera buforującego jest poprawny plik pamięci podręcznej domeny głównej, z dopisanym serwerem jako takim. Ponieważ serwery buforujące nie mogą być autorytatywne, nie powinno się delegować ich do domeny. Serwery buforujące mogą zostać skonfigurowane do przekazywania zapytań a następnie zapamiętywania odpowiedzi do wykorzystania w przyszłości.
Serwery buforujące są wyjątkowo przydatne dla dostawców usług internetowych udostępniających swoje podstawowe usługi DNS, chcących poprawić wydajność systemu, oraz dla odległych lokalizacji z wolnymi łączami. Aby uruchomić serwer buforujący w Windows, w pierwszej kolejności trzeba zainstalować i uruchomić serwer DNS. Pamięć podręczna i loopback generowane są automatycznie w chwili zainstalowania nowego serwera. Jedyną wymaganą czynnością jest upewnienie się że usługa uruchamia się po restarcie systemu lub innych przerwach w jego działaniu. Większość instalacji nie korzysta z usług ISP (dostawcy usług internetowych) by zapewnić wsparcie DNS dla środowiska domen Windows, lecz lokalny bufor nazw zewnętrznych publicznej przestrzeni nazw ISP lub wewnętrznego serwera nazw jest nader użyteczny.
Serwery buforujące mają kilka zalet. Główną z nich jest wzrost wydajności dla wielu użytkowników, którzy w przeciwnym razie przeciążyliby pojedynczy serwer: obciążenie przekazywane jest na komputer do tego tylko przeznaczony. Wadą, chociaż niewielką, jest posiadanie przez serwery buforujące nie zawsze precyzyjnych informacji. Aby kontrolować czas przechowywania przez serwer buforujący danych przed skasowaniem, można ustawić jego „czas życia” – wartość TTL (time-to-live). Problemem związanym z DNS w Windows 2000 jest zaimplementowanie w nim buforowania [odpowiedzi negatywnych], NCACHE. Zwykle nie jest to kłopotliwe, lecz czasami może prowadzić do dezorientacji, zwłaszcza dla administratorów DNS wprowadzających zmiany i dokonujących testów.
Serwer DNS może wyznaczyć inny na swój serwer przekazowy (forwarder), co decyduje gdzie przekazywać będzie zapytania na które nie może odpowiedzieć. Stosunek podporządkowania przez ograniczenie działalności serwera — to znaczy, zakaz działania jako klient dla innych serwerów DNS — uzależnia rozwiązywanie zapytań przez serwer od jego forwarderów. W skrócie, podstawowa różnica między serwerem przekazującym a podporządkowanym jest następująca:
§ Serwer przekazujący. Przesyła zapytania do wyznaczonego komputera – swojego forwardera, czeka przez krótki okres czasu a następnie sam zaczyna poszukiwania odpowiedzi
§ Serwer podporządkowany (slave). Wysyła zapytania do wyznaczonego komputera – swojego forwardera i czeka na odpowiedź. Serwery podporządkowane nie próbują samodzielnie rozwiązywać zapytań. Proszę zauważyć, że takie zastosowanie terminu slave nie odnosi się do serwera wtórnego, lecz funkcjonalności nazywanej slave (podporządkowaniem)
Forwarder to komputer wyznaczony do obsługi zapytań (patrz rys. 3.1)
Klienci, włącznie z innymi serwerami DNS, czekają krótki okres czasu po wysłaniu zapytania do forwardera a następnie, jeśli nie otrzymają odpowiedzi, mogą same zacząć poszukiwania — chyba, że działają jako podporządkowane. Ponieważ przez przekazujące serwery DNS może być przesyłana duża ilość danych, gromadzą one dużą pamięć podręczną adresów. Może okazać się to przydatne przy tworzeniu bufora dla wielu użytk...
hansgolastyk