DNS.doc

DNS

Pod koniec lat 60 eksperymentalna, rozległa sieć komputerowa ARPAnet finansowana przez Agencję ds. Zaawansowanych Projektów Badawczych (ARPA) Departamentu Obrony (DoD) Stanów zjednoczonych połączyła organizacje badawcze realizujące kontrakty rządowe w celu współdzielenia zasobów obliczeniowych.

Bardzo szybko sieć stała się medium wykorzystywanym także i w innych obszarach współpracy poprzez przesyłanie plików i wymianę poczty elektronicznej. Komunikacja między komputerami odbywała się w oparciu o adresy numeryczne, co dość szybko okazało się niewygodne i uciążliwe. Zdecydowanie łatwiejszym sposobem operowania adresami przez człowieka jest system nazw symbolicznych, które są łatwiejsze do zapamiętania, a także o wiele rzadziej ulegają zmianie niż adresy numeryczne. Pierwotnie system nazw symbolicznych oparty był na pliku HOSTS.TXT, który konserwowany był indywidualnie przez każdy ośrodek. Bardzo szybko okazało się, że utrzymywanie wielu kopii jednego pliku jest nieefektywne, co doprowadziło do rozpoczęcia w 1973 roku prac nad centralizacją systemu zakończonych w roku 1974. W wyniku konsultacji uzgodniono, że oficjalna kopia pliku HOSTS.TXT będzie utrzymywana i udostępniana przez Stanford Research Instutute (SRI) Network Information Center (NIC). System ten doskonale zdawał egzamin przez prawie 10 lat, do momentu gdy standardowy zestaw protokołów sieci ARPAnet o nazwie TCP/IP dołączono do systemu operacyjnego BSD UNIX. W wyniku tego bardzo dużo komputerów znajdujących się w sieciach lokalnych wielu organizacji uzyskało dostęp do sieci ARPAnet. Lawinowy przyrost hostów w sieci sprawił, że niemożliwe stało się centralne utrzymywanie pliku z nazwami komputerów i powstała konieczność wypracowania innego sposobu zarządzania systemem nazw symbolicznych. Rezultatem prac rozpoczętych w 1982 roku było opublikowanie do 1983 roku kilku dokumentów RFC (810, 811, 819, 830, 881, 882, 883) definiujących sam system nazw symbolicznych oraz sposób jego implementacji. System ten znany pod nazwą DNS (Domain Name System) wykorzystywany jest do dzisiaj.

Utrzymywanie pliku HOSTS.TXT w sieci ARPAnet było stosunkowo proste i mało kłopotliwe. Administratorzy wysyłali do NIC wprowadzone przez siebie zmiany i raz na jakiś czas (np. dwa razy w tygodniu) pobierali plik HOSTS.TXT z NIC. System ten zdawał egzamin dopóki sieć składała się z kilkuset hostów. Wraz ze wzrostem liczby hostów wzrosło obciążenie sieci i serwera związane z dystrybucją pliku. Wystąpiły problemy z utrzymaniem spójności pliku w zakresie unikalności nazw. Ponadto proces przeszukiwania dość dużego pliku przez lokalne komputery stanowił poważne źródło obciążenia.

Przystępując do tworzenia nowego systemu przyjęto szereg założeń, których celem było uniknięcie wszystkich dotychczasowych ograniczeń. Najważniejszą cechą systemu nazw symbolicznych jest niewątpliwie hierarchiczna struktura danych, która pozwala zarówno na decentralizację danych, jak i na decentralizację zarządzania danymi. Zarządzanie danymi odbywa się w miejscu ich powstawania w ściśle określonym zakresie, co w naturalny sposób gwarantuje spójność systemu. W podobny, naturalny sposób osiągnięto wysoki stopień odporności i wydajności systemu wprowadzając dodatkowe mechanizmy powielania i buforowania danych, które w połączeniu z trybem pracy typu klient-serwer czynią system w pełni skalowalny.

Kluczowym elementem projektu DNS jest hierarchiczna struktura nazw. Wszystkie nazwy są wieloczłonowe i rozpoczynają się od wspólnego korzenia (ang. root), reprezentowanego znakiem „.” (kropki). Poszczególne człony nazwy także oddzielane są od siebie znakiem kropki, np.:

www.pw.edu.pl. Nazwę zapisuje się począwszy od ostatniego członu, który najczęściej oznacza nazwę hosta w danej organizacji, w kierunku członów bardziej ogólnych tworzących nazwę domeny tej organizacji. Przyjęto oznaczać pełną nazwę hosta skrótem FQHN od ang. Full Qualified Host Name i podobnie pełną nazwę domeny FQDN od ang. Full Qualified Domain Name. Zgodnie z pierwotną specyfikacją poszczególne człony nazwy powinny spełniać następujące warunki: powinny składać się z liter, cyfr i znaku ‘-’, długość członu powinna wynosić min. 3 znaki, pierwszy znak powinien być zawsze literą, wielkość liter nie ma znaczenia. W późniejszym okresie dopuszczono stosowanie krótszych członów.

Pierwszym członem w nazwie domenowej jest tzw. domena pierwszego poziomu TLD (and. Top-Level Domain). Poniżej domeny pierwszego poziomu może znajdować się dowolnie dużo poddomen drugiego poziomu, poniżej których może znajdować się dowolnie wiele poddomen trzeciego poziomu, itd.

W pierwotnej specyfikacji znalazło się siedem domen pierwszego poziomu: .com, .edu, .mil, .gov, .net, .org, .int, oraz dwuliterowe domeny narodowe. Obsługa każdej z domen delegowana jest do odpowiedniej organizacji, odpowiedzialnej za daną domenę. Po kilkunastu latach od chwili ogłoszenia pierwszej specyfikacji zostały zgłoszone propozycje nowych domen pierwszego poziomu, z których zaakceptowano kolejnych siedem, z czego cztery .biz, .info, .name, .pro otrzymały status domen ogólnie dostępnych, natomiast pozostałe trzy .aero, .coop, .museum status domen sponsorowanych. Spośród domen znajdujących się w pierwotnej specyfikacji, w trzech: .com – firmy comercyjne, .net – firmy/organizacje zajmujące się ogólnie rozumianą technologią sieciową, .org – firmy/organizacje non-profit rejestracja nie podlega ograniczeniom, natomiast w pozostałych czterech rejestracja odbywa się według ściśle określonych kryteriów: .edu – jednostki oficjalnie uznane za edukacyjne w USA, .mil – Armia USA, .gov – instytucje rządowe USA, .int – organizacje oficjalnie zajmujące się obsługą Internetu na podstawie umów międzynarodowych. Nazwy domen pierwszego poziomu oraz związane z nimi zasady rejestracji zostały przeniesione i zaakceptowane w odniesieniu do domen drugiego poziomu domen narodowych. Ostatecznie zasady organizacji domen zostały dość mocno rozluźnione. Rozszerzono zestaw domen pierwszego poziomu, dopuszczono stosowanie dowolnych schematów tworzenia domen poniżej poziomu domen narodowych. W związku z tym pojawiły się domeny regionalne (w Polsce waw, czest, katowice), zmieniono nazwy niektórych domen (Wielka Brytania com -> co, edu -> ac), dopuszczono dowolne nazwy poniżej poziomu domen narodowych. Z wyjątkiem wspomnianych wyżej reguł rejestracji w 4 domenach pierwszego poziomu, które zaadoptowano także dla drugiego poziomu domen narodowych oraz takich wyjątków jak rejestracja w domenie .eu, gdzie stworzono bufor czasowy dla firm i organizacji posiadających osobowość prawną, rejestracja odbywa się w dowolny sposób na zasadzie „kto pierwszy ten lepszy”. Szczegóły dotyczące zasad funkcjonowania nazw domenowych można znaleźć na stronach ICANN (Internet Corporation For Assigned Names and Numbers):

·         http://www.icann.org/tlds/ - Top-Level Domains (gTLDs),

·         http://www.icann.org/topics/TLD-acceptance/ - Universal Acceptance of all Top-Level Domains

·         http://data.iana.org/TLD/tlds-alpha-by-domain.txt - List of Top Level Domains

Nazwa domeny .arpa to skrót od Address and Routing Parameter Area. Domena ta przeznaczona jest do obsługi infrastruktury Internetu. Administracją domeny zajmuje się IANA wspólnie z Internet Architecture Board. Wymagania oraz wytyczne dotyczące obsługi domeny .arpa znajdują się w RFC3172 (BCP 52). Obecnie w domenie .arpa zdefiniowane są następujące domeny drugiego poziomu:

in-addr.arpa, której zadaniem jest mapowanie numerów IPv4 na nazwy ip6.arpa, której zadaniem jest mapowanie adresów IPv6 na nazwy e164.arpa, której zadaniem jest mapowanie numerów telefonicznych zgodnych z E.164 na adresy URI (ang. Uniform Resource Identifier).

Na slajdzie poniżej zaprezentowana jest przestrzeń mapowania odwrotnego dla adresów IPv4.

Slajd poniżej pokazuje położenie domeny .arpa w przestrzeni nazw DNS.

Drugą istotną cechą DNS, obok hierarchicznej struktury nazw jest rozproszona baza nazw. Idea delegowania obsługi fragmentu bazy danych organizacjom, w których te dane powstają okazała się prosta i niezwykle skuteczna.

Organizacje centralne, odpowiedzialne za funkcjonowanie Internetu obsługują lub zlecają obsługę domen pierwszego poziomu (np. domen narodowych), natomiast obsługa domen drugiego poziomu przekazywana jest organizacjom, do których należy dana domena, albo które specjalnie zostały do tego celu powołane. Następnie, organizacje obsługujące domeny drugiego poziomu, delegują obsługę domen trzeciego poziomu innym organizacjom, które zgodnie z przyjętymi zasadami mają do tego prawo, itd. Dzięki takiej strukturze zależności dane są wpisywane do bazy w miejscu, w którym powstają, co do minimum skraca czas od powstania do wprowadzenia nazwy do bazy, a to oznacza, że teoretycznie taka nazwa natychmiast jest widziana w Internecie. Aby taki system mógł działać potrzebne są specjalne serwery utrzymywane przez organizacje obsługujące jedną lub więcej domen. Serwery te przechowują właściwy dla danej organizacji fragment bazy i udostępniają posiadane informacje użytkownikom sieci, którzy o to poproszą. Na przykład domenę pw.edu.pl. należącą do Politechniki Warszawskiej obsługują serwery europa.coi.pw.edu.pl oraz io.pw.edu.pl. Jeżeli jakiś użytkownik będzie chciał połączyć się z serwerem www Politechniki www.pw.edu.pl i zapyta o adres IP tego serwera, to pośrednio albo bezpośrednio otrzyma odpowiedź właśnie z serwerów europa/io.coi.pw.edu.pl.

Podstawą fizycznej realizacji systemu nazw są serwery DNS zaimplementowane w postaci specjalnych programów komputerowych. Jakkolwiek działanie wszystkich serwerów opiera się na kilku, bardzo podobnych aplikacjach, to ze względów praktycznych poszczególne serwery różnią się między sobą funkcjonalnością. Różnice te wynikają tylko i wyłącznie ze sposobu konfiguracji, odzwierciedlającej politykę danej firmy, a nie ze względu na stosowane oprogramowanie. To jak zostanie skonfigurowany dany serwer zależy przede wszystkim od zakresu przechowywanych danych oraz budowy sieci komputerowej firmy.

Podstawowym typem serwerów DNS są serwery główne. Z praktycznego punktu widzenia każdy serwer przechowujący dane źródłowe jest traktowany jako serwer główny dla danego poziomu w hierarchii nazw domenowych. Wśród tego typu serwerów szczególną funkcję pełnią tzw. „root serwery”, czyli serwery przechowujące informacje o serwerach głównych, obsługujących domeny pierwszego poziomu. Ze względu na dość specyficzną rolę, która ma krytyczne znaczenie dla sprawnego działania całego systemu nazw w Internecie, serwery te realizują tylko i wyłącznie tę jedną funkcjonalność. Wszystkie inne serwery DNS muszą znać adresy „root serwerów”, co jest podstawowym warunkiem umożliwiającym rozwiązanie wszystkich poprawnych nazw.

Na każdym poziomie systemu nazw instalowane są tzw. „master serwery”, przechowujące dane źródłowe dla konkretnego poddrzewa danego poziomu. W zależności od możliwości firmy, serwery te mogą ograniczać się jedynie do tej jednej funkcjonalności albo mogą świadczyć szerszy zakres usług w sieci, np. udzielać odpowiedzi bezpośrednio stacjom klienckim. Na ogół, w celu podniesienia poziomu bezpieczeństwa sieci, serwery te oprócz przechowywania danych źródłowych, świadczą jedynie usługi polegające na transferze pełnych danych do serwerów zapasowych oraz udzielaniu odpowiedzi dotyczących domen zależnych.

Serwery zapasowe także zaliczane są do serwerów głównych. W praktyce, klient jednakowo traktuje odpowiedzi uzyskane od serwera typu slave co i master. Zgodnie z normami, dopuszczalna liczba oficjalnych serwerów głównych (master i slave) wynosi pięć.

Praca serwera typu slave polega na transferowaniu informacji z serwera typu master zawsze wtedy, gdy serwer typu slave nie ma odpowiednich danych albo gdy dane uległy zmianie. Serwer typu slave okresowo porównuje wersję danych, które posiada z wersją danych znajdujących się na serwerze typu master. Jeżeli wersje różnią się między sobą (wersja master jest nowsza niż wersja slave), serwer typu slave dokonuje transferu danych z serwera typu master. Najnowsze serwery DNS umożliwiają bardziej efektywny sposób synchronizacji danych poprzez informowanie serwerów pomocniczych o zmianie wersji oraz transfer tylko tych danych, które uległy zmianie.

Bardzo częstym sposobem konfiguracji serwerów jest łączenie obu funkcji master i slave w jednym serwerze w ten sposób, że dany serwer pełni rolę serwera typu master dla domeny „A” oraz serwera typu slave dla domeny „B”, natomiast serwer typu master dla domeny „B” pełni rolę serwera typu slave dla domeny „A”. Sytuacje takie występują najczęściej w sieciach korporacyjnych oraz uniwersyteckich sieciach kampusowych.

Oprócz serwerów oficjalnych, w sieci można zainstalować rozsądnie dowolną liczbę serwerów typu slave. Dodatkowe serwery typu slave instalowane są najczęściej w poszczególnych segmentach sieci komputerowej i obsługują tylko i wyłącznie komputery należące do danego segmentu. Dzięki temu następuje zmniejszenie ruchu z Internetem poprzez ograniczenie zapytań do zewnętrznych serwerów DNS. Wszystkie podobne zapytania od pojedynczych stacji obsługiwane są przez wewnętrzny serwer typu slave, który tylko raz wysyła zapytanie do serwerów zewnętrznych, a potem przez pewien czas przechowuje uzyskane odpowiedzi w pamięci podręcznej i na tej podstawie udziela odpowiedzi. Innym przykładem wykorzystania serwerów typu slave jest instalacja takiego serwera na komputerze świadczącym inne usługi sieciowe, np. poczta elektroniczna, WWW. Praca serwerów usługowych związana jest z istnieniem wielu podrzędnych instancji serwera danej usługi, które tworzone są w momencie wystąpienia zapytania z sieci. Każda taka instancja jest potencjalnym klientem systemu nazw. W wyniku lokalnej obsługi zapytań występują nie tylko oszczędności pasma związane z łączem do Internetu ale także z łączem danego serwera do sieci lokalnej. W przypadku zbyt dużej liczby serwerów pomocniczych może wystąpić efekt odwrotny, polegający na zbyt dużym obciążeniu ruterów komunikacją między serwerem typu master a serwerami typu slave. Jeżeli konfiguracja sieci uzasadnia potrzebę instalacji tak dużej liczby serwerów pomocniczych, wtedy wybrane serwery typu slave pełnią rolę serwerów typu master dla pozostałych serwerów typu slave. Zależności pomiędzy serwerami konfiguruje się w taki sposób, aby możliwie maksymalnie ograniczyć ruch w sieci związany z transferem danych między serwerami. Wielostopniowa konfiguracja serwerów typu slave oznacza istotne zwiększenie stopnia złożoności systemu, co w konsekwencji oznacza zwiększenie bezwładności systemu oraz powoduje większe utrudnienia w utrzymaniu systemu w ruchu.

Jedną z funkcji serwerów DNS jest buforowanie danych, które zostały uzyskane w wyniku procesu wyszukiwania. Jeżeli serwer nie został skonfigurowany do przechowywania danych dla konkretnego fragmentu systemu nazw jako serwer typu master lub slave, to taki serwer nazywa się serwerem buforującym. Jego jedynym zadaniem jest wyszukiwanie danych i ich buforowanie. Podstawową informacją, na podstawie której serwer buforujący poszukuje danych jest baza adresów serwerów typu root.

Tego typu serwery przeznaczone są na ogół do obsługi segmentu sieci, którego są członkami.

Funkcjonalność serwera typu forward nie wynika z konfiguracji, a ze sposobu jego użytkowania. Serwerem typu forward może być zarówno serwer typu master jak i slave, czy cache, który komunikuje się z serwerami zewnętrznymi w imieniu serwerów wewnętrznych. Jeżeli serwer wewnętrzny otrzyma zapytanie, które wymaga wyszukiwania w Internecie, przekazuje to zapytanie do konkretnego serwera, a ten dokonuje standardowego wyszukiwania danych komunikując się z serwerami zewnętrznymi. Tego typu konstrukcje stosuje się najczęściej w przypadku, gdy sieć wewnętrzna odseparowana jest od Internetu za pomocą FireWall’a i ze względów bezpieczeństwa serwery wewnętrzne komunikują się jedynie z serwerem typu forward, którego rolę pełni zwykły serwer DNS zainstalowany na hoście bastionowym w strefie zdemilitaryzowanej.

Działanie serwera DNS polega na wyszukiwaniu danych i ich buforowaniu oraz na ewentualnym przechowywaniu informacji stałych o ściśle określonym fragmencie systemu nazw. Na podstawie przechowywanych informacji, stałych lub buforowanych serwer DNS udziela odpowiedzi na otrzymane zapytania. Zapytania mogą mieć postać zapytań iteracyjnych albo rekurencyjnych.

W systemie operacyjnym każdego komputera znajduje się zestaw funkcji bibliotecznych przeznaczonych do komunikacji z serwerami nazw. Każda aplikacja wykorzystuje te funkcje do rozwiązywania nazw hostów, do których wysyła pakiety. W celu rozwiązania nazwy hosta, funkcje biblioteczne zadają pytanie serwerowi nazw, którego internetowy adres IP znajduje się w ściśle określonych plikach konfiguracyjnych systemu operacyjnego.

Proces rekurencyjny polega na tym, że serwer po otrzymaniu zapytania bierze na siebie cały ciężar znalezienia odpowiedzi na zapytanie przesłane od klienta. Na rysunku przedstawiono proces rozwiązywania nazwy składający się w całości z zapytań rekurencyjnych.

W praktyce jedynie lokalne serwery nazw dopuszczają zapytania rekurencyjne pochodzące tylko i wyłącznie od klientów znajdujących się w danym segmencie sieci, gdyż oprogramowanie resolvera nie potrafi samodzielnie szukać rozwiązań w przestrzeni nazw. Natomiast, lokalny serwer nazw po otrzymaniu od klienta pytania rekurencyjnego poszukuje odpowiedzi za pomocą pytań iteracyjnych.

Iteracyjny sposób rozwiązywania nazw dla odmiany polega tym, że serwer zwraca najlepszą odpowiedź jaką ma w bazie albo w buforze. W skrajnym przypadku zwraca adres serwera typu root.

Na przykład, jeżeli trzeba rozwiązać nazwę www.pw.edu.pl klient wysyła zapytanie rekurencyjne do serwera DNS, którego adres znajduje się w plikach konfiguracyjnych systemu operacyjnego. Serwer DNS sprawdza, czy w buforze znajduje się informacja dotycząca tej nazwy. Jeżeli tak, to zwraca do klienta odpowiedź. Jeżeli nie ma takiej nazwy w bazie albo w buforze, to sprawdza, czy master wie jaki serwer obsługuje domenę pw.edu.pl, potem domenę edu.pl i na końcu pl. Jeżeli serwer nie ma takiej informacji w buforze, to wysyła zapytanie do jednego z serwerów głównych typu root. W odpowiedzi otrzyma informację w postaci adresu serwera DNS obsługującego domenę pl, do którego wyśle zapytanie. Serwer obsługujący domenę pl w odpowiedzi prześle adres serwera obsługującego domenę edu.pl, do którego nasz serwer wyśle kolejne zapytanie i od którego otrzyma adres serwera DNS obsługującego domenę pw.edu.pl, który z kolei, jak należy się spodziewać w odpowiedzi zwróci adres IP odpowiadający nazwie www.pw.edu.pl. Przedstawiony przykład opisuje skrajny przypadek, gdy żaden z serwerów DNS nie wie nic więcej poza adresem serwera domeny podrzędnej wchodzącej w skład nazwy. W praktyce, jeżeli jakiś serwer będzie miał w buforze szukany adres albo adres serwera obsługującego domenę tworzącą nazwę lub jej fragment, to zwróci tę informację przez co znacznie skróci proces poszukiwania rozwiązania. Oczywiście serwer DNS poszukując odpowiedzi gromadzi w buforze wszystkie otrzymane odpowiedzi przez ściśle określony czas. Jeżeli w tym czasie otrzyma zapytanie dotyczące, np. nazwy www.ee.pw.edu.pl, to rozpocznie przeszukiwanie od serwera obsługującego domenę pw.edu.pl. Natomiast poszukując rozwiązania dla nazwy www.fuw.edu.pl skieruje pierwsze zapytanie do serwera obsługującego domenę edu.pl.

Najpopularniejszą fizyczną implementacją serwera DNS jest program o nazwie BIND, który na ogół stanowi jeden z elementów składowych wszystkich systemów operacyjnych z rodziny UNIX i LINUX.

Obecnie dostępnych jest kilka implementacji serwerów DNS, które można pobrać z Internetu w postaci programów źródłowych lub w postaci binarnej dla konkretnej platformy programowo sprzętowej.

Aby aplikacje pracujące w danym systemie operacyjnym mogły korzystać z systemu nazw, należy w systemie operacyjnym skonfigurować reslover. Resolver tworzy zbiór programów bibliotecznych systemu operacyjnego, które odpowiadają za komunikację z serwerami DNS.

W przypadku systemów UNIX i LINUX konfiguracja wykonywana jest w postaci odpowiednich deklaracji w ściśle określonych plikach. Wpisy dokonywane są albo bezpośrednio za pomocą edytora tekstowego ed lub vi, lub innego kompatybilnego z tymi edytorami, albo za pomocą aplikacji graficznej dostarczonej z systemem. W przypadku dokonywania wpisów bezpośrednich, należy upewnić się czy sposób zapisu tekstu do pliku jest zgodny ze specyfikacją konkretnego systemu operacyjnego (znaki zakończenia linii oraz znaki zakończenia pliku). W przypadku systemów z rodziny M$ Windows konfigurację resolver’a wykonuje się albo za pomocą aplikacji graficznej, albo automatycznie z serwera DHCP, co jest znacznie częstszą praktyką.

W systemach operacyjnych typu UNIX i LINUX konfigurację resolvera zaczyna się od ustawienia odpowiedniej deklaracji w pliku nsswitch.conf (NameServiceSWITCH.CONFiguration), który na ogół znajduje się w katalogu /etc. W pliku tym definiuje się serwisy oraz kolejność ich przeszukiwania w celu znalezienia konkretnej informacji. W przypadku rozwiązywania nazw istnieje wiele serwisów umożliwiających rozwiązanie nazwy: plik hosts (opcja „files”), dns, nis, nisplus, ldap i inne. W celu wymuszenia przeszukiwania serwerów DNS należy w pliku nsswitch.conf umieścić odpowiednią deklarację w opcjach hosts oraz ipnodes. Opcja ipnodes i związana jest z obsługą adresów IPv6.

Następnie należy wpisać odpowiednie deklaracje do pliku resolv.conf, który także na ogół znajduje się w katalogu /etc. W pliku tym powinna znajdować co najmniej jedna deklaracja „nameserver”, wskazująca adres IP serwera DNS. Serwer ten będzie każdorazowo pytany przez aplikacje uruchomione w danym systemie operacyjnym podczas poszukiwania rozwiązań dla nazw. W deklaracji tej możemy podać dowolny serwer w Internecie, jednak zazwyczaj podawany jest adres serwera właściwego dla danego segmentu sieci, ze względu na szybkość odpowiedzi, ale przede wszystkim, ze względu na fakt, że ten inny serwer może odmówić udzielenia odpowiedzi. Jeżeli na danym hoście uruchomiony jest serwer DNS, to jako adres IP serwera DNS podaje się numer IP: 127.0.0.1. Zgodnie z normami w pliku resolv.conf może znajdować się nie więcej niż 3 deklaracje typu „nameserver”. W pliku tym można zadeklarować domyślną nazwę domeny za pomocą deklaracji „domain”, co spowoduje, że do każdej nazwy niezakończonej kropką automatycznie będzie dołączany zadeklarowany ciąg znaków. Jeżeli dana organizacja składa się z wielu jednostek posiadających własne domeny, lub komputery tej organizacji w zdecydowanej większości przypadków kontaktują się z nieliczną grupą ściśle określonych domen, to zamiast deklaracji „domain” można użyć deklaracji „search” z listą nazw domen. Podczas poszukiwania odpowiedzi nazwy domen podanych w opcji „search” będą dołączane według kolejności w liście do nazwy poszukiwanej, o ile ta nie kończy się znakiem kropki. Proces poszukiwań kończy się w chwili znalezienia pierwszej, poprawnej odpowiedzi.

W systemach M$ Windows konfiguracji resolvera dokonuje się za pomocą aplikacji graficznej dostępnej, np. w następujący sposób:

START → Panel sterowania → Połączenia sieciowe → Połączenie lokalne → Właściwości → Protokół internetowy (TCP/IP) → Właściwości.

Za pomocą tej aplikacji można ustawić wszystkie parametry związane z komunikacją z siecią komputerową. Najczęściej wybieraną konfiguracją jest konfiguracja automatyczna. Ustawienia pochodzące z konfiguracji automatycznej można zmienić wpisując swoje własne parametry. Ponadto, podobnie jak w systemach UNIX i LINUX można zadeklarować domenę domyślną komputera oraz domeny używane podczas przeszukiwania.

W przypadku, gdy dystrybucja adresów IP odbywa się w sposób całkowicie przypadkowy, konkretna stacja robocza może za każdym razem otrzymywać inny adres IP. Zatem, w celu zachowania spójności systemu nazw opracowano system tzw. dynamicznego DNS’u, w którym stacja robocza, po otrzymaniu z serwera DHCP wartości parametrów sieciowych może dokonać odpowiedniego wpisu do baz serwera DNS.

W zwykłych konfiguracjach opcja dynamicznego uaktualniania baz DNS jest zablokowana po stronie serwera. Natomiast, mechanizm ten jest bardzo intensywnie wykorzystywany w środowisku Active Directory firmy Microsoft, dlatego też opcja ta w domyślnej konfiguracji interfejsów sieciowych jest włączona. Staje się to przyczyną generowania zbędnego ruchu w sieci i niepotrzebnie absorbuje serwery DNS obsługą niedopuszczalnych zleceń. Zatem, opcję tą należy zawsze wyłączać, chyba że wymaga tego środowisko sieciowe, które w takim przypadku powinno być tak skonfigurowane, aby związany z tym ruch nie wychodził poza sieć lokalną.

Zamieszczony w tym module opis konfiguracji serwera DNS stanowi niezbędne minimum jakie należy wykonać, aby uruchomić poszczególne typy serwerów. Opis ten jest zgodny z implementacjami BIND w wersji 8 oraz 9 (widoki dotyczą tylko wersji 9). Natomiast, położenie plików konfiguracyjnych oraz sposób uruchamiania i zatrzymywania serwera został przedstawiony na podstawie systemu operacyjnego SUN Solaris. Przyjęto również założenie, że stosowne oprogramowanie aplikacyjne znajduje się już w systemie operacyjnym.

Podstawowym plikiem konfiguracyjnym systemu BIND 8/9 jest plik „named.conf”, znajdujący się zazwyczaj w katalogu /etc. Natomiast pliki z bazami danych, buforami, logami itp. umieszczane są w domyślnym katalogu bazowym /var/named. Katalog ten może zostać zmieniony odpowiednią deklaracją w pliku „named.conf”. Również nazwy wszystkich plików konfiguracyjnych mogą zostać ustawione dowolnie przez administratora systemu, jak i położenie tych plików wewnątrz katalogu bazowego. Pliki z bazami danych, to: baza root serwerów (root.cache), baza odwzorowania nazwy dla loopback (localhost.zone), baza odwrotnego odwzorowania dla loopback (localhost.rev), bazy odwzorowania dla poszczególnych stref. Podane w nawiasach nazwy plików zostały ustalone dla potrzeb niniejszego opisu.

W zależności od systemu operacyjnego istnieją różne sposoby konfigurowania procesu automatycznego uruchamiania się serwera DNS. W systemie SUN Solaris v.9 i niższe), serwer DNS uruchamiany jest jako jeden z procesów za pomocą skryptu startowego /etc/rc2.d/S72inetsvc poleceniem „/usr/sbin/in.named &”.

Buforowanie danych jest naturalną, jedną z podstawowych funkcjonalności serwera DNS, dlatego aby uruchomić serwer DNS dowolnego typu należy zawsze zacząć od uruchomienia serwera buforującego.

Na konfigurację serwera buforującego składają się: baza root serwerów (root.cache), baza odwzorowania nazwy dla loopback (localhost.zone), baza odwrotnego odwzorowania dla loopback (localhost.rev), przy czym BIND v.9 nie wymaga stosowania pliku z bazą root serwerów, którą tworzy samodzielnie.

Slajd przedstawia pierwsza część pliku named.conf, zawierającą deklaracje „options” oraz „logging”.

Deklaracja „options” służy do ustawienia opcji podstawowych, jak np. położenie plików oraz innych opcji, o znaczeniu globalnym, obowiązujących we wszystkich innych deklaracjach, chyba że zostaną one jawnie zmienione w obszarze konkretnej deklaracji szczegółowej. W naszym przypadku pokazano deklaracje dwóch opcji: directory – określającą położenie katalogu bazowego, pid-file - określającą położenie pliku z numerem procesu serwera. Deklaracje te nie są wymagane, jeżeli wartości opcji są zgodne z wartościami domyślnymi. Jednak ze względów bezpieczeństwa zaleca się jawne deklarowanie wszystkich istotnych zmiennych, aby uniknąć sytuacji wieloznacznych. Szczegółowy wykaz opcji można znaleźć w dokumentacji systemowej.

Deklaracja logging dotyczy sposobu obsługi komunikatów systemowych. Jeżeli zostanie pominięta, to serwer poprzestanie na generowaniu standardowych komunikatów wynikających z działania w konkretnym systemie operacyjnym. Przedstawiona deklaracja pokazuje najprostszą możliwą konfigurację systemu logowania, zgodnie z którą wszystkie komunikaty będą zapisywane w pliku „/var/named/log”. W procesie uruchamiania serwera DNS logi z komunikatami stanowią nieocenioną pomoc w odnajdywaniu błędów w konfiguracji systemu. System BIND posiada możliwość bardzo precyzyjnej konfiguracji sposobu obsługi komunikatów, z którego szczegółowy opis można znaleźć w dokumentacji.

Slajd przedstawia drugą część minimalnej wersji pliku „named.conf”, zawierającą deklaracje dotyczące bazy root serwerów oraz mapowania prostego i odwrotnego dla interfejsu loopback. Wszystkie deklaracje wykonane są zgodnie ze składnią stosowaną do opisu stref.

Deklaracja root serwerów składa się z deklaracji typu „hint” oraz nazwy pliku zawierającego bazę root serwerów. Typ „hint” oznacza, że baza ma charakter bufora. Podobnie wygląda sprawa deklaracji dla interfejsów loopback, przy czym w tym przypadku występują deklaracje typu master, a pliki z bazami są zbudowane zgodnie ze składnią plików opisujących zwykłe strefy.

Plik zawierający bazę root serwerów składa się z dwóch typów rekordów. Jeden typ to rekordy stosowane do opisu delegacji domeny:

. 3600000 IN NS A.ROOT...