Prace z informatyki – Strona 18 – Prace dyplomowe – prace licencjackie i magisterskie

Najczęstsze konfiguracje włączenia hosta w DNS

Oceń tę pracę

Komputer podłączony do sieci może być częścią systemu DNS na kilka różnych sposobów, w zależności od rodzaju informacji pobieranej z DNS, konfiguracji samych name serverów i sposobu ich połączenia.

Najczęściej spotykana konfiguracja jest pokazana na Rysunku 4.

Rysunek 4.

Źródło własne

Programy użytkowników komunikują się z przestrzenią DNS za pomocą resolver’ów. Format zapytań zależy od rodzaju komputera i systemu operacyjnego. Zwykle zapytania będą funkcjami systemowymi, a resolver i cache będą częścią systemu operacyjnego.

Resolver odpowiada programowi użytkownika informacją uzyskaną od innych name server’ów lub z lokalnego cache’a Poprzez własne zapytania.
Należy pamiętać, że aby odpowiedzieć na zapytanie host’a Resolver musi sam wysłać kilka zapytań do kilku różnych Name Server’ów i może wymagać wielu połączeń sieciowych, a co za tym idzie – czasu.

W zależności od możliwości name server powinien być osobnym programem na dedykowanej maszynie lub procesem na dużej maszynie wielodostępnej.
Przykładowa konfiguracja pokazana została na Rysunku 5.

Rysunek 5.

Źródło własne

Widać wyraźnie, iż Primary name server zdobywa informację o strefie lub strefach czytając dane z plików konfiguracyjnych i dane pochodzące od innych Resolverów.

DNS wymaga, by informacje o wszystkich strefach były przechowywane na więcej niż jednym serwerze, spełniając tym samym wymogi zabezpieczenia danych w razie awarii. Dedykowane serwery drugorzędne (secondary name servers). Do uzgadniania i aktualizowania danych z serwera głównego używają protokołu transferów strefowych (zone transfer protocol). Taka konfiguracja jest pokazana na Rysunku 6.

Rysunek 6.

Źródło własne

W tej konfiguracji name server regularnie inicjuje wirtualne połączenie do innego name serwera by uaktualnić dane lub sprawdzić, że się nie zmieniły.
Komunikaty towarzyszące tej wymianie informacji przypominają formę zapytań i odpowiedzi, choć różnią się zawartymi sekwencjami.

Przepływ informacji w hoście prowadzącym wszystkie rodzaje aktywności systemu DNS jest pokazany na Rysunku 7.

Rysunek 7.

Źródło własne

Dzielona baza danych zawiera DN Space dla lokalnych name serverów i resolver’ów. W typowym przypadku zawartość bazy danych jest mieszanką autoryzowanych danych otrzymywanych dzięki okresowym operacjom odświeżania oraz danych w cache’u pochodzących z poprzednich zapytań resolver’a.

Przepływ informacji może być też zorganizowany tak, aby grupa host’ów działała razem w celu zoptymalizowania ich aktywności. W takim rozwiązaniu komputery o mniejszych możliwościach nie muszą mieć w pełni zaimplementowanych resolver’ów (takie rozwiązania są popularne dla komputerów klasy PC lub bardziej obciążanych komputerów sieciowych.

Taki schemat pozwala również na dzielenie zasobów niewielkiej ilości cache’y pomiędzy grupą komputerów, w odróżnieniu od zarządzania duża ilością niezależnych cache’y (dla domniemanego zwiększenia wysokości celności trafień (cache hit ratio). W takim przypadku resolver’y są zamieniane na tzw. stub resolver’y, których działanie ogranicza się do bycia forpocztą rzeczywistych resolver’ów. Rozwiązanie to (charakteryzujące się możliwościami replikowania danych w domenie, kiedy tylko zajdzie taka potrzeba) przedstawiono na Rysunku 8.

Rysunek 8.

Źródło własne

Name servers. Rodzaje name serwerów

Oceń tę pracę

Name server’y są magazynem informacji składających się na bazę danych domeny. Baza danych podzielona jest na sekcje – strefy, które są później dystrybuowane pomiędzy serwerami. Jakkolwiek name server’y mogą spełniać różne funkcje, to głównym ich zadaniem jest odpowiadanie na zapytania, używając do tego informacji zawartych w bazie danych.

Dane o strefach są osiągalne z kilku name server’ów, by zapewnić dostęp do informacji nawet w przypadku awarii komputera lub łączy komunikacyjnych. Absolutnie wymagane jest, by dane o strefach były umieszczone na conajmniej dwóch serwerach.

Ponieważ name server przechowuje tylko niewielki wycinek drzewa domeny (i dla niej jest „autorytetem”), może również trzymać dane z innych części drzewa zawartą w np. cache’u (są one nieautoryzowane). Ponieważ name server zachowuje odpowiedzi udzielone na zapytania, ten któremu udzielono informacji może stwierdzić, czy dana odpowiedź była miarodajna czy nie.

Dla każdej domeny Internetowej potrzebne jest uruchomienie name server’a. Dla domen głównych (top level domains) jest to wymóg konieczny, natomiast jest bardzo zalecane uruchamianie name server’a w każdej poddomenie (subdomain).

W ten sposób struktura name server’ów będzie odpowiadać hierarchicznej strukturze nazw domen. Zatem potrzebne są następujące serwery:

ROOT SERVER dla trzymania informacji wszystkich domen głównych
NAME SERVER dla każdej domeny głównej
NAME SERVER dla wszystkich poddomen
NAME SERVER dla każdej domeny odwróconej (reverse domain – .in-addr.arpa)

Przykład:

 Name Server dla domeny:         .pl
 Name Server dla domeny:         .edu.pl
 Name Server dla domeny:         .pk.edu.pl
 Name Server dla domeny:         .usk.pk.edu.pl
 Name Server dla domeny:         .156.149.in-addr.arpa
(...)

Rodzaje name serwerów

Rozróżnia się pięć podstawowych typów name server’ów:

ROOT SERVER
MASTER SERVER
CACHING SERVER
FORWARDING SERVER
SLAVE SERVER

ROOT SERVER
Zna wszystkie top level domains w sieci Internet. Informacje o host’ach jest zbierana z tych domen. Na przykład ROOT SERVER nie zna w ogóle lokalnej poddomeny usk.pk.edu.pl. Jednak poprzez przeprowadzenie zapytania dla komputera z innej strefy (name server query) ROOT SERVER może stwierdzić miarodajnie o istnieniu danego host’a w tej poddomenie.

Po gruntownej reorganizacji w strukturze ROOT SERVER’ów Internetu obecnie funkcjonują ROOT SERVER’y podane poniżej:

 Nazwa ROOT SERER'a Adres IP 
 A.ROOT-SERVERS.NET 198.41.0.4 
 B.ROOT-SERVERS.NET 128.9.0.107 
 C.ROOT-SERVERS.NET 192.33.4.12 
 D.ROOT-SERVERS.NET 128.8.10.90 
 E.ROOT-SERVERS.NET 192.203.230.10 
 F.ROOT-SERVERS.NET 192.5.5.241 
 G.ROOT-SERVERS.NET 192.112.36.4 
 H.ROOT-SERVERS.NET 128.63.2.53 
 I.ROOT-SERVERS.NET 192.36.148.17 
O tym, który serwer jest ROOT SERVER'em decyduje NIC (Network Information Center).

MASTER SERVER

Jest „miarodajny” dla całego obszaru bieżącej domeny, prowadzi bazy danych dla całej strefy.

Istnieją dwa rodzaje MASTER SERVER’ow:

PRIMARY MASTER SERVER
SECONDARY MASTER SERVER

Może się zdarzyć, że serwer jest zarazem MASTER SERVER’em dla kilku domen – dla jednych PRIMARY MASTER SERVER’em, dla innych SECONDARY MASTER SERVER’em.

Ładowanie plików z bazy danych odbywa się za pomocą PRIMARY MASTER SERVERA. PRIMARY MASTER SERVER ładuje bazę danych z pliku znajdującego się na dysku. Natomiast SECONDARY MASTER SERVER otrzymuje pełnomocnictwo (authority) wraz z bazą danych od PRIMARY MASTER SERVER’a.

Podczas inicjalizacji systemu, SECONDARY MASTER SERVER ładuje dane dotyczące strefy z zapasowej kopii danych. Później jej zawartość jest sprawdzana z bazą danych na głównym serwerze i w razie potrzeby modyfikowana.
W czasie pracy serwerów SECONDARY MASTER SERVER co jakiś czas sprawdza zgodność danych u siebie z zawartością serwera głównego. Jeżeli na PRIMARY MASTER SERVERze nastąpiły zmiany, aktualne dane są kopiowane przez sieć.

MASTER SERVER może rozesłać potwierdzenie pełnomocnictw dla poddomen innym MASTER SERVER’om.

Każda domena powinna posiadać przynajmniej dwa MASTER SERVER’y – jeden PRIMARY i jeden (lub więcej) SECONDARY. Serwery zapasowe mogą pracować jako serwery backup’owe, w razie gdy serwer główny jest przeładowany, psuje się lub jest prowadzona konserwacja.

CACHING SERVER
Wszystkie serwery (PRIMARY jak i SECONDARY) prowadzą cache’owanie informacji, które otrzymują, dla poprawienia wydajności i szybkości obsługi. Dzieje się tak aż do zdezaktualizowania danych.

Wygasanie określone jest w polu ttl , które jest zawsze dołączane do danych dostarczanych serwerowi. Ono właśnie określa czas w jakim informacje są aktualne.
CACHING SERVER’y nie mają pełnomocnictw dla żadnej strefy, w związku z tym nie zarządzają żadnymi bazami danych. Mogą natomiast odpowiadać poprzez wysyłanie queries (zapytań) do innych serwerów posiadających takie pełnomocnictwa a dane z zapytań są później przechowywane (aż do wyczerpania daty ważności).

FORWARDING SERVER (FORWARDER)

FORWARDER’em może być każdy serwer w Internecie. Może nim być również MASTER SERVER (główny lub zapasowy) lub CACHING SERVER.
Głównym zadaniem FORWARDER’ów jest przeprowadzanie rekursywnych zapytań, które nie mogły zostać rozwiązane (resolved) lokalnie.

FORWARDER ma pełny dostęp do Internetu, przez co jest w stanie otrzymać każdą informację (nieosiągalną w lokalnych CACHE SERVER’ach) od ROOT SERVER’ów.
Ponieważ FORWARDER’y otrzymują wiele zgłoszeń od SLAVE SERVER’ów tendencją jest posiadanie przez nie większego cache’a lokalnego niż mają SLAVE SERVER’y. Dzięki takiemu rozwiązaniu wszystkie hosty w domenie korzystają z tego większego cache’a, co powoduje zredukowanie liczby całkowitej liczby zgłoszeń i przesyłania ich poza Internet do ROOT SERVER’ów. Oczywiście zmniejsza to stan obciążenia sieci i komputerów (tzw. load).

Konfiguracja zawierająca SLAVE SERVER i FORWARDER jest przydatna w momencie, gdy nie ma potrzeby, aby każdy serwer z domeny komunikował się z wszystkimi innymi serwerami w Internecie.

Jest możliwe prowadzenie DNS’u na lokalnej sieci komputerowej bez potrzeby zakładania FORWARDER’a. (Przykładowo: sieć lokalna nie włączona do Internetu).
Należy jednak pamiętać, iż bez uruchomionego FORWARDER’a nasz system nie ma dostępu do ROOT SERVER’ów w Internecie.

SLAVE SERVER

Ponieważ nie posiada nie posiada bezpośredniego dostępu do Internetu, w związku z tym nie może bezpośrednio kontaktować się z np. ROOT SERVER’ami by uzyskać niedostępną w lokalnym systemie.

Zamiast tego, SLAVE SERVER wysyła zapytania (queries) do wszystkich FORWARD’erów wyszczególnionych w swoim pliku konfiguracyjnym. Wysyłane one są aż do otrzymania informacji, lub wyczerpania listy FORWARDEDR’ów.
W miarę jak SLAVE SERVER’y żądają nowych informacji do FORWARDER’ów, te przechowują je we własnych cache’ach.

Poniższy Rysunek 3. może zilustrować zależności pomiędzy różnymi rodzajami name server’ów.

Rysunek 3.

Źródło własne

Domain Name Pointer Entry

Oceń tę pracę

Wpis wskaźnika do nazwy domeny (Domain Name Pointer – PTR) pozwala na odwoływanie się przez specjalne nazwy do innych lokalizacji w domenie.
Format PTR:

rev-addr ttl addr-class entry-type hostname

Poszczególne pola mają wartości zdefiniowane podobnie jak dla BIND File Entries, z wyjątkiem pól:

rev-addr

To pole wskazuje na odwrotny adres IP host’a (reverse IP adressDla przypomnienia jednak: jeżeli adres komputera jest np. 149.156.98.14 to odwrotnym adresem IP będzie: 14.98.156.149.

hostname

Tutaj umieszczana jest pełna nazwa kanoniczna host’a. Należy pamiętać o postawieniu kropki (.) na koniec zapisu nazwy host’a. Patrz przykład.

Przykład:
Wpis pola PTR posiadającego dwie pozycje.

; rev-addr                      ttl addr-class entry-type hostname
33.22                                         IN         PTR                  chicago
66.55.44.121.in-addr.arpa           IN         PTR                  mail.peace.org.

Pierwszy wpis można rozszyfrować jako host lokalny o adresie IP 22.33 w bieżącej domenie, zapisany w notacji odwrotnej., Drugi wpis to host innej domeny (mail.peace.org). Nie powinno się tak robić, ponieważ dane z cache’a z własnego serwera lokujemy na innym, który nie jest upoważniony. Wpisy PTR powinny wskazywać na komputery z naszej własnej domeny. Przykładowy wpis ustawia wskaźnik odwrotny dla host’a mail.peace.org.

Format wpisów dla programu BIND/Hesiod

Oceń tę pracę

BIND (Berkeley Internet Name Domain) jest jedną z UNIX’owych implementacji DNS’u. Składa się z serwera (daemon’a) oraz bibliotek resolver’a. Jest on na tyle popularny, i posłużyć może jako przykład implementacji. Jedyną różnicą jest to, iż BIND operuje na strefach (zones), a nie na domenach.

Strefa jest miejscem w drzewie DNS, do którego można się odwoływać (delegation point). Zawiera wszystkie nazwy począwszy od pewnego węzła i dalej idąc w dół drzewa, za wyjątkiem tych węzłów, które już są w innej strefie.

Strefa może dać się „mapować” do dokładnie jednej domeny, może też zawierać tylko jej wycinek. Prowadzi to do stwierdzenia, iż każda nazwa w drzewie DNS jest poddomeną, nawet jeżeli ona sama nie posiada poddomeny.

Zatem kiedy prosimy kogoś o prowadzenie serwera drugorzędnego dla naszej domeny, w przypadku BIND’a oznacza to pytanie o drugorzędnego serwera dla całego zbioru stref.

Hesiod jest serwisem informacyjnym zbudowanym na bazie BIND’a a jego funkcja podobną do NIS’u firmy Sun – dostarcza informacji o użytkownikach, grupach, systemach plikowych dostępnych w sieci, zasobach drukarek i rodzajach używanych usług poczty elektronicznej.

Format wpisów dla programu BIND/Hesiod odnosi się do sposobu, w jaki są przechowywane i zarządzane dane w systemie nazw domenowych (DNS) w oparciu o oprogramowanie BIND (Berkeley Internet Name Domain) oraz Hesiod – system, który pozwala na przechowywanie informacji o zasobach sieciowych w bazach danych. BIND jest jednym z najczęściej używanych serwerów DNS, a Hesiod jest systemem, który współpracuje z BIND, umożliwiając przechowywanie danych o użytkownikach, serwisach i zasobach w strukturze hierarchicznej, podobnej do DNS.

Wpisy w pliku strefy BIND są zapisywane w specjalnym formacie, który umożliwia definiowanie różnych typów rekordów, takich jak A (adres IPv4), AAAA (adres IPv6), MX (serwer pocztowy), CNAME (alias), TXT (tekst), oraz innych. Każdy wpis w pliku strefy zawiera kilka podstawowych informacji, w tym nazwę domeny, typ rekordu oraz jego wartość. Na przykład, zapis dla rekordu typu A, który mapuje nazwę domeny na adres IP, wyglądałby następująco:

example.com.   IN  A    192.0.2.1

Rekordy Hesioda są zapisywane w podobny sposób, ale różnią się od standardowych rekordów DNS. Zamiast przechowywać tylko dane dotyczące lokalizacji serwisów, Hesiod umożliwia także przechowywanie informacji o użytkownikach i hasłach w formie rozproszonych baz danych. Przykład zapisu w systemie Hesiod może wyglądać następująco, gdzie hesiod określa rekord w bazie Hesiod:

user@example.com. IN HINFO "hesiod" "user"

Wpisy BIND/Hesiod zawierają także specjalne dane konfiguracyjne, które wskazują na sposób interakcji systemu DNS z bazą Hesioda. Na przykład, używanie usługi Hesiod w połączeniu z serwerem DNS wymaga odpowiednich wpisów w pliku konfiguracyjnym, który może wyglądać następująco:

hesiod.example.com. IN  A   192.0.2.100

Plik konfiguracyjny BIND zawiera również odniesienia do plików strefy, w których przechowywane są konkretne rekordy DNS. Oprócz podstawowych rekordów takich jak A, MX, czy CNAME, w plikach strefy mogą znajdować się także bardziej zaawansowane rekordy, takie jak NS (serwery nazw), które wskazują na serwery DNS odpowiedzialne za daną strefę, oraz SOA (Start of Authority), który jest używany do określenia głównych serwerów odpowiedzialnych za strefę.

Zalety stosowania formatu BIND/Hesiod obejmują łatwość integracji systemu DNS z różnymi usługami sieciowymi, szczególnie w większych środowiskach, gdzie zarządzanie użytkownikami, dostępem i zasobami wymaga centralizacji danych. Dzięki takiej integracji, administratorzy mogą w sposób bardziej elastyczny i efektywny zarządzać siecią, użytkownikami oraz usługami w środowisku rozproszonym.

Podsumowując, format wpisów dla BIND/Hesiod to struktura, która umożliwia tworzenie i zarządzanie rekordami DNS oraz danymi o zasobach w systemach rozproszonych, takich jak użytkownicy i serwisy. Przy odpowiedniej konfiguracji, BIND i Hesiod stanowią potężne narzędzia do zarządzania danymi sieciowymi w organizacjach o różnej wielkości.

Format Of BIND/Hesiod File Entries

Oceń tę pracę

name ttl addr-class entry-type entry-specific-data

Poszczególne pola oznaczają:

name

Tutaj umieszczana jest nazwa domeny, np. cities.dec.com. Domena musi rozpoczynać pierwszą kolumnę.

Dla niektórych pozycji pole nazwy może być puste. W takim przypadku za nazwę domeny przyjmuje się domyślnie nazwę z poprzedniej pozycji.

Wolno stojąca kropka (.) oznacza bieżącą domenę.

Wolno stojący znak „at” (@) wskazuje na bieżące położenie, choć można wyspecyfikować więcej niż jedną domenę.

Wolno stojący dwukropek (..) reprezentuje zerową domenę root’a.

ttl

Oznacza pole time-to-live. Specyfikuje jak długo (w sekundach) dane mają być przechowywane w bazie danych. Jeżeli zostawi się to pole pustym, wartość zostanie określona domyślnie jako wartość ttl zawarta w SOA (start of authority). Maksymalna wartość to 99999999 sekund lub 3 lata.

addr-class

Pole oznacza klasę adresową (adress class). Zdefiniowane są trzy klasy:

IN — adresy sieci Internet

HS — Hesiod naming service data

ANY — każdy inny rodzaj adresów sieciowych

Klasy adresu wszystkich podanych pozycji pliku bazowego z danego typu pozycji w poszczególnych strefach muszą być jednakowe.

Tak więc tylko pierwszy wpis w strefie wymaga wyszczególnienia pola addr-class.

entry-type

Pole określa resource record type, np. SOA lub A.

entry-specific-data

Wszystkie pola następujące po entry-type różnią się w zależności od typu wpisu w resource record.