1. Wiadomości wstępne


1.1. Co to jest DNS i dlaczego się go stosuje

Skrót DNS pochodzi z angielskiego Domain Name Service, bądź też Domain Name Servers i nie będę próbował go tłumaczyć, łatwiej bowiem posłużyć się skrótem, niż złym tłumaczeniem. Część z pojęć zostanie poddana tłumaczeniu na język polski w tekście, jednak towarzyszyć im będą nazwy oryginalne - szczególnie w przypadkach, gdy nie stosuje się polskich odpowiedników. Ponieważ tłumaczenia zawsze zostawiają możliwości interpretacji i wyboru słów, w tekście mogą pojawić się różne pojęcia oznaczające ten sam termin angielski.

DNS stosuje się dla wygody i zmyślą o użytkownikach rozległych sieci komputerowych a w szczególności (w obecnej dobie jej popularności) sieci Internet. Prawdopodobnie z myślą o tak dynamicznym (by nie powiedzieć agresywnym) rozwoju sieci komputerowych (np. Internetu) myślano o posłużeniu się takim rodzajem usług komputerowych.

W tym opracowaniu postaram się wytłumaczyć dlaczego stosuje się DNS, co się na niego składa i podam szczegóły techniczne dotyczące rozwiązań obecnie stosowanych w DNS.

1.2. Nazwy i adresy w sieci komputerowej

Wyobraźmy sobie środowisko sieciowe, w którym mogą znajdować się różne typy obiektów (oczywiście może być ich wiele z każdego rodzaju). Niech będą to przykładowo:

Użytkownicy sieci będą na pewno chcielikorzystać z tych wszystkich (lub części) urządzeń w środowisku sieciowym. Aby jednak z nich skorzystać każdemu z nich musimy przyznać adres sieciowy, zarezerwowany tylko dla tego obiektu. Najprościej jest to zrobić przy użyciu adresów cyfrowych (łatwo "przyswajanych" przez komputer).

I tu pojawia się pierwszy złożony problem. Taki adres:

Z punktu widzenia zwykłego użytkownika najbardziej niewygodnym jest trudność w zapamiętaniu adresu, ponieważ trzeba użyć odpowiednio dużej liczby do opisania wszystkich obiektów w sieci.

1.3. Nazwy obiektów a ich adresy

Aby jakoś sobie poradzić trzeba by rozwiązać po kolei wszystkie wyżej wymienione problemy jakie stawia adresowanie obiektów w sieci komputerowej.

Każdy użytkownik wolałby używać zamiast adresu (długiego ciągu cyfr) czegoś bardziej naturalnego - nazwy. Jakie byłyby dobre strony używania nazw dla obiektów w sieci komputerowej:

Przykład:

	Obiekt:		host (komputer) rozsyłający pocztę (mail relay host)  	Adres:		131.130.17.5  	Nazwa:		MAIL-RELAY  

Tylko teraz należy postawić pytanie: jak połączyć (skojarzyć) adresy sieciowe i nazwy?

I właśnie do tego służy DNS - jest "klejem" łączącym adresy sieciowe z obiektami (komputerami/host'ami) z nazwami jakimi się posługują wszyscy użytkownicy.

1.4. Sytuacja panująca w Internecie

Nikt początkowo nie zakładał tak gwałtownego rozwoju Internetu w momencie gdy on powstawał (a przecież na początku był to wojskowy eksperyment). Dziś Internet jest największą ogólnoświatową siecią komputerową. Liczbę użytkowników szacuje się na kilkanaście milionów na całym świecie.

Początek Internetu datuje się na rok 1969, kiedy to projekt ARPA (Advanced Research Project Agency) został wprowadzony w życie. Rozwój liczby komputerów podłączonych do Internetu można prześledzić na Tabeli 1.
Rozwój rozpoczęto od zbudowania 15 węzłów i połączenia 23 komputerów. Z końcem marca 1996 w samej Europie jest już 2.5 miliona komputerów w sieci Internet.

Tabela 1.
Liczba hostów w Europie
Data Liczba hostów Data Liczba hostów Data Liczba hostów
1971 23 Luty 1986 2,000 Wrzesień 1991 617,000
1974 62 Listopad 1986 5,000 1992 1,000,000
1982 235 1987 20,000 1993 2,000,000
1983 500 1989 100,000 1994 3,000,000
1984 1000 Styczeń 1991 376,000 1995 4,000,000

Praktyczną koordynacją całej sieci Internet zajmują się dwie organizacje:

Lokalne sieci są administrowane przez lokalne organizacje i lokalnych administratorów.

Adres głównej domeny sieciowej jest przyznawany przez GSI lub RIPE lub też lokalnych rejestratorów (local registers), natomiast adresy sieciowe poszczególnych komputerów wpiętych do sieci (lub podsieci lokalnych) ustalane są przez administratorów (po uprzednim sprawdzeniu, czy taki numer nie jest już zajęty przez inny host). Nazwy host'ów ustala się lokalnie.

Przykład:
Nowy host (komputer - wyrażenia mogą być stosowane zamiennie) musi otrzymać poprawną nazwę w obrębie domeny, lecz nie jest konieczne informowanie o tym fakcie GSI lub innych organizacji (a nawet innych administratorów lokalnych).
Jednakże, by mieć dostęp do nowego host'a z zewnątrz (innych sieci) informacja na temat jego istnienia musi być ogólnodostępna w Internecie.

1.5. łączenie nazw z adresami host'ów

Skoro już wiemy, że adresom komputerów musimy skojarzyć nazwy, które użytkownicy mogliby łatwo pamiętać, czas się uporać z przedstawieniem rozwiązania, które byłoby najbardziej optymalne.

Potrzebny jest system dystrybucji nazw skojarzonych z adresami.

Przykład:
Został zainstalowany nowy komputer, nadano mu adres i nazwę. Ten nowy host powinien być widziany z każdego miejsca w Internecie. Host jest znany tylko z nazwy., ponieważ wszyscy użytkownicy wolą stosować nazwy a nie adresy sieciowe.

Pytania:

  1. W jaki sposób można się z tym host'em skontaktować i gdzie powinna być przechowywana informacja o tym, z jakim adresem sieciowym należy nawiązać połączenie?
  2. Jeżeli host zmieni adres (np. z przyczyn technicznych), jak w takim razie inni użytkownicy Internetu będą się mogli o tym dowiedzieć?


Rozwiązanie pierwsze:

Informacja na temat adresów komputerów i ich nazw, jakimi się będą posługiwać użytkownicy będzie przechowywana w specjalnym pliku "hosts", którego zawartość będą stanowić dwa pola:

nazwa_host'a adres_Internet'owy

Dla uzyskania połączenia program będzie wyszukiwał nazwę host'a w pliku "hosts" i zamieniał go na adres i szukał już adresu sieciowego, aż do uzyskania połączenia.

Przykład:

	riad.usk.pk.edu.pl		149.156.132.152  

Należy teraz sobie wyobrazić sytuację taką, iż każdy host powinien móc się skontaktować z każdym innym znajdującym się Internecie. Czyli każdy host potrzebuje pliku "hosts" zawierającego adresy i nazwy wszystkich innych komputerów w sieci.
NIE JEST TO WYKONALNE!

Przykład:
Administrator sieci lokalnej chce zmienić adres jednego z host'ów lub też chce dodać nowy komputer do sieci.
Wszystkie pliki "hosts" w komputerach w Internecie muszą być zmienione! Dla przypomnienia - obecna przybliżona liczba komputerów podłączonych do Internetu w samej Europie - 25000000.

Oczywiście nie byłoby to wykonalne obecnie, w dzisiejszych czasach. Początek historii Internetu był jednak skromny i właśnie podobne rozwiązanie przyjęto na samym jego początku. Mapowanie nazw host'ów na adresy Internetowe (host name mapping) było zarządzane przez specjalną organizację sieciową NIC (Network Information Center) i było zapisywane do pojedynczego pliku HOSTS.TXT, który był później rozsyłany FTP'em do wszystkich host'ów. Ponieważ jednak zmniejszenie przepustowości całej sieci spowodowane transferem nowych wersji plików HOSTS.TXT postępowało w przyroście kwadratowym (nawet przy użyciu wielopoziomowych sesji FTP) obciążenie serwera NIC'u było znaczne. Lawinowy rozwój Internetu pokazał bezzasadność dalszego stosowania tej metody.

Do tego zmieniał się charakter sieci. Pierwotna sieć ARPANET (składająca się z komputerów wielodostępnych) przekształcała się w skomplikowany organizm sieci lokalnych (z np. stacjami roboczymi). Lokalne organizacje i administratorzy musieli czekać na zmianę wpisów do pliku HOSTS.TXT dokonywanych przez NIC. Struktura sieci komplikowała się i wymagała nowej metody na zarządzanie nazwami i adresami.

Rozwiązanie drugie:

Jeżeli ma dojść do komunikacji między dwoma komputerami, program pobiera nazwę host'a i wysyła pytanie do specjalnego serwera (name server) o powiązany z tą nazwą adres sieciowy.

Name server zna adresy wszystkich lokalnych komputerów w zdefiniowanej strefie, jaką obsługuje (sieci lokalnej).

Name server zna adresy innych name server'ów w Internecie.

Jeżeli więc skądś nadchodzi zapytanie (query) o adres komputera po podaniu nazwy tego komputera, name server może:

Potrzebne jest teraz zdefiniowanie struktury hierarchicznej, która mogłaby reprezentować strukturę sieci oraz dokonać podziału na strefy, by każdy z name server'ów mógł odpowiadać tylko za jedną strefę - domenę (domain). W ten sposób informacja na temat obecności komputerów w sieci byłaby ogólnie dostępna a przechowywanie i modyfikowanie informacji nie sprawiałoby kłopotu. Za zmianę i przechowanie nowego adresu w sieci lokalnej odpowiadałby tylko lokalny name server a nie cała sieć. W ten sposób informacje są przechowywane tylko tam, gdzie powinny - lokalnie.

Sposób szukania i odczytywania (resolving) adresu przez name server jest opisany w Rozdziale 2.6.4.

1.6. Cele serwisu DNS

Zatem podstawowe cele postawione w projektowaniu serwisu DNS mają oczywiście wpływ na jego strukturę.

System domen zapewnia kilka z powyższych postulatów:

Przykład:
Fizycznie, resolver może być ulokowany na tym samym komputerze co name server i mogą dzielić wspólną bazę danych składającą się ze stref zarządzanych przez tenże name server a cache'owanych przez tenże resolver.

 

2. Dokładny opis serwisu DNS


2.1. Składniki DNS

Na pojęcie DNS składają się trzy podstawowe elementy:

  1. DOMAIN NAME SPACE oraz RESOURCE RECORDS, które specyfikują strukturę drzewa przestrzeni nazw i danych związanych z tymi nazwami. Każda gałąź i każdy liść drzewa DNSPACE zawiera pewien zbiór informacji i sposoby (rodzaje zapytań - queries) potrzebne do uzyskania chcianej informacji z całego zbioru. Zapytanie wyszczególnia domenę, która go interesuje, oraz określa rodzaj informacji, jakiej potrzebuje.
  2. NAME SERVERS są programami, które przechowują informacje o drzewie struktury domeny i zbiorach informacji. Name server może cache'ować jakiś dowolny fragment struktury sieci, ale generalnie Name Sever zawiera kompletną informację na temat fragmentu przestrzeni nazw i wskaźniki do innych name server'ów, które zapewniają informacje dla pozostałych części lub innych domen. Name Server zna całą część domeny, o której ma kompletną informację i mówi się, że jest autorytatywny dla niej (authoritative). Miarodajne (autorytatywne) informacje są organizowane w jednostki zwane dalej strefami (zones).
  3. RESOLVERS są również programami, które wyciągają informację od name server'ów w celu udzielenia informacji na pytania żądane przez komputery - klientów. Resolver musi mieć dostęp do co najmniej jednego name server'a, by móc odpowiedzieć na pytanie bezpośrednio, lub wymóc żądanie odpytania innych name server'ów. Żaden protokół nie jest potrzebny do komunikacji między programem użytkownika a Resolver'em, ponieważ ten ostatni jest zwykle wywołaniem systemowym dostępnym bezpośrednio z programów.

Te trzy składniki dość dobrze oddają trzy perspektywy systemu domenowego:


2.2. DNS Space

2.2.1. Definicje

Domain Name Space ma strukturę drzewiastą. Każdy węzeł i liść na drzewie reprezentuje pewien zbiór zasobów (który może być pusty). System domenowy nie widzi różnicy między węzłami a liśćmi, więc dalej posługiwać się będę terminem węzeł w odniesieniu do oby składników struktury drzewiastej.

Każdy węzeł posiada etykietę (label) o długości od 0 do 63 oktetów. Węzły na tym samym poziomie (bracia) nie muszą mieć tej samej etykiety, natomiast tą samą etykietą można nazwać węzły nie będące braćmi. Jedna etykieta została zarezerwowana (null - o zerowej długości) dla korzenia (root).

Nazwą domeny (Domain Name) węzła jest lista etykiet powstająca w wyniku złożenia etykiet podczas przejścia od węzła do korzenia. Przyjęto konwencję, w której etykieta składająca się na nazwę domeny jest zapisywana od lewej do prawej, od najniższego węzła do korzenia.

Programy posługujące się nazwami domen powinny je przedstawiać jako sekwencje etykiet, z których każda składa się z oktetu określającego długość etykiety i oktetu będącego ciągiem znaków (string).

Dla użytkownika oktety określające długości etykiet są niewidoczne, natomiast same etykiety rozdzielane są kropką (.) - patrz opis składni nazwy domeny w Rozdziale 2.2.3.

Ponieważ kompletna nazwa kończy się etykietą korzenia, każda nazwa zakończona jest dodatkową kropką. Pozwala to rozróżnić między dwoma sytuacjami:

Aby zapewnić prostotę rozwiązań implementacyjnych całkowitą liczbę oktetów reprezentujących nazwę domeny (czyli sumę oktetów przeznaczonych na etykiety i długości etykiet) ograniczono do 255.

2.2.2. Klasy domen

W Internecie każdy oktet reprezentuje odrębną klasę poddomeny i w zależności od klasy nazwa jest nadawana przez organizacje Internetowe lub przez lokalnych administratorów.

Adresy IP host'ów Internetowych podzielone zostały na 4 oktety określające domeny i poddomeny (tak więc nazwa host'a, która jest ograniczona do 128 etykiet musi zostać zapisana w postaci 4 oktetów adresu IP).

I tak - przykładowo komputer o nazwie riad.usk.pk.edu.pl ma adres IP: 149.156.132.152.

Przyjmuje się, że adres IP o postaci A.B.C.D reprezentuje poszczególne klasy domen.

Numer w każdym oktecie musi się zawierać w przedziale od 0 do 255 (tak więc na każdą klasę w adresie IP przypada po 255 unikalnych numerów IP).


2.2.3. Składnia nazw domen

Aby móc skorzystać z usług name server'ów musimy skonstruować mechanizm do tworzenia struktur jednostek organizacyjnych, będących częścią Internetu (strefy - zones). Każdy host musi zostać przypisany do takiej strefy.

Jako rozwiązanie podano system nazwany Domain Naming. W ten sposób nazwa host'a reprezentuje swoje miejsce w strukturze organizacyjnej sieci.

Jak wygląda nazwa domeny (Domain Name) w praktyce? Otóż składa się z nazwy komputera oraz nazw jednostek organizacyjnych, które jednostki nazywa się popularnie domenami (domains). Należy dodać, iż domeny i poddomeny mogą być pogrupowane w strefy (zones). Dokładne wytłumaczenie subtelności w różnicy pomiędzy strefą a domeną można znaleźć w Rozdziale 2.4.3.

Uproszczony schemat tworzenia Domain Name dla pewnego komputera:

	hostname(.subdomain)*.topleveldomain    gdzie odpowiednio:   - hostname		nazwa host'a (komputera, któremu jest przypisywana nazwa)   - subdomain		poddomena (może ich być kilka)   - topleveldomain	główna domena (patrz Rozdziały 2.2.2. i 2.2.4.)  

Przykład:

	riad.usk.pk.edu.pl    gdzie odpowiednio:   - riad		nazwa konkretnego komputera   - usk		domena Uczelniana Sieć Komputerowa   - pk		domena Politechnika Krakowska   - edu		strefa edukacyjna w Polsce   - pl		domena Polska (topleveldomain)  

Dla wszystkich przyzwyczajonych do bardziej formalnych definicji poniżej podana zostaje definicja w zapisie BNC.

<domain> ::= <subdomain> | ""  <subdomain> := <label> | <subdomain>"."<label>  <label> ::= <letter> [ [ <ldh-str> ] <let-digit> ]  <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>  <let-dig-hyp> ::= <let-dig> | "-" <let-dig> ::= <letter> | <digit>  <letter> ::= [A-Z][a-z]  <digit> ::= [0-9]  

2.2.4. Oznaczenia domen w Internecie

W Internecie przyjęto pewne konwencje co do zapisu nazw domen. Pozostałości historycznej już części ARPANET (protoplasty Internetu) i podziału na pierwsze domeny w U.S.A. Podczas formowania sieci Internet pierwotną jej nazwą była właśnie ARPANET, a dopiero potem wydzielono sieć MILNET (częściowo obecna domena .mil) i utworzono pozostałe pierwsze domeny Internetowe.

W Tabeli 2. podano najczęściej spotykane domeny główne (top level domains), wraz z już historycznymi.

Tabela 2.

Top Level Domains
USA .arpa historyczna część ARPANET
.edu domena edukacyjna - sieci akademickie
.com domena komercyjna
.gov domena rządowa
.mil domena wojskowa
.org organizacje (tzw. non-profit)
.net specjalne organizacje sieci Internet Europa .pl Polska
.de Niemcy
.fi Finlandia
.nl Holandia
.se Szwecja
.uk Zjednoczone Królestwo
.es Hiszpania
.at Austria
.fr Francja
Inne kraje .au Australia
.va Watykan
.za Republika Południowej Afryki
.su Rosja (i kraje byłego ZSRR)

Dokładny opis kodów dla wszystkich krajów można znaleźć w dokumencie ISO3166. Lub zobaczyć do Dodatku E.

2.2.5. Sytuacja Internetu w Polsce i Europie

Według najnowszych danych (na dzień 29 Marca 1996, poprzedni zapis 1 Marca) sytuacja w Europie przedstawia się jak podano w Tabeli 3. Uaktualnione dane można znaleźć na serwerze WWW: http://www.ripe.net/ lub w pliku: ftp://ftp.ripe.net/ripe/hostcount/RIPE-Hostcount

Tabela 3.

   Kraj (nazwa domeny)        Liczba host'ów       Zmiana                  .at                          62,574       - 2,003               .de                         516,342       +29,534               .dk                          59,851       + 4,400               .fr                         154,030       - 1,615               .fi                         230,702        - 7233               .it                          92,305       + 4,916               .nl                         185,625       + 1,316               .no                         104,843       + 7,449               .pl                          30,359       + 2,602               .se                         157,730       - 3,842               .su                          12,618        +  469               .uk                         504,950       +21,840              (...)                                                          W sumie                     2,483,833       +77,326       cała                                                   Europa                                                  

2.2.6. Drzewo hierarchiczne struktury domeny .pl

Struktura Internetu zaczyna być coraz bardziej skomplikowana, pojawia się bowiem coraz więcej domen wewnątrz domeny głównej. Każde z miast wojewódzkich ma swoją domenę (np. krakow.pl, lodz.pl, wroc.pl), oprócz tego jest mnóstwo domen komercyjnych (np. tpsa.pl, gazeta.pl, pse.pl, rsw.pl, tpnet.pl, computerland.pl) i oczywiście domeny edu.pl, gov.pl, net.pl, nask.pl, com.pl.

Uproszczone drzewo domeny .pl można zobaczyć na Rysunku 1.

Rysunek 1. Uproszczone drzewo domeny .pl

Pełen wykaz domen w Polsce (aktualny na dzień 1 maja 1996 został zamieszczony w Dodatku D.

2.2.7. Domena Internetowa .in-adress.arpa

Programy komunikacyjne przesyłają dane w postaci pakietów TCP/IP (Transmission Control Protocol/Internet Protocol), które mogą zawierać jedynie adresy adres TCP/IP nadawcy.

Jednak host - odbiorca chciałby znać także nazwę a nie tylko adres host'a - nadawcy.

Potrzebny jest więc mechanizm ponownej translacji z adresu na pełną nazwę komputera (full domain name).

Oczywiście można do tego użyć name server'a.

Do tego celu stworzono specjalną domenę w sieci Internet, nazwaną .in-adress.arpa, która spełnia wyżej wymienione założenie. Wszystkie sieci TCP/IP są ulokowane w tej domenie.

Przykład:

	Adres:			149.156.96.9  	Reverse Name:		9.96.156.149.in-addr.arpa  	Nazwa komputera:	galaxy.uci.agh.edu.pl  

Dzięki tej domenie możliwy jest mechanizm bezbłędnego mapowania (mapping) adresu Internetowego na nazwę host'a, jak również lokalizacji wszystkich gateways w danej sieci lokalnej podłączonej do Internetu.

2.2.8. Odwrócone drzewo hierarchiczne

Rysunek 2. przedstawia odwrócone drzewo hierarchiczne dla przykładowego komputera.

Rysunek 2. Odwrócone drzewo hierarchiczne

2.3. Name servers

2.3.1. Definicje

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:


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  (...)  

2.3.2. Rodzaje name server'ów

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


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.
Jeszcze w roku 1995 było siedem ROOT SERVER'ów:

	aos.brl.mil  	c.nyser.net  	kava.nisc.sri.com  	nic.nordu.net  	ns.nasa.gov  	ns.nic.ddn.mil  	terp.umd.edu  

Po gruntownej reorganizacji w strukturze ROOT SERVER'ów Internetu obecnie funkcjonują ROOT SERVER'y podane w Tabeli 4.

Tabela 4.

       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:

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.

Jak odbywa się ładowanie plików z bazy danych?
Otóż 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 ładujedane 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. Rysunek 3.

2.3.3. Najczęstsze konfiguracje włączenia host'a w DNS

Komputer wpięty 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. Rysunek 4.
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. Rysunek 5.
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. Rysunek 6.
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. Rysunek 7.
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. Rysunek 8.

2.4. Resource Records

2.4.1. Definicje standardu

Nazwy domen zawarte w przekazywanych informacjach mają postać ciągu etykiet, z których każda jest reprezentowana prze dwa oktety - jeden określający długość pola etykiety, drugi zawierający właściwą nazwę etykiety (patrz Rozdział 2.2.1.).
Nazwa domeny identyfikuje węzeł. Każdy węzeł może zawierać zbiór informacji, może też być pusty. Zbiór informacji związany z konkretną nazwą składa się z pojedynczych rekordów zasobów (resource records - RRs). Kolejność RR w zbiorze nie ma znaczenia i nie musi być zapamiętywany przez name server'y, resolver'y, lub inne części DNS'u.

2.4.2. Składnia Resource Records

Format RR pozostaje niezmienny dla wszystkich zasobów. Składają się na niego takie elementy jak:

NAME
nazwa właściciela, to znaczy nazwa węzła, do którego się odnosI
TYPE
2 oktety zawierające jeden z kodów RR TYPE
CLASS
2 oktety zawierające jeden z kodów RR CLASS
TTL
liczba całkowita 32-bitowa, określająca czas w którym dane są przechowywane w cache'u (nie muszą być odświeżane i sprawdzane z oryginalną zawartością)
RDLENGTH
naturalna liczba 16-bitowa określająca długość oktetów w polu RDATA
RDATA
Zmiennej długości ciąg oktetów, opisujący informację źródłową. Format zależy od rodzaju TYPE i CLASS w rekordzie.

Najczęściej spotykane typy pól dla pozycji TYPE:

A
adres host'a
NS
autoryzowany name server
CNAME
nazwa kanoniczna dla aliasu
SOA
wskazuje początek strefy autoryzowanej
WKS
opis najbardziej znanych serwisów
PTR
wskaźnik nazwy domeny
HINFO
informacje o hoście
MX
wymiana poczty
TXT
ciąg tekstowy

Wartości pozycji CLASS:

IN
oznacza Internet
CS
już nie używany, tylko dla przykładu
CH
klasa systemu CHAOS
HS
Hesiod

Dokładnie omówiono poszczególne pola wpisów w Rozdziale 2.4.3., będącym przykładową implementacją DNS'u (BIND system).

RRs są reprezentowane fizycznie w postaci binarnej jako pakiety protokołu DNS i są zwykle zakodowane podczas przechowywania w name server'ach i resolver'ach.

Pojedynczy RR mieści się w jednej linii (choć możliwe jest zapisanie go w kilku, z użyciem nawiasów). Początek wiersza określa zawsze właściciela rekordu, choć często spotykane są puste pola dla poprawienia przejrzystości zapisu (puste pole owner oznacza, iż właściciel jest taki sam, jak w przypadku poprzedniego rekordu). Następne pola wypełnia się zgodnie ze standardową składnią opisaną powyżej.

2.4.3. Format wpisów dla programu BIND/Hesiod

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.

Niżej podany został format pozycji pliku bazowego Resource Record dla standardu BIND/Hesiod.

Format Of BIND/Hesiod File Entries

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.

Start of Authority Entry (SOA)

Określa początek strefy. Nie może być więcej niż jeden wpis SOA dla jednej strefy.
Format wpisu SOA:

name ttl addr-class entry-type origin person sesrial# refresh retry expire min

Poszczególne pola oznaczają:

name
Tutaj umieszczana jest nazwa host'a, na którym umieszczone są dane bazy. Zwykle jest nim główny serwer.
person
To pole definiuje login name i adres mail'owy osoby odpowiedzialnej za prowadzenie BIND'a/Hesiod'a w domenie lokalnej.
serial#
Pole przeznaczone jest na numer wersji pliku bazowego. Osoba edytująca pliki konfiguracyjne (master files) dla całej strefy powinna zwiększać o jeden wartość tego pola za każdym razem, kiedy dokonywane są zmiany w plikach. Zmiana numeru seryjnego informuje serwery drugorzędne (secondary servers) o konieczności dokonania zmian w plikach (skopiowania nowej informacji z głównego serwera). Maksymalna wartość wynosi 232-1 "po przecinku" (kropce oddzielającej wartości całkowite od dziesiętnych).

Numer seryjny pozwala na rozstrzygnięcie, która z dwóch kopii plików bazowych jest późniejsza. Zwykle serial # zaczyna się jedynką (1) i jest zwiększany o jeden za każdą zmianą zawartości pliku. Zaleca się używanie liczb naturalnych.

W praktyce używa się formatu rokmiesiącdzieńzmiana czyli np. wpis mogłby wyglądać tak: 1996050401.

refresh
Pole wyznacza jak często (w sekundach) serwer drugorzędny ma sprawdzać serwer główny, czy nie zachodzi potrzeba uaktualnienia plików. Jeżeli Pliki na serwerze drugorzędnym są nieaktualne (o czym świadczy inny serial # ) dane są kopiowane z głównego serwera.

Minimalny okres odświeżania to 30 sekund. Jeśli pole refresh nie zwiera żadnej wartości, dane nie są uaktualnianie automatycznie.

retry
To pole specyfikuje jak długo (w sekundach) drugorzędny server (secondary BIND/Hesiod server) będzie próbował odświeżyć dane, po tym jak podczas sprawdzania nastąpił błąd odświeżania. (Jeżeli server próbuje odświeżyć zawartość plików i kończy się to błędem, próbuje znowu, tyle sekund później, ile zostało zdefiniowane w tym polu).
expire
To pole określa dolny limit (w sekundach) czasu, w którym serwer drugorzędny może utrzymywać dane w cach'u bez potrzeby ich uaktualniania, lub do czasu, w którym serwer główny stwierdzi potrzebę uaktualnienia.
min
Pole specyfikuje domyślny minimalny czas ttl w przypadku, gdy pole ttl pozostawiono pustym.

Przykład:

Przykładowy wpis pola SOA. Średniki oznaczają komentarze - pierwsza linia określa pola dla łatwiejszej orientacji.

; name ttl addr-class entry-type   origin		person    @		IN	SOA	utah.states.dec.com hes.utah.states.dec.com  				( 1		; sesrial  				3600		; refresh - co godzinę  				300		; retry co 5 minut  				3600000	; expire co 1000 godzin  				86400 )	; min - ttl wynosi 24 godziny  
W powyższym przykładzie widać, że wartość ttl nie została zdefiniowana w polu ttl, co wskazuje na wyspecyfikowanie tej wartości w polu min.

Średniki pozwalają na zwiększenie czytelności zapisu i dodawanie komentarzy.

Name Server Entry

Wpis NS określa, że dany komputer jest name server'em dla podanej domeny.
Format NS

name ttl addr-class entry-type server

Poszczególne pola mają wartości zdefiniowane podobnie jak dla BIND File Entries, z wyjątkiem pola:
server
Tutaj umieszczana jest nazwa primary master server'a dla domeny wyszczególnionej w pierwszym polu..
Przykład:
Wpis pola NS:
; name ttl addr-class entry-type	server  		 IN	 NS	utah.states.dec.com  
W powyższym przykładzie widać, że wartość pierwszych dwóch pól nie została zdefiniowana. Używana jest nazwa domeny i ttl wyszczególnione we wpisie SOA.

Adress Entry

Wpis adresowy A wylicza wszystkie adresy poszczególnych komputerów.
Format A:

name ttl addr-class entry-type adress

Poszczególne pola mają wartości zdefiniowane podobnie jak dla BIND File Entries, z wyjątkiem pola:
adress
Tutaj umieszczany jest adres IP dla każdego komputera. Może być tylko jedna pozycja typu A dla każdego podanego adresu.

Przykład:
Wpis dwóch pól A:

; name 			ttl addr-class entry-type	adress  miami.cities.dec.com		IN	 A		128.11.22.44  				IN	 A		128.11.22.33  
Pole ttl zostało opuszczone, zatem przyjmowana jest wartość określona w SOA. Z powyższego przykładu wynika, iż komputer miami.cities.dec.com ma dwa adresy IP.

Canonical Name Entry

Wpis nazwy kanonicznej CNAME specyfikuje alias dla nazw kanonicznych. Przykładowo, nazwą kanoniczną (znana też jako pełna nazwa BIND'a) jest miami.cities.dec.com to dobrym aliasem mogłoby być miami lub mi.

Alias musi być unikalny, wszystkie inne wpisy muszą być powiązane z nazwami kanonicznymi, a nie z aliasami. Nie wolno tworzyć aliasów, których potem się używa w innych wpisach.
Format CNAME:

aliases ttl addr-class entry-type can-name

Poszczególne pola mają wartości zdefiniowane podobnie jak dla BIND File Entries, z wyjątkiem pól:
aliases
Pole, w którym umieszczane są aliasy nazw kanonicznych host'ów.
can-name
Tutaj umieszczana jest nazwa kanoniczna host'a. Jeżeli nazwa kanoniczna jest częścią bieżącej domeny, wystarcza podać nazwę komputera. Jeżeli nazwą kanoniczną jest komputer w innej domenie, musi zostać podana pełna nazwa BIND'owa zakończona kropką (.). Patrz przykład.

Przykład:
Wpis pola CNAME posiadającego dwie pozycje. Pierwsza z nich pochodzi z bieżącej domeny cities.dec.com, druga z innej:

; aliases ttl addr-class entry-type	can-name  to		 	IN	  	CNAME		toledo  oh		 	IN	  	CNAME		ohio.state.dec.com.  

Domain Name Pointer Entry

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 adress). Rodzaje adresowania omówione zostały w Rozdziałach: 2.2.4., 2.2.6. i 2.2.7. tego opracowania. Dla 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.

Host Information Entry

Wpis informacji na temat host'a (HINFO) pozwala na opisanie informacji o komputerze. Wpis składa się z różnych pozycji takich jak specyfikacja sprzętowa, system operacyjny. Należy pamiętać, że tylko jedna spacja oddziela opis hardware'u od systemu, więc jeżeli odstęp ma być częścią nazwy należy ująć ją w cudzysłów. W zapisie nie może być więcej niż jedna pozycja określająca każdy host w domenie.

Format HINFO:

host ttl addr-class entry-type hardware opsys

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

host
To pole specyfikuje nazwę host'a. Jeżeli host jest w bieżącej domenie, wystarczy podać tylko nazwę komputera. Jeżeli komputer znajduje się w innej domenie, należy podać pełną nazwę BIND'ową (tzn. zakończoną kropką (.). Np. utah.states.dec.com.
hardware
Tutaj umieszczana jest informacja o typie procesora.
opsys
Tutaj umieszczana jest nazwa systemu operacyjnego, pod którym pracuje dany komputer.Patrz przykład.
Przykład:
wpis pola HINFO posiadającego jedną pozycję.
; host		ttl addr-class entry-type hardware    opsys  alpha.twins.pk.edu.pl  IN	  HINFO   "DEC Alpha 3400" "Digital Unix v3.2"  

Well Known Services Entry

Dobrze znane usługi (WKS) to pole określające usługi prowadzone przez poszczególne protokoły na podanym adresie. Usługi i numery portów są dostarczane w liście usług wyspecyfikowanych w pliku /etc/services.

Format WKS:

name ttl addr-class entry-type address protocol services

W praktyce przestało się tego używać, ponieważ mało serwerów używa tego wpisu, ponieważ nie ma takiego obowiązku.
Poszczególne pola mają wartości zdefiniowane podobnie jak dla BIND File Entries, z wyjątkiem pól:
address
To pole specyfikuje adres IP dla każdego systemu. Dozwolone jest tylko jedno WKS dla każdego adresu IP.
hardware
Pole zawiera informację u stosowanym protokole, jaki będzie użyty dla usługi (np. UDP lub TCP)
Przykład:
Wpis pola HINFO posiadającego dwie pozycje.
; name ttl addr-class entry-type address 	protocol services  		 IN  HINFO	   128.32.0.4	UDP    who route  		 IN  HINFO	   128.32.0.78	TCP   (echo talk  						discard sftp  						netstat host  						time link pop  						finger domain auth)  
Usługi ujęte w nawiasy () są traktowane jako jedna usługa i mogą zajmować więcej niż jedną linijkę.

Mail Exchanger Entry

Pole to określa, który z komputerów w domenie lokalnej będzie pełnił funkcję gateway'a (tzn. komputera wiedzącego jak rozsyłać nadchodzącą pocztę do komputerów nie wpiętych bezpośrednio do sieci lokalnej i wysyłać ich pocztę poza obszar domeny).
Format MX:

system ttl addr-class entry-type pref-value gateway

Poszczególne pola mają wartości zdefiniowane podobnie jak dla BIND File Entries, z wyjątkiem pól:
system
Pole specyfikuje nazwę systemu, do którego poczta ma być wysłana.
pref-value
Pole, w którym zapisywana jest kolejność, według której mailer wybiera drogę wysłania poczty (jeżeli jest określonych kilka różnych).
gateway
Pole zawiera informację o nazwie gateway'a.
Przykład:
Wpis pola MX posiadającego dwie pozycje.
; system      ttl addr-class entry-type pref-value gateway  munari.oz.au.		IN	MX	0   	ceisimo.cs.au.  *.folks.dec.com.	IN	MX	0   	relay.cs.net.  
W pierwszej linijce host ceisimo.cs.au. jest gateway'em poczty dla munari.oz.au., natomiast w drugiej linijce zastosowano gwiazdkę jako wildcard, pozwalającą na to, by niezależnie od nazwy komputera w domenie .folks.dec.com cała poczta będzie przesyłana przez gateway relay.cs.net.

2.5. Queries (zapytania)

2.5.1. Definicje

Zapytania (queries) są wiadomościami wysyłanymi do name server'a, by wymusić na nim odpowiedź. W obrębie Internetu zapytania podróżują poprzez UDP (User Datagram Protocole) lub połączenia TCP. Odpowiedź otrzymana od name server'a może być rozwiązaniem problemu (pytania) postawionego w zapytaniu, odesłaniem do innych name server'ów w celu dalszych poszukiwań, lub też odpowiedzią sygnalizującą wystąpienie błędu.

Generalnie, użytkownik sam nie generuje zapytań, przekazuje je tylko w postaci żądań obsługi do resolver'a, który wysyła dopiero właściwie sformułowane zapytania do name server'a. W przypadku wystąpienia błędów, to również resolver zajmuje się ich obsługą.

Zapytania DNS, jak i odpowiedzi na nie udzielone przez name server'y, są przesyłane w postaci standardowego komunikatu (patrz Rozdział 2.7.). Komunikat posiada ustalony format zawierający nagłówek i pola zawierające informacje o zapytaniach, odpowiedziach itp.
Najważniejszym polem w nagłówku jest 4-bitowe pole opcode. Rozdziela ono różne rodzaje zapytań - z 16 możliwych wartości, jakie może przyjąć, jedna jest częścią oficjalnego protokołu (standard query), dwie są przeznaczone na opcje (inverse query i status query), zaś pozostałe są dowolne.

2.5.2. Rodzaje zapytań

Podstawowe dwa rodzaje zapytań stosowane podczas uzyskiwania informacji:


Absolutnie nie wolno stosować odwróconych zapytań do przypisywania adresów host'ów ich nazwom! Do tego celu służy specjalna domena .in-addr.arpa omówiona w Rozdziale 2.2.7.

W zależności od zaawansowania serwera, może on odpowiadać na dwa różne sposoby - nierekursywny i rekursywny.


Serwis rekursywny bywa pomocny w sytuacji, gdy:


2.5.3. Algorytm zapytań

Algorytm wykonywania zapytań może się różnić w zależności od rodzaju systemu operacyjnego czy też konkretnej implementacji serwisu DNS i oczywiście w zależności od struktury rekordów RR. Poniższy algorytm przyjmuje, że rekordy są zorganizowane w drzewa (po jednym dla każdej strefy i dodatkowo jedno dla cache'a).

krok 1.
Ustaw lub wyczyść wartość rekursji (w zależności od tego czy name server jest w stanie przeprowadzać zapytania rekursywne). Jeżeli taka usługa jest dostępna i jest zgłoszone takie żądanie (poprzez bit RD w zapytaniu idź do kroku 5.
W przeciwnym przypadku krok 2.

krok 2.
Przeszukuj wszystkie dostępne strefy w poszukiwaniu najbliższej do poprzednika QTYPE. Jeżeli znaleziono taką strefę, idź do kroku 3.
W przeciwnym razie krok 4.

krok 3.
Zacznij sprawdzanie dopasowania rekordów idąc w dół etykieta po etykiecie w obrębie strefy. Proces dopasowywania może się zakończyć na kilka sposobów:


a. jeżeli dopasowano całe QNAME, znaleziony został szukany węzeł. Jeżeli dane w węźle pasują do CNAME a QNAME nie pasuje do CNAME, skopiuj zawartość CNAME do sekcji odpowiedzi, zmień QNAME na nazwę kanoniczną w CNAME i przejdź do kroku 1.. W innym razie skopiuj wszystkie rekordy które pasują do QNAME do sekcji odpowiedzi i przejdź do kroku 6..

b. jeżeli dopasowywanie zabierze nas do danych miarodajnych, otrzymaliśmy połączenie. Skopiuj rekordy NS dla podstrefy do sekcji autoryzacji odpowiedzi.
Do sekcji dodatkowej wpisz wszystkie dostępne adresy.
Przejdź do kroku 4.

c. jeżeli na którymś poziomie dopasowanie nie jest możliwe (odpowiednia etykieta nie istnieje) zobacz czy da się określić etykietę "*" (pasujące wszystkie typy lub klasy dla pól QTYPE lub QCLASS). Jeżeli nie istnieje, sprawdź czy szukamy oryginalnej QNAME, czy też nazwy podanej w CNAME za którą podążyliśmy. Jeżeli nazwa jest oryginalna - wpisz w pole odpowiedzi "błąd miarodajnej nazwy" ("authoritative name error") i wyjdź.
W innym przypadku - wyjdź.
Jeżeli istnieje "*" sprawdź czy da się dopasować wszystkie rekordy w węźle z QTYPE. Jeżeli którykolwiek pasuje, skopiuj go do sekcji odpowiedzi, ale wpisz do wartości "właściciel" w rekordzie QNAME a nie węzeł z etykietą "*".
Idź do kroku 6.

krok 4.
Rozpocznij proces sprawdzania w dół cache'a. Jeżeli znaleziony zostanie QNAME, skopiuj wszystkie pasujące do QTYPE rekordy z nim powiązane do sekcji odpowiedzi. Jeżeli nie ma odniesienia do miarodajnych danych, poszukaj najlepszej autorytatywności w cache'u i wpisz ją do sekcji miarodajności.
Przejdź do kroku 6.

krok 5.
Korzystając z lokalnego resolver'a lub kopii jego algorytmu odpowiedz na zapytanie. Zachowaj wyniki (również pośredniczące CNAMES) i zapisz do sekcji odpowiedzi.

krok 6.
Korzystając wyłącznie z danych lokalnych spróbuj dodać inne rekordy RR, które mogą się przydać do sekcji dodatkowej zapytania.
Wyjdź.

2.5.4. Przykłady zapytań

Dla przykładu poniżej opisano procedurę postępowania jaką wykonują SLAVE SERVER i FORWARDER by odpowiedzieć na zapytanie. (resolve name server query).

krok 1.
SLAVE SERVER otrzymuje zapytanie o nazwę host'a, na które musi odpowiedzieć.

krok 2.
SLAVE SERVER wysyła pytania do wszystkich FORWARDER'ów, które zapisane są w boot file serwera, dopóki nie dostanie odpowiedzi lub lista FORWARDER'ów zostanie wyczerpana.

krok 3.
Jeżeli FORWARDER nie posiada żądanej informacji w lokalnym cach'upyta ROOT SERVER'y umieszczone w jego plikach konfiguracyjnych. Dzieje się tak aż do uzyskania odpowiedzi lub lista ROOT SERVER'ów zostanie wyczerpana.

krok 4.
ROOT SERVER podaje FORWARDER'owi informację z jakim serwerem w jakiej domenie ten musi się skontaktować dla odpytania o szukany host.

krok 5.
FORWARDER wysyła żądanie do serwera w tej domenie. Adres serwera otrzymuje od ROOT SERVER'a, którego właśnie przepytywał.

krok 6.
Serwer dostarcza informacji o serwerach na niższych piętrach w strukturze domeny i poddomen.

krok 7.
Kroki 5. i 6. są powtarzane dopóki FORWARDER nie otrzyma żądanej informacji lub możliwości uzyskania informacji od innych host'ów zostaną wyczerpane.

krok 8.
FORWARDER zwraca rezultat poszukiwań do SLAVE SERVER'a, nawet jeśli jest niepomyślny.


2.6. Resolvers

2.6.1. Wstęp

Resolver'ami są programy, które pośredniczą pomiędzy programami użytkownika a name server'ami. W najprostszym przypadku, resolver otrzymuje żądanie obsługi przez program użytkownika (np. program pocztowy, FTP lub TELNET) w postaci np. wywołania systemowego i zwraca żądaną odpowiedź w formie umożliwiającej odczytanie przez program (a zgodnej z formatem danych na hoście).

Resolver zwykle jest umieszczony na komputerze z którego pochodziło zgłoszenie obsługi, choć do udzielenia odpowiedzi może potrzebować zasięgnąć informacji u innych name server'ów na innych host'ach. Ponieważ może komunikować się z kilkoma name server'ami lub też tylko wyciągnąć informację z lokalnego cache'a, czas oczekiwania na odpowiedź może trwać od milisekund do kilku sekund.

Ważnym zadaniem resolver'a jest eliminowanie opóźnień w sieci i obciążeń name server'ów, poprzez odpowiadanie na podstawie danych zawartych w lokalnym cache'u. Cache jest wielodostępny przez różne procesy, komputery, użytkowników i bardziej efektywny od zwykłego jedno-dostępnego cache'a.

2.6.2. Funkcje

Sposób komunikowania się procesu-klienta z resolver'em zależy od konwencji lokalnych, ale musi spełniać trzy podstawowe funkcje:

  1. translacja nazwy komputera na jego adres
    Funkcja pochodzi jeszcze z czasów, kiedy wszystkie hosty były wpisywane do pliku HOSTS.TXT. Poprzez podanie ciągu znaków, wywołujący chce otrzymać w zamian jeden lub więcej 32-bitowych adresów IP. W DNS'ie takie żądanie jest interpretowane jako żądanie znalezienie właściwego rekordu RR typu A. Ponieważ DNS nie zachowuje porządku w rekordach, funkcja może posortować otrzymane adresy, lub wybrać "najlepszy", jeżeli wymagane jest zwrócenie jako wyniku operacji tylko jednego adresu klientowi. Chociaż podanie wielu adresów może być pożądane, to jednak jedynym sposobem na zachowanie kompatybilności z serwisem z czasów HOSTS.TXT jest podanie tylko tego "najlepszego".
  2. translacja adresu host'a na jego adres
    Bardzo często takie zgłoszenie podąża za pierwszym typem. Podając 32-bitowy adres IP chcemy uzyskać informację o nazwie komputera w postaci ciągu znaków. Oktety adresu IP są odwróconej kolejności i uzupełnione przyrostkiem ".in-addr.arpa". Do tego celu używa się zapytania typu PTR, by uzyskać odpowiedni rekord zawierający główną nazwę host'a. Przykładowo, zgłoszenie odszukania nazwy komputera o adresie IP 149.156.96.9 powoduje, iż szukany jest rekord PTR o wartości "9.96.156.149.in-addr.arpa".
  3. funkcja ogólnego lustrowania (general lookup)
    Pobiera informacje z DNS'u i nie ma odpowiednika w poprzednich funkcjach. Dostarczane są QNAME, QTYPE i QCLASS, a potrzebne są wszystkie pasujące rekordy RR. Ta funkcja często wykorzystuje format DNS do pobrania wszystkich rekordów, bez względu na przyjęte lokalnie konwencje.

Niezależnie od funkcji i wyniku przeszukiwania, resolver zawsze zwraca rezultaty klientowi przesyłając:


Może się zdarzyć, iż nazwa na którą natrafi resolver jest aliasem. Np. sytuacja, w której resolver po podaniu nazwy host'a i wykonaniu translacji na adres, otrzymuje alias znaleziony w rekordzie CNAME. Resolver powinien zwrócić alias klientowi jako wynik., jednak wwiększości przypadków ponawiane jest przeszukiwanie już dla aliasu. W przypadku gdy resolver wykonuje tylko funkcję lustrowania (lookup) nie pożądane jest by szedł śladem aliasu, jeżeli zapytanie zgadza się z rekordem CNAME. Pozwala to na sprawdzenie czy jakiś alias w ogóle się znajduje. Przykładem takiego zapytania typu CNAME może być sytuacja, w której użytkownika nie interesuje gdzie rekord CNAME wskazuje (w przypadku aliasu), ale sama jego zawartość.

Należy jednak zachować szczególną ostrożność przy konstruowaniu aliasów. Wielostopniowe aliasy są nieefektywne i powinno się ich unikać, choć z drugiej strony resolver nie powinien ich sygnalizować jako błędu. Natomiast zapętlone aliasy (alias loops) lub aliasy wskazujące do nieistniejących nazw powinny sygnalizować klientowi błąd.

W przypadku, gdy resolver nie jest w stanie wykonać resolving'u, nie powinien być sygnalizowany błąd nazwy lub błąd danych programowi, który zlecił wykonanie jednej z funkcji. Może być wiele przyczyn powodujących chwilowe niemożności poprawnego spełnienia żądania obsługi. Resolver może zostać odseparowany od reszty sieci z powodu np. utraty połączenia, problemów z gateway'em lub nawet przez przypadkowy błąd lub nieosiągalność wszystkich serwerów w domenie.

Zalecanym rozwiązaniem w takich sytuacjach jest zaimplementowanie błędu tymczasowego jako jednej z funkcji. Nie jest zalecane rozwiązanie, w którym żądanie obsługi jest blokowane - a co za tym idzie, blokowany jest program użytkownika.

2.6.3. Zasoby i typy resolverów

Każda implementacja resolver'a niewiele różni się od pozostałych algorytmami. Główne różnice polegają na obsłudze błędów.

Jednym ze stosowanych rozwiązań jest użycie tzw. stub resolver'a. Polega to na przeniesieniu funkcji rozwiązywania poza maszynę lokalną do name server'a, który jest w stanie przeprowadzać zapytania rekursywne (recursive queries). Taka metoda dobrze się sprawdza w przypadku, gdy chcemy prowadzić serwis DNS na komputerze klasy PC, któremu zwykle brak jest zasobów na dokonywanie rekursywnych zapytań lub też w przypadku centralizacji cache'a dla całej sieci lokalnej.
Jedyne czego stub resolver potrzebuje. to lista serwerów przeprowadzających rekursywne zapytania. Oczywiście dane muszą być zapisane w plikach konfiguracyjnych, gdyż z powodu nieskomplikowanej budowy nie byłby w stanie znaleźć sam bazy danych w sieci lokalnej.
Jednak rozwiązania oparte na stub resolver'ach nie są zalecane z powodu dużej zawodności w przypadku większego obciążenia sieci.
Poza swoimi zasobami, resolver może również korzystać z informacji zawartych w strefach zarządzanych przez lokalny name server. Zwiększa się szybkość dostępu do danych, ale należy być ostrożnym ,by nie spowodować przepisania danych z cache'a jako wyniku (jeżeli wykorzystane będą dane ze stref lokalnych).

Podany algorytm resolving'u opiera się na domyślnym przyjęciu, że wszystkie funkcje zostały skonwertowane do ogólnego lustrowania (general lookup) i używane są podane niżej struktury, niezbędne do reprezentowania postępu w rozwiązywaniu zapytania.

SNAME
nazwa domeny, której szukamy
STYPE
typ rekordu QTYPE podanego żądania przeszukiwania
SCLASS
typ rekordu QCLASS
SLIST
struktura określająca jakie strefy i name server'y obecnie odpytuje resolver. Pozwala na kontrolowanie historii przebiegu poszukiwania.
SBELT
Struktura bezpieczeństwa, podobna do SLIST.
CACHES
truktura zapamiętująca wyniki odpowiedzi na poprzednie zapytania.

2.6.4. Algorytm resolving'u

Algorytm składa się z czterech kroków.

krok 1.
Sprawdź czy odpowiedź jest zawarta lokalnie - jeżeli tak, zwróć rezultat klientowi.
Jeżeli nie krok 2.

krok 2.
Znajdź "najlepszy" serwery, które można zapytać. Dalej krok 3.

krok 3.
Wysyłaj zapytania do tych serwerów, aż do otrzymania odpowiedzi. Teraz krok 4.

krok 4.
Przeanalizuj odpowiedź. W zależności od rezultatu:

a. jeżeli odpowiedź zawiera informację, o którą nam chodziło, lub błąd nazwy wstaw dane do cache'a i zwróć wynik klientowi
jeżeli odpowiedź zawiera odnośnik do innych serwerów, załaduj odnośniki do cache'a i przejdź do kroku 2.

b. jeżeli odpowiedź zawiera odnośnik do innych serwerów, załaduj odnośniki do cache’a i przejdź do kroku 2.

c. jeżeli odpowiedzią okazuje się być CNAME, a nie o to chodziło, wpisz CNAME do cache'a, zmień SNAME na nazwę kanoniczną z rekordu CNAME i przejdź do kroku 1.

d. jeżeli odpowiedź pokazuje błąd serwera, lub dzieją się inne dziwne rzeczy, wykasuj serwer z SLIST i wróć do kroku 3.

Krok 1. poszukuje danych w cache'u lokalnym. Jeżeli się tam znajduje, przyjmuje się, iż jest odpowiednia do normalnego użytku. Niektóre implementacje resolver'ów mają opcję pozwalającą na wymuszenie zignorowania danych z cache'a i skontaktowania się z miarodajnym serwerem. Nie jest to rekomendowane jako opcja domyślna. Jeżeli resolver ma bezpośredni dostęp do stref name server'a, powinien je sprawdzić, czy nie ma w nich autoryzowanej odpowiedzi i użyć jej zamiast danych z cache'a.

Krok 2. wyszukuje name server'ów, których można by zapytać o interesujące nas dane. Generalnie, najpierw sprawdzane są lokalnie dostępne name server'y i zawartości rekordów począwszy od SNAME, później domena wyżej, aż do korzenia. Teraz należy skopiować nazwy do SLIST. Odnaleźć ich adresy korzystając z danych lokalnych. Może się okazać, iż jakaś nazwa nie ma adresu. Resolver może rozpocząć równoległe przeszukiwanie wszystkich dostępnych adresów.

Krok 3. wysyła zapytania, dopóki nie otrzyma odpowiedzi. Najlepszą strategią jest cykliczne poszukiwanie spomiędzy adresów wszystkich serwerów, z przyjęciem ograniczenia czasowego na każdą z transmisji. SLIST zwykle zawiera typy danych pozwalające na ustawienie takiego ograniczenia (timeout) a nawet na prowadzenie zapisu poprzednich transmisji.

Krok 4. polega na analizie nadchodzących odpowiedzi. Wymagane jest zachowanie szczególnej podejrzliwości przez resolver'a. Powinien sprawdzać czy odpowiedź zgadza się z zapytaniem, używając do tego celu pola ID w odpowiedzi. Jeżeli w odpowiedzi napłynie odniesienie, należy sprawdzić czy jest "bliżej" odpowiedzi niż serwery z SLIST. Można to osiągnąć poprzez porównywanie licznika w SLIST z liczonym w SNAME i w rekordach NS w odniesieniu. Jeżeli jest "dalej" - informacja jest ignorowana jako niepotrzebna.
Idealną odpowiedzią na zapytanie jest odpowiedź autorytatywnego serwera, podająca informację, o którą nam chodziło, bądź błąd nazwy. Odpowiedź jest przesyłana klientowi i zapamiętywana w cache'u (jeżeli wartość pola TTL jest różna od zera).

2.7. Komunikaty (Messages)

2.7.1. Wstęp

Wszystkie informacje krążące wewnątrz protokołu domeny przenoszone są za pomocą osobnego formatu zwanego komunikatem lub wiadomością (message). Format podano poniżej.

2.7.2. Format

Górna część nagłówka wiadomości jest podzielona na pięć sekcji, z których niektóre mogą być puste (w pewnych okolicznościach).

Oto sekcje:

HEADER
(nagłówek). Jest zawsze obecny, posiada również specjalne pole określające, które z pozostałych sekcji są obecne w wiadomości, jak również pole określające czy wiadomość jest zapytaniem, odpowiedzią, standardowym zapytaniem czy też innym typem określonym przez opcode.
QUESTION
pola zawierające opis zapytań do name server'a. Pola mogą być typem query type (QTYPE), lub query class (QNAME), bądź też zapytaniem o nazwę domeny (QNAME).
ANSWER
zawiera RRs odpowiadające na pytania. Ta sekcja, jak i następne mają format listy (może być pusta) połączonych rekordów RR..
AUTHORITY
sekcja zawiera rekordy RR wskazujące na to, gdzie znajduje się miarodajny (authoritative) name server.
ADDITIONAL
tu znajdują się rekordy, które związane są z zapytaniem, lecz nie tak całkiem dokładnie z odpowiedzią na nie.

 

Powrót do strony głównej