2

Jak działa DNS

Poniższy rozdział opisuje zasady działania i współpracy serwerów DNS oraz ich reakcje na zapytania o nazwy.

§         Hierarchia hostów i domen – ten podrozdział przedstawia drzewiastą strukturę przestrzeni nazw (hierarchię nazw komputerów związanych z organizacjami). Wyjaśnia podział przestrzeni nazw za pomocą poddomen na jednostki łatwe do zarządzania i sposób w jaki delegacje kierują odpytywaniem w razie potrzeby innych serwerów przez serwer DNS.

§         Domeny i strefy – relacje pomiędzy domeną a serwerem DNS mogą być różne, nie zawsze jednej domenie odpowiada jeden serwer. Serwery DNS korzystają z plików strefy które określają precyzyjnie, które domeny i które hosty są zarządzane. Dzięki strefom administratorzy DNS-u mogą elastycznie przydzielać serwerowi DNS jedną lub więcej domen, części jednej lub kilku domen, albo kombinacje powyższych. Podrozdział ten przedstawia dane strefy, najważniejsze w administrowaniu DNS-em. Uwaga: Niektóre serwery nie korzystają z plików strefy do przechowania informacji o strefie, serwery wtórne mogą po prostu przechowywać kopię roboczą w pamięci a serwery w systemie Windows mogą przechowywać dane strefy w Active Directory.

§         Rozwiązywanie zapytań klientów – co dzieje się gdy klient przysyła zapytanie o nazwę? Podrozdział ten opisuje szczegółowo proces rozwiązywania zapytania klienta, korzystając z przykładowego zapytania.
Wyjaśniono tu również rekursywny i iteracyjny tryb zapytania których mogą użyć serwery DNS. Przykład przedstawia zapytanie wędrujące w górę drzewa nazw DNS aż do węzła głównego i z powrotem do innej gałęzi aby spełnić żądanie klienta.

§         Przegląd narzędzi – ten podrozdział opisuje podstawowe narzędzia które pomagają radzić sobie z DNS-em w zakresie gromadzenia informacji, rozwiązywania problemów itp. Przedstawiono tutaj niewielki zestaw podstawowych narzędzi pozwalających na pracę z DNS-em i jego zrozumienie.

DNS jest praktyczną składnicą i „izbą rozrachunkową” sieciowych nazw hostów i domen, w której każda nazwa hosta traktowana jest jak adres symboliczny — ponieważ nazwy są wygodniejsze w użyciu i łatwiejsze do zapamiętania od liczb.

Funkcje klienta DNS są najlepiej widoczne w sieciowej warstwie aplikacji, w której adres internetowy (URL: Uniform Resource Locator) wpisany do przeglądarki prowadzi do witryny WWW w dowolnym miejscu na świecie. Niższa warstwa, transportowa, służy do przesyłania informacji przez sieć. Serwery i klienci DNS do zapytań używają bezpołączeniowego protokołu UDP (User Datagram Protocol) na porcie 53 a do połączeń między serwerami protokołu TCP (Trasmission Control Protocol) na porcie 53. Powód, dla którego DNS używa bezpołączeniowego protokołu UDP, jest prosty. Ruch informacji przesyłanych poprzez UDP nie wymaga odpowiedzi; jeżeli urządzenie nadające nie otrzyma niezbędnych informacji, program analizujący powtarza transmisję aż do uzyskania odpowiedzi (co zostało opisane w podrozdziale „Rozwiązywanie zapytań klientów” w dalszej części rozdziału). W przypadku komunikacji pomiędzy serwerami, korzystać można jedynie z protokołu połączeniowego, jak na przykład TCP, ponieważ serwery przesyłają ważne rekordy zasobów (RR) i informacje [seryjne] które replikowane są jedynie co jakiś czas. Bez tych informacji serwery nie są zsynchronizowane i nie mogą dostarczać wiarygodnych usług.

Hierarchia hostów i domen

W czasach gdy Internet (zwany pierwotnie ARPAnet) był niewielki, w sieci rozsyłany był pojedynczy, zwarty plik hosts.txt służący do łączenia hostów. W miarę rozbudowy Internetu model dystrybucji wspomnianego pliku przestał wystarczać. Aby zastąpić przestarzałą, opartą o pliki metodę łączenia hostów, opracowano architekturę DNS, z modelem rozproszonych przypominającym drzewo systemu plików, jak na rysunku 2.1. Z punktu widzenia architektury, DNS jest systemem rozproszonego, hierarchicznego zarządzania bazą danych w układzie klient – serwer.

Model typu drzewa jest rozproszony, ponieważ każda zarejestrowana domena posiada własny listing bazy danych dodawany do ogólnej architektury, co przedstawia rysunek 2.2.

Na szczycie hierarchii znajduje się węzeł główny drzewa domen (root), zazwyczaj przedstawiany w formie kropki (.) i składający się z serwerów nazw poziomu głównego. Na serwerach tych umieszczone są wskaźniki początkowe prowadzące w dół do domen pierwszego poziomu, zwanych inaczej domenami najwyższego poziomu (TLD od Top Level Domain), takich jak .com, .org, .mil czy .edu. Dodatkowo, istnieje ponad 200 geograficznych domen TLD a ich lista wciąż rośnie. Z początku, domeny najwyższego poziomu były zarządzane przez

Rys. 2.1 Drzewo DNS, podobnie jak drzewo systemu plików, wymaga na każdym poziomie stosowania jednoznacznych nazw.

Rys. 2.2 Hierarchia drzewa nazw DNS zaczyna się od domeny głównej.

organizację IANA (Internet Authorized Numbers Authority). Zarządzanie niektórymi domenami najwyższego poziomu zostało jednakże oddelegowane do innych organizacji, jak np. Internet Network Information Center (InterNIC). InterNIC zarządza, pomiędzy innymi, domenami .com, .org, .net i .edu. Jest to przestrzeń ewoluująca z powodu wielkiej liczby rejestracji w latach 80-tych i 90-tych i z pewnością ulegnie zmianom. Autorzy postarali się przedstawić szeroki zakres domen TLD w dodatku C, „Internetowe domeny najwyższego poziomu”.

Hosty w hierarchii nazw domen mogą być umieszczone na dowolnym poziomie poniżej głównego. Ponieważ drzewo nazw jest hierarchiczne a nie płaskie, nazwy hostów muszą być jednoznaczne jedynie w obrębie każdej małej gałęzi drzewa domen. Na przykład, www może stanowić nazwę kilku serwerów WWW dla jednego przedsiębiorstwa, gdy każda maszyna znajduje się w oddzielnej gałęzi hierarchii domen. Na przykład, www.xyz.com, www.corp.xyz.com i www.eng.xyz.com są poprawnymi nazwami hostów rozwiązywanymi na różne, unikalne adresy, chociaż wszystkie hosty mają takie same nazwy. Ta podstawowa zasada pozwala również na ujednoliconą konwencję nazewnictwa w domenach dla serwerów FTP, WWW, serwerów nazw i tak dalej.

Serwery nazw poziomu głównego są bardzo podobne do tych używanych przez korporacje i instytucje edukacyjne na całym świecie, lecz rozmieszczone w najbardziej uprzywilejowanych miejscach w Internecie — to znaczy, nawet ponad domenami najwyższego poziomu, jak .com i .org. Tabela 2.1 przedstawia najważniejsze pierwsze poziomy w hierarchii nazw domen.

Aby łatwo zapamiętać poziomy DNS-u wystarczy przypomnieć że domena poziomu głównego ma w nazwie tylko kropkę (.). Domeny najwyższego poziomu (TLD) mają jedną nazwę a domeny drugiego poziomu (SLD) dwie.

Kluczową różnicą między serwerami nazw poziomu głównego a serwerami organizacji jest fakt iż te pierwsze zawierają wskaźniki do wszystkich zarejestrowanych domen drugiego poziomu, jak np. example.net czy college.edu.

Domeny SLD dzielą się na geograficzne i organizacyjne według ostatniego członu nazwy, inaczej przyrostka. Na przykład, microsoft.com jest własnością Microsoft Corporation. Większość przyrostków domen podpowiada jakiego typu organizacja jest jej właścicielem.

Tab. 2.1 Hierarchia nazw domen

Uwaga

Domeny najwyższego poziomu (TLD) w porównaniu z poziomem głównym znajdują się na poziomie drugim lecz zwyczajowo nazywane są domenami pierwszego poziomu. O domenie głównej często nie myśli się jako o domenie, chociaż jest nią w każdym sensie technicznym. Maszyny członkowskie domeny głównej — stosunkowo nieliczne — istnieją jedynie dla utrzymania drzewa nazw i jego funkcji.

Jednakże nie zawsze tak łatwo jest określić rodzaj organizacji patrząc na przyrostek. Na przykład, domeny .net i .org nie są tak jasno zdefiniowane jak komercyjna, .com. Chociaż domena .net w zamysłach przeznaczona była dla dostawców usług internetowych (ISP) i innych organizacji sieciowych, przyrostek .net przyznano również szeregowi projektów badawczych, jak handle.net czy giga.net.

Planowanym zastosowaniem domeny .org były badawcze organizacje niekomercyjne i sponsorowane przez państwo; lecz oprócz tego korzystają z niej organizacje rządowe takie, jak High Performance Computing Center (hpc.org) czy  Intergration Technology Office (ito.org)

Poddomeny

Domena poniżej jakiejkolwiek innej jest poddomeną, tak że nawet domeny najwyższego poziomu są poddomenami głównej. Jednakże różnorodność poddomen poniżej drugiego poziomu jest ogromna. Ponieważ tam właśnie rezyduje większość poddomen, określenie „poddomena” najczęściej odnosi się do położonych gdziekolwiek poniżej poziomu drugiego.

Organizacje tworzą poddomeny z własnych wewnętrznych motywacji. East.isi.edu jest poddomeną isi.edu używaną przez położony na wschodnim wybrzeżu USA oddział Information Sciences Institute (ISI). Korporacje tworzą czasami poddomeny odpowiadające swojej wewnętrznej strukturze. Przedstawione jest to na rys. 2.3 w podrozdziale „Domeny i strefy”, na którym poszczególne poddomeny odpowiadają działom: [Sprzedaży, Badań, Marketingu i Kadrom]. Tego typu podziały domen pozwalają na poprawę wydajności serwerów pocztowych, serwerów nazw i innych usług przez rozłożenie obciążenia na kilka komputerów w wewnętrznej sieci przedsiębiorstwa. Wybór struktury poddomen jest całkowicie dowolny i zależy od właściciela domeny. Celem powinno być zminimalizowanie całkowitego ruchu w sieci przy jednoczesnej obsłudze wszystkich zapytań. Windows 2000 nierzadko korzysta ze struktur podobnych do rozmieszczenia kontrolerów domen, z podobnych przyczyn. Rozmiary domen warto ograniczać do obrębu sieci lokalnej (LAN) aby zredukować do minimum ruch danych w sieci rozległej (WAN); zaleca się umieszczenie przynajmniej serwera buforującego DNS w każdej sieci lokalnej.

Domeny czy poddomeny?

Purysta logiczny mógłby nazywać wszystkie domeny poniżej głównej poddomenami ze względu na ich podległość. Takie użycie wyrażenia jest jednak zbyt szerokie i nie odróżnia w sposób wystarczający wyższych poziomów. Administratorzy określają zazwyczaj poddomenami wszystkie domeny poniżej drugiego poziomu — to znaczy, posiadające trzy lub więcej nazw oddzielonych kropkami. Odróżnia to bardziej trwałe TLD od domen na trzecim, czwartym i niższych poziomach.

W praktyce, domenami nazywamy mocno utwierdzone domeny na poziomach głównym, najwyższym i drugim, zaś poddomenami — poniżej poziomu drugiego.

Delegowanie

Dochodzimy tu do celu delegowania — formalnej metody rozkładu obciążenia pomiędzy serwery w domenie, jak np. pomiędzy domenę rodzicielską a jej poddomeny potomne. Serwer podstawowy (lub większa ich grupa) określany jest początkiem pełnomocnictwa (SOA, Start of Authority dla domeny DNS-u). Serwer podstawowy ma niekwestionowane prawo odpowiadać na wszystkie pytania w obrębie domeny lub delegować część pełnomocnictw na inne serwery.

Każda domena TLD jest w rzeczywistości małą częścią domeny głównej, zaś TLD dalej dzielone są na domeny drugiego poziomu, SLD. Delegowanie stanowi metodę, za pomocą której serwery domeny głównej dzielą się odpowiedzialnością z innymi serwerami nazw. W wyniku otrzymujemy rozdział pełnomocnictw dla wszystkich nazw hostów zarejestrowanych w Internecie. Dzięki podziałowi temu realizowana jest kluczowa idea DNS-u. Żaden pojedynczy serwer nie może być źródłem awarii systemu. Serwery domeny głównej są zwielokrotnione, podobnie jak większość— jeśli nie wszystkie — serwery TLD i podobnie jak powinno być w domenie czytelnika tej książki.

Jeżeli pojedynczy serwer DNS nie jest w stanie odpowiedzieć na pytanie, może automatycznie skierować klienta do następnego serwera który został oddelegowany przez zaangażowaną domenę. Poddomeny często obsługiwane są przez oddelegowane serwery. Delegacje określają  które serwery mają pełnomocnictwo do nazw, wobec czego ustalają w razie konieczności kolejność odpytywania serwerów. Jeżeli serwer z pełnomocnictwem w zakresie domeny nie może dać odpowiedzi na zapytanie, oznacza to że host o szukanej nazwie nie istnieje w tej domenie lub znajduje się w innej. W drugim przypadku niezbędny jest wskaźnik kierujący zapytanie dalej (na przykład na następny poziom drzewa). Delegacje informują o serwerach nazw upełnomocnionych w  domenie; jednakże w rzeczywistości w większości zapytań klient potrzebuje skorzystać tylko z jednego serwera nazw. Klient (resolwer) otrzymujący autorytatywną odpowiedź twierdzącą iż host lub domena nie istnieje zazwyczaj natychmiast kończy poszukiwania. Resolwer nie podąża dalej śladem delegacji i nie jest istotne z iloma serwerami nazw ze swojej listy komunikował się uprzednio.

Delegacje zazwyczaj wskazują w dół od serwerów poziomu głównego, będących zwieńczeniem struktury DNS, do serwerów poziomu najwyższego. Serwery DNS poddomen rejestrowane są w serwerach domen rodzicielskich za pomocą rekordów serwerów nazw, NS (Name Server). Organizacje rejestrują domeny poziomu drugiego i ich serwery DNS w InterNIC do oddelegowania z  serwerów TLD. Jak wspomniano wcześniej, poniżej SLD może istnieć większa ilość delegacji.

Delegacje wskazują zwykle zarówno w dół jak na boki. Delegacje w bok identyfikują inne serwery nazw na tym samym poziomie, dzielące się pełnomocnictwami w domenie na pojedynczym poziomie, zaś delegacje w dół identyfikują poddomeny (patrz dodatek C). Każdy publiczny serwer DNS w organizacji może być oddelegowany przez serwer poziomu najwyższego jako jedna z jego poddomen.

Delegowanie serwerów nazw odbywa się za pomocą rekordów NS (Rozdział 4 „Szczegóły informacji o domenach”, opisuje rekordy NS i sposób ich użycia). Rekordy NS określają listę serwerów upełnomocnionych w domenie. Na przykład, aby stworzyć poddomeny dla organizacji, należy dokonać oddelegowania z domeny rodzicielskiej do poddomen. Jeżeli nie zostanie to wykonane, nazwy w poddomenie nie będą widziane przez hosty z zewnątrz.

Z perspektywy klienta-resolwera DNS-u wszystkie zarejestrowane adresy hostów są lokalne dla swojego serwera DNS. Jest to jednak tylko wrażenie. Delegacje mówią lokalnemu serwerowi DNS jak znajdować hosty na zewnątrz, dzięki czemu jego klienci mogą rozróżniać nazwy poza własną domeną.

Domeny i strefy

Zrozumienie różnicy pomiędzy strefami i domenami może wymagać pewnego wysiłku umysłowego. W drzewie nazw domen DNS-u istnieją gałęzie dla nazw domen i liście dla nazw hostów. W drzewie tym poddomeny i hosty są członkami wszystkich domen znajdujących się powyżej.

Strefy pokrywają logicznie części struktury drzewa DNS-u aby określić które nazwy obsługiwane są przez każdy z serwerów DNS. Strefa serwera DNS określa gałęzie drzewa nazw obsługiwane przezeń, jego zasięg i dla jakich domen (w liczbie mnogiej!) serwer ten posiada pełnomocnictwa.

Na rysunku 2.3 pojedynczy serwer obejmuje pełnomocnictwami dwie domeny – mkt i sales. Strefa w DNS może również obejmować pojedynczą domenę — jak na przykład eng na rys. 2.3, mimo iż tutaj pojedyncza domena zawiera dwie poddomeny. Ponieważ w Windows 2000 strefy służą do przechowywania ciągłych gałęzi, co wymagałoby rozdzielenia mkt i sales na oddzielne strefy, ogólne zasady tworzenia stref mogą się nieco różnić.

Współdziałanie serwerów i klientów DNS wymaga stosowania stref i delegacji, ponieważ strefy określają miejsce (serwer) w którym nazwy są przechowywane oraz drogi którymi klienci i serwery komunikują się z innymi serwerami DNS.

Strefa może zawierać rekordy dla pojedynczej domeny, jej części, jednej lub więcej poddomen lub kombinacji domen rodzicielskich i potomnych. Przechowywanie rekordów dla wielu domen jest szczególnie typowe dla specjalnej klasy stref adresów odwrotnych, które służą do rozwiązywania adresów IP na nazwy. Strefy adresów odwrotnych opisane są w rozdziale 4, w podrozdziale „Rekordy wskaźników i wyszukiwanie w tył”.

Rys. 2.3 Strefy decydują o zarządzaniu domenami przez serwery DNS.

Strefy przydzielają serwerom DNS — można tak powiedzieć — porcje nazw do zarządzania, a delegacje wskazują gdzie szukać odpowiedzi na zapytanie poza własną strefę. Ani strefy, ani delegacje nie określają, który serwer DNS jest upełnomocnionym pierwotnym źródłem rekordów w domenie, a które serwery pełnia rolę zapasowych. Przydzielenie serwerowi początku pełnomocnictwa (SOA) nadaje te uprawnienia, zaś nadanie statusu serwera wtórnego (NS) czyni z niego serwer zapasowy dla podstawowego.

Podstawowe serwery DNS

Jak stwierdzono wcześniej, serwer podstawowy DNS (SOA) jest autorytatywny dla nazw w swojej domenie i z niego pochodzą informacje o wszystkich nazwach w obrębie domeny. Podczas startu serwer podstawowy otrzymuje dane strefy z lokalnego pliku (lub z Active Directory) znajdującego się na komputerze na którym jest uruchomiony. Serwer DNS może być podstawowym równocześnie dla więcej niż jednej domeny, a zarazem może pełnić funkcję podstawowego dla jednej domeny i wtórnego dla innej. Typy serwerów DNS opisano dokładniej w rozdziale 3.  Jednakże należy koniecznie zdać sobie sprawę, iż nie istnieją podstawowe domeny czy strefy. Jedynie serwer DNS może być podstawowy i jest to określenie serwera będącego autorytatywnym źródłem nazw w domenie.

Jeśli planuje się stworzenie hierarchii domen w organizacji, najrozsądniej jest rozpocząć od skonfigurowania podstawowego serwera nazw dla całej domeny. Strefa którą serwer ten zarządza powinna zawierać wszystkie wymagane nazwy domen. Jeśli serwer nie zawiera wszystkich rekordów w domenie, należy oddelegować pełnomocnictwa do poddomen (np. example.net podzielona na sales.example.net, ops.example.net, eng.example.net itd.).

Decyzja o wykorzystaniu poddomen zwiększa elastyczność. Jednocześnie wzrasta potencjalnie wymagany wkład pracy, ponieważ każda poddomena może posiadać start pełnomocnictwa; wobec czego każda zmiana musi być dokonana na przydzielonym serwerze podstawowym. Microsoft używa pojęcia strefy w sposób który może być konfundujący. Czytelnik wdrażający DNS musi z uwagą podchodzić do słownictwa i jego wykorzystania.

Serwery wtórne DNS

Serwery wtórne pobierają dane z serwera podstawowego. Podczas uruchomienia serwer wtórny w pierwszej kolejności kontaktuje się z serwerem z którego otrzymuje dane strefy, a następnie porównuje ich wersję z wersją serwera podstawowego. W razie potrzeby, serwer wtórny dokonuje przesłania informacji o strefie, pobierając je z serwera podstawowego. Serwer wtórny zna swój podstawowy ponieważ jego nazwa znajduje się w rekordach SOA i NS. Serwery wtórne reprezentowane są jedynie przez rekord NS i nie ponoszą odpowiedzialności za początek pełnomocnictwa, ponieważ jest to wyłącznie cecha serwera podstawowego. Oczywiście jeżeli serwer wtórny nie posiada jeszcze danych strefy, musi wykorzystać wskazania z pliku inicjacyjnego aby znaleźć serwer nadrzędny i s niego pobrać dane.

Podobnie jak serwery podstawowe DNS, wtórne są autorytatywnym źródłem nazw w domenie. Różnica polega na tym, iż serwery podstawowe są źródłem nazw dla innych serwerów DNS chcących zaimportować pliki strefy; podczas gdy wtórne nie są źródłem autorytatywnych danych. Służą jako zapas i wsparcie.

Przesyłanie danych z serwerów podstawowych DNS do wtórnych

Dysponując podstawową wiedzą o domenach, strefach i delegacjach możemy przejść do opisu modelu rozproszonej bazy danych na którym opiera się DNS. Pliki strefy są zasadniczo tabelami bazy danych nazw DNS a serwer podstawowy dysponuje plikiem (plikami) źródłowymi strefy dla swojej domeny (domen).

Należy pamiętać iż serwery nazw w poddomenach mogą pełnić role podstawowych, wydajnie dzieląc dużą listę nazw w domenie na mniejsze porcje w oddzielnych plikach stref. Jeśli duża organizacja tworzy serwery nazw w pojedynczej domenie bez poddomen, pliki stref również przybierają duże rozmiary. Duże płaskie przestrzenie nazw powodują dodatkowy problem: w nie podzielonej gałęzi DNS nie mogą znajdować się dwa hosty o identycznych nazwach. Poprzez zaniechanie podziału domen duże organizacje mogą szybko dojść do podobnych problemów z jakimi borykał się ARPAnet, gdy podjął decyzję o utworzeniu architektury DNS. Jednakże ta sama duża organizacja może podzielić przestrzeń nazw na poddomeny wciąż używając jednego pliku strefy, jak na rys. 2.3, co pozwoli uporać się z jednym z dwu wspomnianych problemów.

Podział domeny może również poprawić wydajność przez utrzymywanie plików strefy o mniejszych rozmiarach i łatwiejszych do zarządzania. Serwer nazw nie powinien musieć analizować gigantycznego pliku strefy. Chociaż inne czynniki również maja swój wpływ, w zasadzie im mniejszy plik strefy tym szybsza odpowiedź serwera nazw. Jednakże podział na poddomeny tworzy pewien problem praktyczny. Delegacje rozwiązują jego część przez koordynację stosunków między domenami rodzicielskimi i potomnymi. W jaki sposób wtórny serwer nazw otrzymuje dane z oryginalnego źródła — swojego serwera nadrzędnego? Odpowiedzią jest przesyłanie pliku strefy tego serwera, zwane inaczej przesyłem strefy (zone transfer). Przesył strefy może być częściowy lub pełny, w zależności od potrzeb i czasu który upłynął od ostatniego pełnego przesyłu. Podział dużych plików strefy na mniejsze poprawia również przesyły stref. W sumie jest to całkiem sporo argumentów za unikaniem dużych, płaskich przestrzeni nazw.

Podstawowy serwer nazw po uruchomieniu od razu może rozpocząć odpowiadać na zapytania usługi nazewniczej. Serwer wtórny po uruchomieniu otrzymuje polecenie odwołania się do serwera nadrzędnego (często jest nim serwer podstawowy) po autorytatywne dane; następnie ścieżkę dostępu i nazwę pliku w którym ma zapisać lokalną kopię danych po ich otrzymaniu. Służą do tego informacje inicjacyjne serwera, co zostało opisane w rozdziale 4. Jeżeli wtórny serwer nazw uruchamiany jest po raz pierwszy lub ktoś wyczyścił jego katalog danych, wysyła do serwera nadrzędnego żądanie kopii pliku strefy.

Przesył strefy wygląda podobnie jak replikacja plików w Windows (NT lub 2000) albo replikacja danych między partnerami w usłudze WINS. Jeśli serwer wtórny posiada kopię pliku strefy serwera podstawowego, może również rozpocząć dostarczać autorytatywnych odpowiedzi na zapytania o nazwy. Co dzieje się w przypadku modyfikacji lub uaktualnienia pliku strefy na serwerze podstawowym? W skład rekordu SOA wchodzą pola informacyjne decydujące o częstotliwości z jaką serwery wtórne powinny sprawdzać możliwe zmiany na serwerze podstawowym.

Pola te ustawiają termin ważności, czasy oczekiwania i częstotliwość odświeżania. Rekord SOA posiada również numer seryjny (wersji). Dalsze informacje o rekordzie SOA znajdują się w rozdziale 4.

Serwer wtórny okresowo wysyła zapytania do podstawowego sprawdzając czy pliki stref wymagają odświeżenia, na podstawie ewentualnych zmian numeru seryjnego (wskaźnika przyrostu numeru wersji bazy danych). Jeśli numer uległ zmianie, serwer wtórny wiedząc iż dane strefy zostały zmienione inicjalizuje przesył (częściowy albo zupełny) wymaganych informacji. Przesyły częściowe są zdefiniowanymi w RFC 1995 przesyłami typu przyrostowego, w których przesyłane są jedynie zmiany a nie całe strefy.

Serwer wtórny dokonuje przesyłu strefy jedynie jeżeli numer seryjny został zwiększony. Jeżeli z jakiegokolwiek powodu numer ten został zmniejszony, serwer wtórny przyjmuje iż jego kopia strefy jest nowsza i używa jej dalej aż do zakończenia terminu ważności. Jeżeli z jakiegoś powodu numer seryjny musi przejść do zera, lokalny plik strefy w serwerze wtórnym jest kasowany i serwer ten inicjalizuje przesył całkowicie świeżego pliku strefy z serwera nadrzędnego. Serwer wtórny może pobrać dane strefy z podstawowego lub innego wtórnego, lecz w obu przypadkach mówi się o pobraniu danych z serwera nadrzędnego.

Zarówno serwer DNS w Windows 2000 jak BIND w wersji 8. posiadają możliwość powiadamiania powodującego uaktualnienie. Opcja powiadomienia wyspecyfikowana została w RFC 1996. Oznacza to iż serwer nadrzędny może w istocie powiadomić serwery wtórne o zmianach aby przyspieszyć propagację nowych informacji. Opcja powiadomienia zwiększa bezpieczeństwo, gdyż serwer podstawowy może inicjować wszystkie przesyły strefy. Ponieważ jego administrator tworzy listę serwerów wtórnych które należy powiadomić, dostępne są jedynie wstępnie autoryzowane serwery wtórne. Przez całkowitą zmianę inicjatora przesyłów strefy z serwerów wtórnych na podstawowe utrudnia się znacząco możliwość kradzieży pliku strefy domeny. Jest to imponująca lista przyczyn dla których zaleca się stosowanie powiadamiania zgodnie z zaleceniami wydajności przesyłu przyrostowego [dosłownie? – przyp. tłum.]

Jednakże, niektórym serwery BIND w wersji 8.1.1 zdarza się zrzut pamięci (tzn. awaryjne zatrzymanie) podczas odbioru takich przesyłów z DNS-u Windows 2000 wobec czego zaleca się stosowanie wersji 8.1.2 jeżeli planowana jest taka organizacja serwerów wtórnych.

Organizacje które chcą uzyskać szybkie przetwarzanie zapytań DNS w skali światowej mogą rozmieścić serwery wtórne w różnych miejscach geograficznych, nawet umieszczając część plików stref na serwerach będących własnością współpracujących z nimi, życzliwych organizacji. Zapewni to lepsze parametry lokalnych zapytań i doda nadmiarowość która może okazać się bezcenna w przypadku awaryjnego odłączenia własnego ośrodka od Internetu.

Wtórne serwery DNS mogą wciąż zapewniać rozwiązywanie nazw podczas awarii, chociaż docelowy host może okazać się niedostępny. Jest to przydatne dla usług takich, jak Sendmail™, ponieważ jeżeli rzeczony jest w stanie rozwiązać nazwę hosta lecz nie może otworzyć sesji dla przesyłu wiadomości, po prostu odkłada wiadomość z powrotem do kolejki i próbuje ją wysłać w późniejszym terminie. Jeśli Sendmail™ nie potrafi rozwiązać nazwy hosta, zwraca wiadomość z błędem „Host nieznany”.

Windows 2000 posuwa się krok dalej od rozróżnienia typowych serwerów DNS: podstawowego i wtórnego, dodając jako trzeci rodzaj strefy integrację z Active Directory. W przypadku integracji mogą wciąż istnieć zwykłe serwery wtórne lecz można też stosować wielokrotne równorzędne serwery podstawowe korzystające z replikacji Active Directory. Zostało to opisane w rozdziale 7 – „Dynamiczny DNS i Active Directory”, gdzie omówiony został szereg rozwiązań DNS-u związanych z Active Directory.

Rozdział ten  jak dotąd dotyczył przestrzeni nazw domen i domenowych serwerów nazw. Pozostała część rozdziału skupia się na klientach, zapytaniach klientów i współpracy serwerów DNS odpowiadających na nie.

Rozwiązywanie zapytań klientów

Jeśli klient chce połączyć się z oddalonym systemem (jak na przykład użytkownik klikający na łącze do strony WWW), przed rozpoczęciem rzeczywistej komunikacji musi wykonać się szereg kroków. Pierwszym krokiem jest rozwiązanie nazwy zdalnego systemu na adres IP. Klient działa jako resolwer. Aby rozwiązać nazwę zdalnego systemu, klient wysyła zapytanie do jednego ze swoich serwerów DNS. W konfiguracji klienta zapisany jest przynamniej jeden serwer DNS. Kolejność przeszukiwania serwerów DNS można obejrzeć w zakładce DNS dialogu własności TCP/IP, jak na rysunku 2.4. Wprowadzenie do rozdziału 14, „Konfiguracja i rozwiązywanie klienta Windows” pokazuje, gdzie należy szukać tych informacji w różnych odmianach Windows 2000.

Na rysunku 2.5 widać, że na listę wpisać można jeden lub więcej adresów IP serwerów DNS, wskazujących resolwerowi klienta gdzie pytać o adresy dla nazw hostów. Klient odpytuje pierwszy serwer nazw z listy. Jeśli resolwer nie otrzyma potwierdzenia w zadanym przedziale czasu, będzie próbował następnych serwerów z listy aż do serwera nazw który przyjmie zapytanie.

Jeśli serwer nazw przyjmuje zapytanie klienta, ten zwykle oczekuje biernie na odpowiedź podczas gdy serwer usiłuje znaleźć adres IP odpowiadający nazwie hosta podanej w zapytaniu, przeszukując plik strefy lub odpytując inne serwery DNS. Jeżeli pierwszy serwer DNS przyjmie zapytanie lecz nie jest w stanie rozwiązać go lokalnie ani zdalnie,

Rysunek 2.4 DNS w okienku własności TCP/IP klienta Windows 95/98

Rysunek 2.5 Zaawansowana konfiguracja DNS w kliencie Windows 2000

zwraca odpowiedź o błędzie nazwy (NE od name error) wskazujący iż nazwa domeny nie istnieje. W takim przypadku, klient nie wysyła zapytania do alternatywnego serwera DNS.

Jeśli nazwa hosta zawiera nazwę domeny do której on należy, serwe...