Serwery nazw

Serwery nazw
Teoretycznie możliwe jest załadowanie całej bazy DNS do pojedynczego serwera i powierzenie temu serwerowi funkcji
odpowiadania na wszystkie żądania związane z tą bazą. W praktyce jednak rozwiązanie takie nie może być brane pod uwagę z dwóch
powodów. Pierwszym z nich jest niewyobrażalne obciążenie, jakiemu serwer ten musiałby sprostać, drugim natomiast fakt, że awaria
(lub po prostu wyłączenie) tegoż serwera sparaliżowałaby cała domenę (teoretycznie nawet cały Internet).
W związku z powyższym konieczne jest podzielenie całej przestrzeni nazw na rozłączne strefy (ang. zones) - jeden z możliwych
sposobów takiego podziału przedstawiono na rysunku 7.2. Każda ze wspomnianych stref obejmuje pewien wycinek drzewa
przestrzeni nazw i ma własne serwery DNS zwane serwerami nazw (ang. name servers). Zazwyczaj jeden z tych serwerów, zwany
głównym serwerem nazw (ang. primary name server) zajmuje się bezpośrednią obsługą bazy DNS na dysku (dyskach), podczas gdy
pozostałe, zwane wtórnymi (ang. secondary name servers) uzyskują dostęp do zawartości bazy pośrednio, za pomocą serwera
głównego. Dla zwiększenia niezawodności niektóre z serwerów DNS danej strefy mogą być zlokalizowane poza tą strefą.
www.zsp1.eu - 1/4
Konkretny podział domeny na strefy — czyli położenie granic poszczególnych stref — określany jest przez administratora domeny i
podyktowany jest głównie lokalizacją poszczególnych serwerów nazw. W podziale przedstawionym na rysunku 7.2 domena
cs.yale.edu nie korzysta z serwera nazw przeznaczonego dla domeny eng.yale.edu, posiada bowiem własny serwer nazw.
Widocznie zarządcy domeny eng.yale.edu nie chcieli uruchamiać własnego serwera nazw (w przeciwieństwie do informatyków
administrujących domeną cs.yale.edu). W efekcie domena cs.yale.edu jest odrębną strefą, podczas gdy domena eng.yale.edu nie jest.
Proces określający nazwy, otrzymawszy żądanie znalezienia adresu IP odpowiadającego danej nazwie mnemonicznej domeny,
przekazuje tę nazwę do jednego z lokalnych serwerów nazw. Jeżeli odnośna domena znajduje się w zakresie jurysdykcji tego serwera
(jak np. domena ai.cs.yale.edu w zakresie jurysdykcji serwera cs.yale.edu) zwracany przez serwer rekord zasobów jest rekordem
wiarygodnym (ang. authoritative record), czyli na pewno aktualnym; w przypadku rekordu pochodzącego z pamięci cache (a nie
bezpośrednio z serwera) nie możemy być pewni jego aktualności, a więc nie zasługuje on na miano rekordu wiarygodnego.
Lokalne serwery nie dysponują jednak na ogół informacją o domenach odległych, dlatego też muszą one uzyskiwać tę informację od
serwerów nadrzędnych, czyli zlokalizowanych na wyższych poziomach w drzewie przestrzeni nazw. W sytuacji zilustrowanej na
rysunku 7.3 proces określający nazwy, dziejąca na hoście flits.cs.vu.nl, próbuje uzyskać adres IP hosta linda.cs.yale.edu. W kroku 1.
wysyła ona żądanie do lokalnego serwera nazw cs.uv.nl; żądanie to zawiera nazwę domeny, typ rekordu (A) i jego klasę (IN).
Tak się jednak składa, że lokalny serwer nazw nie posiada żadnej informacji na temat rzeczonej nazwy, bo nigdy wcześniej nie miał z
nią do czynienia; próbuje on więc uzyskać tę informację z pobliskich serwerów lokalnych — niestety, one również nią nie dysponują.
www.zsp1.eu - 2/4
W związku z tym nasz serwer wysyła pakiet UDP (krok 2.) do serwera domeny edu — adres tego serwera (edu-server.net) pobiera z
własnego pliku konfiguracyjnego. Jest mało prawdopodobne, by serwer nazw domeny edu dysponował informacją na temat hosta
linda.cs.yale.edu czy nawet domeny cs.yale.edu, na pewno jednak dysponuje on adresami serwerów nazw swoich poddomen, w
szczególności domeny yale.edu. Żądanie przekazywane jest więc do serwera nazw domeny yale.edu (krok 3,). a następnie do domeny
cs.yale.edu (krok 4.), której serwer nazw ostatecznie udostępnia poszukiwany adres IP, w formie wiarygodnego rekordu zasobów.
Rekord ten musi teraz przebyć drogę powrotną (kroki 5 - 8), by ostatecznie trafić do procedury wywołującej.
Gdy tylko rekord ten przybędzie do serwera nazw domeny cs.vu.nl, zostanie on wpisany do pamięci cache tego serwera, by przy
powtórnym żądaniu dotyczącym nazwy linda.cs.yale.edu uniknąć powtarzania opisanych ośmiu kroków. Niewątpliwie zwiększa to
efektywność, lecz jednocześnie czyni lokalny serwer nazw niewrażliwym na wszelkie zmiany w serwerach nazw odległych domen.
W efekcie rekord zapisany w cache'u lokalnego serwera może już nie odzwierciedlać stanu faktycznego, aby więc uniknąć
problemów wynikających z jego (ewentualnej) nieaktualności, należy racjonalnie ograniczyć czas jego obecności we wspomnianym
cache'u. Temu właśnie celowi służy pole Czas życia znajdujące się w każdym rekordzie zasobowym. Mimo iż wiele hostów
utrzymuje swe adresy IP bez zmian przez wiele lat. w opisanym przypadku bezpiecznie będzie ograniczyć czas życia rekordu do
jednego dnia. W stosunku do informacji o większym stopniu ulotności wskazane jest ograniczanie ich obecności w pamięci cache do
kilku minut, a nawet sekund.
Należy zauważyć, iż opisany scenariusz uzyskiwania adresu IP ma charakter rekurencyjny: jeżeli mianowicie dany serwer nie
potrafi spełnić żądania za pomocą własnych zasobów, formułuje kolejne żądanie pod adresem innego serwera, który z kolei znów
może zaprząc do pomocy kolejny itd. Niektóre serwery nie implementują jednak takiego rekursywnego mechanizmu, zastępując go
mechanizmem na wskroś iteracyjnym: jeżeli zasoby serwera są niewystarczające do spełnienia żądania, zwraca on po prostu nazwę
kolejnego serwera, zamiast formułować pod jego adresem nowe żądanie.
Warto także wspomnieć, iż w przypadku przeterminowania żądania (czyli braku odpowiedzi z serwera w założonym limicie czasu)
klient DNS nie powinien ponawiać próby, lecz skierować żądanie do innego serwera DNS. Zakłada się bowiem, że przyczyną
przeterminowania jest raczej po prostu wyłączenie serwera niż zagubienie pakietu z żądaniem.
Mimo krytycznego znaczenia DNS dla poprawnego funkcjonowania internetu, jego mozliwości ograniczają się do "zmiany"
mnemonicznych nazw domen (lub hostów) na adrsy IP; nie jest on w stanie wspomóc poszukiwania ludzi, zasobó, usług i innych
obiektów w ogólności. Zadaniem temu może natomiast spraostać inna usługa katalogowa, nosząca orginalną nazwę LDAP
(Lightweight Directory Access Protocol, dosł. Lekki Protokół Usług Katalogowych).
www.zsp1.eu - 3/4
LDAP jest wykorzystywany praktycznie w adresacji sieci Internet w celu zapewnienia niezawodności, skalowalności i
bezpieczeństwa danych. W odróżnieniu od X.500 nie potrzebuje ani szerokiego pasma, ani dużej mocy obliczeniowej. Pracuje w
oparciu o protokół TCP/IP lub inne połączeniowe usługi transportu. Dane grupowane są w strukturze przypominającej drzewo
katalogów. Każdy obiekt jest jednoznacznie identyfikowany poprzez swoje położenie w drzewie.
LDAP w wielu sytuacjach uznawane jest za rozwiązanie lepsze od innych usług katalogowych, ponieważ korzystając z TCP/IP
(które działa tylko w warstwie transportowej modelu OSI), daje niezwykle szybkie odpowiedzi na żądania zgłaszane przez klienta.
www.zsp1.eu - 4/4