[ Pobierz całość w formacie PDF ]
.210 Czesc II Praca z TCP/IPZapytania iteracyjne i rekurencyjneResolwery wysylaja do serwerów nazw zapytania rekurencyjne.Okreslenie rekuren-cyjny odnosi sie do faktu, iz zapytanie moze przechodzic kolejno do serwerów nazww calej globalnej przestrzeni nazw, co czasami okreslane jest terminem kroczenie podrzewie (walking the tree).Relacje miedzy resolwerem i serwe rem nazw wymagajazwrócenia jednej z dwóch mozliwych odpowiedzi na zapytanie o nazwe: (1) odpowie-dzi, lub (2) komunikatu o bledzie stwierdzajacego, ze szukany host nie istnieje.Serwernazw nie moze skierowac resolwera do innego serwera nazw.Musi znalezc odpowiedzlub stwierdzic, ze odpowiedz nie istnieje.Gdy serwer nazw otrzymuje zapytanie od resolwera, w pierwszej kolejnosci sprawdzapamiec podreczna nazw, a nastepnie plik strefy.Jesli w tych dwóch miejscach nie jestw stanie znalezc wpisu dla nazwy lub adresu IP szukanego hosta, to serwer nazw wyko-rzystuje plik wskazówek glównych (inaczej plik podreczny) w polaczeniu z zapytania-mi iteracyjnymi, aby przemieszczajac sie po drzewie domen znalezc odpowiedz dla re-solwera.Jesli w tej samej przestrzeni nazw odpowiedz istnieje, to zostanie ona w tymprocesie znaleziona; moze to jednak zajac troche czasu.Rysunek 10.5 pokazuje, jakdzialaja zapytania iteracyjne i rekurencyjne:Rysunek 10.5.Zapytania iteracyjnei rekurencyjne1.Goofy.cartoon.com odpytuje swój serwer nazw o adres IP hosta host2.realife.com.2.Serwer nazw domeny cartoon.com sprawdza, czy posiada pelnomocnictwa(plik strefy) dla realife.com.Nie posiada ich, a poza tym nie ma tez odpowiedziw pamieci podrecznej, wiec serwer formuluje zapytanie iteracyjne i wysyla jedo jednego z serwerów poziomu glównego, wymienionych w pliku podrecznym.3.Serwer poziomu glównego w odpowiedzi zwraca najlepsze z posiadanychinformacji.Poniewaz serwer ten z nazwy host2.realife.com zna jedynie czesc.com, wobec tego odpowiada na zapytanie zwracajac adres IP serwera nazwdomeny.com, którego adres IP posiada w pliku strefy glównej. Rozdzial 10.Znajdowanie hostów w sieci IP 2114.Serwer nazw domeny cartoon.com ponownie przekazuje zadanie hosta goofyo host2.realife.com, lecz tym razem do serwera nazw domeny.com.5.Serwe r nazw domeny.com odpowiada najlepiej, jak potrafi.Poniewaz jego plikstrefy zawiera jedynie wpis dla serwera nazw domeny realife.com, wiec mozeodeslac do serwera nazw domeny cartoon.com jedynie ten adres.6.Ponownie serwer nazw dla cartoon.com wysyla zapytanie hosta goofy, lecz tymrazem do serwera nazw posiadajacego pelnomocnictwa dla domeny realife.com.7.Serwer nazw domeny realife.com odpowiada adresem IP hosta host2.realife.com.8.Serwer nazw dla cartoon.com odpowiada na zapytanie hosta goofy, podajac adres IPdla host2.realife.com.Z punktu widzenia resolwera, obslugujacy go serwer nazw zna wszystkie adresy IP i na-zwy hostów w globalnej przestrzeni nazw.Resolwer wysyla pytanie i otrzymuje odpo-wiedz za pomoca zapytania rekurencyjnego.Z drugiej strony, serwery nazw posiadaja zdolnosc wskazywania na siebie nawzajem napodstawie najlepszych posiadanych informacji.Takie odpytywanie iteracyjne moze wy -magac lacznosci z wieloma serwerami nazw w celu odpowiedzi na pojedyncze zadanieresolwera.Konfiguracja DNS-u z wykorzystaniem programu BINDKonfiguracja DNS-u za pomoca oprogramowania Berkeley Internet Name Daemon(BIND) opiera sie na istnieniu pliku rozruchowego (boot file), który zawiera poczatko-we parametry startowe dla serwera DNS.Serwery DNS systemów Windows nie potrze-buja pliku rozruchowego, poniewaz dla nich dane konfiguracyjne DNS-u sa przecho-wywane w Rejestrze.Gdy jednak chcemy przeniesc is tniejaca konfiguracje z programuBIND do DNS-u systemu Windows, mozemy bez trudu wykorzystac plik rozruchowy.Plik rozruchowy musi nosic nazwe boot i zawierac okreslone polecenia i opcje.Polece-nia te kontroluja sposób, w jaki usluga DNS jest uruchamiana.Pliki rozruchowe pro-gramu BIND w wersjach 4 i 8 maja odmienne style.W tym punkcie zajmiemy sie pli-kiem rozruchowym programu BIND 4.Ponizej przedstawiony zostal prosty plik rozruchowy DNS.Numery wierszy zostalywstawione jedynie dla wygody czytelnika.Polecenia pliku rozruchowego zaczynaja sieod poczatku wiersza i nie sa poprzedzane znakami spacji.1.cache c:\winnt\system32\dns\cache.dns2.primary cartoon.com cartoon.com.dns3.secondary realife.com 192.168.1.22 db.realife.com4.forwarder 192.168.1.47 192.168.1.485.option no recursionPolecenie cache w wierszu 1.okresla nazwe i polozenie pliku podrecznego.Plik pod-reczny (inaczej plik wskazówek glównych) sluzy do znajdowania serwerów nazw dladomeny glównej.Wiersz 2.okresla, iz serwer posiada pelnomocnictwa dla strefy pod-stawowej cartoon.com, której dane skladowane sa w pliku strefy o nazwie carto-on.com.dns.Wiersz 3.okresla, iz serwer nazw posiada takze pelnomocnictwa dla strefy212 Czesc II Praca z TCP/IPwtórnej realife.com oraz podaje nazwe lokalnego pliku sluzacego do buforowania da-nych tej strefy.Wiersz 4.podaje lis te serwerów nazw, które zgadzaja sie rozwiazywaczapytania rekurencyjne w imieniu naszego serwera nazw.Polecenie option w wierszu5.okresla, iz serwer nazw powinien do innych serwerów nazw wysylac zapytania nie-rekurencyjne.Serwery nazw BIND nie dysponuja inna mozliwoscia konfiguracji, poza ta z wykorzy-staniem pliku rozruchowego.Serwery nazw Windows moga byc konfigurowane za po-moca danych zawartych w Rejestrze lub pliku rozruchowym.Rózne wersje serwerówDNS pod Windows stosuja odmienne metody konfiguracji pozwalajace na uruchomie-nie z pliku rozruchowego.Jedna z tych metod jest DNS-owy wpis w Rejestrze Boot-Method.Wartosc 1 oznacza uruchamianie z pliku, zas 2 kaze skorzystac z Rejestru
[ Pobierz całość w formacie PDF ]