Odwzorowanie adresów IP i nazw logicznych
Odwzorowanie adresów IP na adresy MAC
Aby dwa komputery mogły nawiązać komunikację, ich karty sieciowe muszą mieć możliwość wzajemnego odnalezienia się. W sieci TCP/IP każdej stacji przypisuje się reprezentujący ją adres IP. Protokołem używam do odwzorowania adresu IP do adresu MAC karty sieciowej jest ARP. Chociaż teraz zajmiemy się przypisywaniem logicznych nazw stacjom, warto pamiętać, że faktyczne zaistnienie komunikacji zawsze wymaga również tego kroku.
Odwzorowanie nazw logicznych na adresy IP
Wyższość oznaczania stacji nazwami pochodzącymi z języka naturalnego w porównaniu z korzystaniem z adresów IP nie wymaga chyba uzasadnienia. W sieciach TCP/IP wykorzystywane są dwie techniki odwzorowywania nazw:
§ Odwzorowywanie hostnames.
§ Odwzorowywanie nazw NetBIOS.
Proces odwzorowywania nazw logicznych odbywa się na poziomie aplikacji w modelu warstw TCP/IP
Jak widać na rysunku, do odwzorowania nazwy wykorzystuje się jedną z dwóch metod. Jej wybór należy do aplikacji korzystającej z usługi odwzorowania. Aplikacje NetBIOS używają odwzorowania nazw NetBIOS, aplikacje Winsock - odwzorowania hostnames.
Po określeniu dla danej nazwy adresu IP wykorzystywany jest protokół ARP w celu uzyskania adresu MAC. Rezultat tego procesu zależy od tego, czy poszukiwana stacja znajduje się w sieci lokalnej, czy odległej. W pierwszym przypadku ARP zwraca adres MAC stacji docelowej. Jeżeli jednak stacja znajduje się w sieci odległej, protokół ARP określi adres MAC routera wykorzystywanego do przesyłania danych do tej sieci. Ramka zostaje przesłana do bramy domyślnej, która przekaże ją dalej do sieci zawierającej stację docelową.
Odwzorowanie hostnames
Metoda odwzorowania nazw określana jako hosmame resolution towarzyszyła Internetowi od jego początków. Wówczas informacje o nazwach stacji (czyli host names) były przechowywane w jednym centralnym pliku HOSTS.TXT.
Sieciowe Centrum Informacyjne (NIC) rejestrowało w tym pliku nazwy i adresy IP wszystkich pojawiających się w Internecie stacji.
Każda z połączonych w sieć stacji tworzyła kopię głównego pliku HOSTS.TXT w swoim systemie. Wraz z rozszerzaniem się Internetu, coraz wyraźniejsza stawała się potrzeba odejścia od tak scentralizowanego systemu. Pojawiły się m.in. następujące problemy:
§ Szybkość rozrostu sieci wymuszała codzienne aktualizacje pliku.
§ Sieć Instytutu Badawczego Stanforda (gdzie przechowywana była główna kopia pliku nazw) stała się prawdziwym "wąskim gardłem" Internetu.
§ "Płaska'' struktura nazw stacji powodowała, że określona nazwa stacji w całej dużej sieci nie mogła zostać nigdzie powtórzona.
§ Zaktualizowanie informacji o nazwach stacji w skali całego Internetu wymagało kilku dni.
Stało się wówczas jasne, że nowy system odwzorowywania nazw musi opierać się na strukturze hierarchicznej. Drugą istotną przesłanką nowego rozwiązania była potrzeba zastąpienia centralnej bazy danych rozwiązaniem typu rozproszonego. Miało ono pozwolić każdej organizacji na zarządzanie własnym systemem nazw stacji.
Przestrzeń nazw domen
Przestrzeń nazw domen (ang. Domain Name Space) jest drzewiastą strukturą obejmującą wszystkie domeny tworzące przestrzeń nazw Internetu. Początkiem drzewa jest domena określana angielskim terminem root, czyli korzeń
Rysunek Przestrzeń nazw domen
W odróżnieniu od pozostałych domen, domenie root nie odpowiada żadna występująca w nazwach stacji etykieta. Do jej określenia stosuje się czasem znak kropki (.).
Poniżej domeny root znajdziemy domeny pierwszego poziomu (ang. top-level domains). Są one dwojakiego rodzaju: pierwsza ich grupa odpowiada typom działalności korzystających z nich organizacji, druga oparta jest na dwuliterowych oznaczeniach krajów, w których poszczególne organizacje się znajdują.
Kolejny poziom hierarchii, zawierający konkretne stacje i dalsze poddomeny, tworzą domeny drugiego poziomu (ang. second-level domains).
Domeny krajowe
http://www.amu.edu.pl - ujednolicony adres zasobu
(ang. URL – universal resource locator)
Nazwa stacji obejmująca pełną nazwę domeny jest określana jako zupełna lub w pełni kwalifikowana nazwa domenowa (ang. FQDN – fully qualified domain name) .
Nazwy domen drugiego poziomu muszą być zarejestrowane
w InterNIC (ang. Internet Network Information Center)
http://www.internic.net
Proces odwzorowywania nazw stacji
Proces prowadzący do określenia adresu IP na podstawie nazwy stacji przebiega wg. algorytmu:
1. Czy przedmiotowa nazwa jest nazwą stacji, na której aktualnie pracujesz?
2. Czy przedmiotowa nazwa występuje w pliku HOSTS?
3. Czy serwer DNS posiada wpis odpowiadający poszukiwanej stacji?
4. Czy nazwa stacji została zarejestrowana na serwerze WINS?
5. Czy nazwa stacji może zostać odwzorowana za pośrednictwem lokalnego rozgłoszenia?
6. Czy nazwa stacji została zapisana w pliku LMHOSTS?
7. Kiedy żadna z tych metod określania adresu IP stacji docelowej nie zakończy się powodzeniem, aplikacja zwraca komunikat informujący, że nazwa stacji nie została odnaleziona.
Podział ról w systemie DNS
W procesie odwzorowania nazwy, jaki zachodzi w systemie przestrzeni nazw domen, biorą udział trzy rodzaje podstawowych elementów:
§ przestrzeń nazw domen,
§ klienci odwzorowania,
§ serwery nazw.
Przestrzeń nazw domen zapewnia rozproszoną, hierarchiczną bazę danych, która zawiera wszystkie przyporządkowania nazw stacji do adresów IP w Internecie. Pozwala więc odwzorować dowolną nazwę stacji w jej adres IP.
Klienci odwzorowania to oprogramowanie klienckie, które wymaga odwzorowania nazw na adres IP. Funkcje klienta odwzorowania są albo częścią aplikacji wywołującej, albo też uruchomione są w systemie operacyjnym stacji jako część stosu protokołu TCP/IP.
Serwery nazw to obecne w sieci stacje przyjmujące zapytania od klientów odwzorowania i zwracające adresy IP poszukiwanych stacji.
W zależności od konfiguracji i przyjętego zapytania serwer nazw może zwracać adres IP odpowiadający nazwie stacji, nazwę odpowiadającą adresowi IP, odpowiedź informującą o tym, że nazwa stacji nie zostali odnaleziona, lub wskazanie innego serwera nazw, który może zrealizować zapytanie.
Każdy z serwerów nazw może występować w następujących rolach:
§ podstawowy serwer nazw,
§ pomocniczy serwer nazw,
§ główny serwer nazw,
§ serwer nazw buforujący.
Podstawowy serwer nazw
Podstawowy serwer nazw (ang. primary name server) zarządza strefą danych. Termin strefa oznacza część przestrzeni nazw domen, za który odpowiedzialny jest konkretny serwer nazw. Pliki danych dla strefy są przechowywane lokalnie na podstawowym serwerze nazw.
Wszystkie modyfikacje w tych plikach mogą być przeprowadzane wyłącznie na tym serwerze. Strefa obsługiwana przez podstawowy serwer nazw może obejmować więcej niż jedną domenę. Może on zarządzać poddomenami w określonej domenie albo też przechowywać pliki związane z kilkoma różnymi domenami drugiego poziomu.
Rysunek 7.4.
Strefy serwerów nazw
Zależność pomiędzy strefami a domenami
Wielu użytkowników zakłada, że plik strefy odpowiada zawsze domenie.
Nie musi to jednak być prawdą. Załóżmy, że firma XYZ, korzystająca z domeny XYZ.com, rejestruje poddomeny sprzedaż, badania i marketing. Strefa może obejmować domenę XYZ.com i trzy poddomeny. Można jednak utworzyć osobne strefy dla wszystkich lub jedynie wybranych poddomen
Rysunek 7.5. Trzy pliki stref w jednej domenie
Pomocniczy serwer nazw
Pomocniczy serwer nazw (ang. secondary name server) uzyskuje informacje o strefie z innego serwera posiadającego plik strefy; owym "innym serwerem" może być inny serwer pomocniczy lub też serwer podstawowy. Operacja przesłania informacji o strefie jest zwięźle określana terminem przesłanie strefy.
Przesłankami wprowadzenia serwera pomocniczego są:
· Potrzeba rozłożenia obsługi ruchu sieciowego na dodatkowy serwer z tymi samymi danymi strefy.
· Potrzeba przyspieszenia odwzorowywania w ośrodku odległym przez utworzenie w nim dodatkowego serwera nazw.
· Potrzeba zmniejszenia awaryjności układu przez utworzenie dodatkowego serwem zapewniającego utrzymanie możliwości odwzorowywania nawet w przypadku utraty funkcjonalności przez jeden z serwerów nazw.
· Utworzenie serwera pomocniczego jest warunkiem zarejestrowania domeny w InterNIC.
Pliki stref przechowywane na serwerach pomocniczych nie są nigdy aktualizowane bezpośrednio - są jedynie kopiami plików przechowywanych na serwerach podstawowych. Stąd też stosowane niekiedy określenie serwer podległy (ang. slave name server)
Główny serwer nazw
Główny serwer nazw (ang. master name server) to serwer nazw, który przesyła swoje pliki stref do serwera pomocniczego. Chociaż mogłoby się wydawać, że jedynie podstawowe (primary) serwery nazw pracują jako serwery główne (master), również serwer pomocniczy (secondary) może pełnić tę rolę. Sytuacja taka może wyniknąć z możliwości wykorzystywanych łączy sieciowych.
Rysunek 7.6 przedstawia sieć, w której korzystniejsze będzie, gdy serwer pomocniczy będzie pełnił rolę głównego.
Rysunek 7.6. Sytuacja, kiedy pomocniczy serwer nazw powinien funkcjonować jako główny serwer
W konfiguracji serwera pomocniczego wskazywany jest adres IP serwera głównego (master). Podczas inicjalizacji komunikuje się on ze wskazanym serwerem głównym i inicjuje przesyłanie danych DNS strefy.
Buforujące serwery nazw
Buforujący serwer nazw (ang. caching-only name server) nie przechowuje informacji strefowej na lokalnych nośnikach danych. Kiedy stacja przesyła zapytanie do serwera buforującego, przekazuje on je dalej "w imieniu" tej stacji, buforuje wynik i zwraca klientowi adres IP poszukiwanej stacji. Kiedy później odbiera takie samo zapytanie od innej stacji, odpowiedź jest przekazywana na podstawie danych wciąż trzymanych w buforze.
Tego rodzaju rozwiązanie staje się użyteczne, gdy łącza sieci rozległej posiadają stosunkowo niewielką przepustowość. Zamiast serwera pomocniczego, który wymaga regularnego przesyłania pełnej informacji o strefie, może zostać utworzony jedynie serwer buforujący. Przesyłane są wówczas jedynie faktycznie użyteczne dane. W buforze przechowywane są wtedy informacje o najczęściej odwiedzanych miejscach i skorzystanie z nich nie wymaga żadnego ruchu na łączach sieci WAN.
Rodzaje zapytań DNS
Klient odwzorowania może kierować do serwera nazw następujące rodzaje zapytań:
§ rekurencyjne,
§ iteracyjne,
§ odwrotne.
Zapytania rekurencyjne
W przypadku zapytania rekurencyjnego serwer nazw może zwrócić wyłącznie adres IP odpowiadający wskazanej stacji albo informację o błędzie. Często wymaga to pełnienia przezeń roli klienta odwzorowania i przekazania zapytania do dalszego wskazanego w konfiguracji serwera nazw (patrz rysunek 7.7).
Tego rodzaju konfiguracja będzie wykorzystywana m.in. w przypadku sieci lokalnej oddzielonej od Internetu zaporą firewall. Wówczas konieczne staje się skonfigurowanie wewnętrznego systemu DNS tak, aby zapytania były przekazywane do serwera DNS zapory. Ich kierowanie poza zaporę nie jest dopuszczalne. Jedynym komputerem, który może kierować zapytania do sieci zewnętrznej, jest sama zapora. Użycie zapytania rekurencyjnego pozwala systemowi firewall przekazać je do wskazanego w konfiguracji serwera nazw, a następnie zwrócić odpowiedź w postaci adresu IP do stacji inicjującej.
Rysunek 7.7. Zapytanie rekurencyjne za pośrednictwem zapory firewall
...
orzel-97