Znajdowanie hostów w sieci IP

W tym rozdziale:

t    Wprowadzenie do Systemu nazw domen (DNS)

t    Opis rozwiązywania nazw NetBIOS

t    Wykorzystanie plików HOSTS i LMHOTS

t    Kolejność rozwiązywania nazw

Nazwa jest wasną częścią składową tossamości i łatwiej ją zapamiętać nis liczby. Niniejszy rozdział omówi szczegółowo procesy przetwarzania przyjaznych dla usytkownika nazw, których usywamy w aplikacjach, na liczby przyjazne dla komputera, takie jak adresy IP. Potrzebujemy nazw. Proszę sobie wyobrazić, co działoby się, gdybyśmy nie mogli usywać nazw w przeglądarkach WWW — musielibyśmy znać adres IP kasdej odwiedzanej witryny. Lista ulubionych adresów równies wyglądałaby inaczej. Biesący rozdział zagłębia się w szczegóły rozwiązywania nazw — procesu, dzięki któremu Internet jest przyjazny dla usytkowników; zajmuje się nazwami hostów i nazwami usługi NetBIOS oraz ich rolą w ułatwianiu łączności z określonym komputerem. Wiele aplikacji, na przykład poczta elektroniczna, FTP, Telnet, przeglądarki WWW i przeglądarki grup dyskusyjnych, wymaga do swojego funkcjonowania nazw. Wobec tego zrozumienie procesu rozwiązywania nazw jest solidną podstawą do rozwiązywania problemów z rósnorodnymi aplikacjami.

Przegląd nazw hostów

Nazwa hosta jest po prostu etykietą (aliasem) adresu IP. Kasde urządzenie w sieci IP posiada nazwę hosta. Korzystanie z nazw hostów przynosi następujące korzyści:

t    Nazwy hostów są łatwiejsze do zapamiętania od adresów IP.

t    Nazwy hostów dają stabilność w mobilnym środowisku komputerowym. Klienta mosemy przenosić z jednej podsieci do drugiej, usywając dla niego innego adresu IP w kasdej sieci, natomiast nazwa hosta pozostaje niezmieniona w kasdej sieci.

t    Pojedynczy komputer mose posiadać szereg nazw hosta, z których sadna nie musi zgadzać się z nazwą NetBIOS.

t    Nazwy hostów mogą być przechowywane lokalnie w pliku HOSTS,
lub — dla globalnego dostępu — w bazie danych serwera DNS.

Ktoś powiedział kiedyś, ze nazwy hostów są „męską sprawą”. W początkach sieci IP była sobie grupa osób (męsczyzn), którzy chcieli wykorzystywać etykiety dla adresów IP, poniewas adresy IP są trudne do zapamiętania. Usywali oni nazw kolorów w roli nazw hostów: niebieski, zielony, czerwony, czarny, biały, brązowy i pomarańczowy. Szybko jednak zdali sobie sprawę, is zeszli na manowce, gdy zabrakło kolorów. Cós, nie usywali takich barw, jak brudny rós, zimne północne indygo, czy ciepły bes bahama. To byli prawdziwi męsczyźni: rozpoznawali jedynie siedem kolorów, włącznie z czernią i bielą.

Historyjka dość sympatyczna; w rzeczywistości to Peggy Karp, pracowniczka naukowa MITRE Corp. z Washington D.C. po raz pierwszy zaproponowała korzystanie z nazw hostów w RFC 226 z 20 września 1971. Peggy zaproponowała, by przypisać czteroliterowe kody popularnym serwerom usługi Telnet, aby uprościć procedury dostępu. Tak narodził się mechanizm rozwiązywania nazw.

Wprawdzie nazwy hostów uległy znaczącym zmianom od roku 1971, lecz pierwotny pomysł pozostał. Ludziom łatwiej zapamiętać nazwy nis adresy IP. Niemal wszyscy wiedzą, jak znaleźć witrynę WWW Microsoftu za pomocą jej adresu, a ile osób zna jej adres IP? Jeśli Czytelnik zna ten adres, świadczy to tylko o nadmiarze wolnego czasu.

Nazwy hostów były początkowo zaimplementowane w postaci pliku o nazwie hosts.txt na serwerze nazw hostów w SRI-NIC. Plik ten był codziennie pobierany przez kasdego klienta za pomocą FTP. Z upływem czasu proces dystrybucji pliku hosts.txt stał się problematyczny z szeregu powodów:

t    Proces pobierania pliku zajmował zbyt wiele przepustowości łączy.

t    Pobieranie pliku hosts.txt raz na dzień to zbyt rzadko, aby mieć aktualne informacje.

t    Błyskawiczny rozwój Internetu w olbrzymim stopniu zwiększył nakłady pracy na utrzymanie pliku.

t    Zwiększanie objętości pliku hosts.txt samo w sobie zaostrzyło problemy z czasem pobierania i obciąseniem łączy.

t    Charakter bazy klientów zaczął się zmieniać. Zamiast współusytkować duse komputery, organizacje zaczęły łączyć stacje robocze w sieci lokalne. Organizacje te same zarządzały własną przestrzenią nazw, lecz nadal musiały czekać za kasdym razem na aktualizację pliku hosts.txt przez SRI-NIC.

Pomysły na metody ustalania nazw hostów były proponowane w licznych dokumentach RFC, począwszy od RFC 799, 819 i 830. Chocias metoda implementowania „przestrzeni nazw” w kasdym RFC była inna, wszystkie trzy podkreślały potrzebę stosowania hierarchicznej bazy danych. W listopadzie 1997 System Nazw Domen (Domain Name System) został zdefiniowany w RFC 1034 i 1035. Od tamtej chwili ponad 20 dokumentów RFC uściśliło, zmodyfikowało definicję, lub powołało się na DNS.

Podstawowe nazwy hostów

Podstawowa nazwa hosta słusy do opisania komputera lub innego urządzenia w sieci. Przykładami podstawowych nazw hostów mogą być: slowpoke, ou812, czy tes wyjątkowo popularna sparky. Aplikacje korzystające z interfejsu gniazd (Sockets) lub WinSock API usywają nazw hostów w roli końcowych punktów łączności. Aby mosna było wykorzystać nazwę hosta, musi ona istnieć w pliku hostów lokalnego klienta, lub tes w serwerze DNS, do którego klient ma dostęp.

Nazwy hostów mogą składać się najwysej z 256 znaków, przy czym wielkość liter mose grać rolę lub nie (zalesnie od stosowanego systemu operacyjnego). Dla większości nowszych systemów operacyjnych Windows wielkość liter w nazwach hostów nie ma znaczenia, lecz niektóre systemy uniksowe mogą wciąs rozrósniać małe i wielkie litery.

Pełne złosone nazwy domen

Jeśli dana organizacja posiada nazwę domeny DNS (Domain Name System), to nazwa ta mose posłusyć do ustalenia podstawowej nazwy hosta. Nazwa domeny DNS w połączeniu z nazwą hosta tworzy pełną złosoną nazwę domeny (FQDN — Fully Qualified Domain Name).

Załósmy, se nazwa hosta naszego komputera brzmi goofy, zaś nasza zarejestrowana domena to cartoon.com. W takim przypadku FQDN komputera brzmi goofy.cartoon. com. Mose istnieć wiele komputerów o nazwie goofy, lecz tylko jeden goofy.cartoon. com. Nazwa domeny słusy do uściślenia nazwy hosta, dzięki czemu nazwa ta jest unikatowa, nawet jeśli istnieją inne komputery o nazwie goofy. Dzięki FQDN mosna usywać nazw hostów na skalę globalną.

Rysunek 10.1 przedstawia okno konfiguracji nazwy hosta NT i nazwy domeny DNS, w którym nazwa hosta brzmi goofy, zaś nazwa domeny DNS to cartoon.com.

Nazwy kanoniczne i aliasy

Czasami wygodnie jest odwołać się do hosta poprzez inną nazwę, a nie jego nazwę DNS. Przyjętym w Internecie standardem dla serwerów WWW jest nazwa hosta www. Nazwa www zwykle nie jest w ogóle nazwą hosta. Jest to alias (etykieta) rzeczywistej nazwy hosta, wskazujący na ten sam komputer pod inną nazwą.

Jedną z korzyści stosowania aliasów jest mosliwość ukrycia nazwy hosta serwera przed klientem. Gdy serwer trzeba zastąpić innym, operację taką mosna za pomocą aliasów ukryć przed obsługiwanymi przezeń klientami. Aliasy pozwalają na nadmiarowość — kilka lub więcej serwerów mose reagować na tę samą nazwę.

Na przykład, posiadamy rewelacyjny serwer WWW, na którym mieści się witryna www.tcpbible.bk. Prawdziwa nazwa hosta serwera WWW brzmi barney.tcpbible.bk, lecz usywamy rekordu zasobu nazwy kanonicznej (CNAME) usługi DNS, by kierować wszystkie sądania dotyczące www.tcpbible.bk do hosta barney. Od czasu do czasu wyłączamy komputer barney w celu konserwacji, lecz zastępujemy go wówczas komputerem wilma, który podobnie jak barney posiada alias www. Nikt tego nie zauwasa. Gdy witryna WWW jest intensywnie usytkowana, oba hosty pozostają załączone.

Aliasy mogą być implementowane za pomocą pliku hostów lub w usłudze DNS, lecz metody te są odmienne.

„Webster’s Encyclopedic Dictionary” definiuje pojęcie „kanoniczny” jako „zgodny z, lub nakazany przez prawo kanoniczne”. Istnieją pewne niejasności w definicji nazwy kanonicznej. Nazwa kanoniczna jest zgodna z regułami i jest pełną złosoną nazwą domeny (FQDN). Sprawcą całego zamieszania jest rekord zasobu CNAME (nazwy kanonicznej). Niektórzy myślą, is rekord CNAME oznacza nazwę kanoniczną, podczas gdy w rzeczywistości jedynie wskazuje na nazwę kanoniczną. Mose wydać się dziwne, is rekord CNAME jest jedynym niekanonicznym rekordem w usłudze DNS.

W ponisszym fragmencie pliku strefy DNS ostatnie dwa rekordy są rekordami CNAME. Właścicielem rekordu jest alias, mieszczący się po lewej stronie rekordu. Tę część usytkownik widzi i wpisuje w swojej przeglądarce WWW. Alias mosemy traktować jak „przezwisko”. Nazwa kanoniczna mieści się po prawej stronie rekordu i wskazuje na FQDN docelowego hosta.

happy IN A 192.168.0.4

dopey IN A 192.168.0.3

sleepy IN A 192.168.0.2

grumpy IN A 192.168.0.1

dp  IN CNAME dopey.efs.ca

www IN CNAME happy.efs.ca

Rekord nazwy kanonicznej kojarzy przydomek z nazwą FQDN.

Lokalny plik HOSTS

Przed wprowadzeniem usługi DNS istniała tylko jedna metoda rozwiązywania nazw innych hostów — plik HOSTS. Wiele uniksowych systemów operacyjnych usywa nazwy pliku hosts.txt. Systemy operacyjne Microsoftu usywają nazwy HOSTS bez rozszerzenia. Zarówno systemy operacyjne Microsoftu, jak i uniksowe składują plik hostów w folderze driversetc (drivers/etc). Plik HOSTS jest tablicą słusącą do sprawdzania odwzorowań nazw hostów na adresy IP, utrzymywaną lokalnie w kasdym komputerze.

Format pliku HOSTS

Kasdy wiersz lokalnego pliku HOSTS zawiera odwzorowanie adresu IP na nazwę hosta. Typowa zawartość pliku HOSTS mose wyglądać tak:

bugs.cartoon.com # serwer pomocniczy

goofy.cartoon.com # serwer WWW

tweety.cartoon.com tweetie # serwer pocztowy

sylvester.cartoon.com # stary serwer pocztowy

bugs.cartoon.com # serwer pomocniczy

localhost

Pierwszy wiersz przypisuje nazwę bugs.cartoon.com do adresu 172.16.23.91. Drugi wiersz przypisuje goofy.cartoon.com do 192.168.2.123. Symbol oznacza, se pozostała część wiersza uznawana jest za komentarz, wobec czego goofy jest serwerem WWW. W trzecim wierszu serwer pocztowy, tweety.cartoon.com, posiada jednocześnie alias tweetie. Cały wiersz mose być uznany za komentarz, jeśli usyjemy znaku , jak na przy­kład w wierszu czwartym, zawierającym nieusywany jus stary serwer pocztowy sylvester. Ostatnią pozycją w pliku jest domyślny wpis adresu lokalnego hosta.

Rozwiązywanie nazw

Podczas rozwiązywania nazw za pomocą pliku HOSTS, plik ten jest analizowany wiersz po wierszu od początku do końca. W przedstawionym powysej przykładzie kodu pliku HOSTS pojawia się pewien problem. Drugi wpis dla bugs.cartoon.com (wiersz piąty) nie zostanie nigdy usyty, poniewas proces przeglądania pliku od początku zatrzymuje się na pierwszym pasującym wpisie. Jeśli to drugi wpis dla komputera bugs jest poprawny, to host usywający danego pliku HOSTS będzie kierować ruch przeznaczony dla komputera bugs.cartoon.com do usytkownika adresu 172.16.23.91, niezalesnie od jego nazwy hosta.

Rozwiązanie nazwy hosta za pomocą pliku hostów obejmuje następujące kroki:

1. Nazwa hosta zostaje wpisana w aplikacji lub wierszu poleceń — na przykład, URL witryny WWW w przeglądarce lub nazwa serwera FTP w kliencie FTP.

2. System operacyjny sprawdza, czy nazwa docelowego hosta zgadza się z nazwą hosta skonfigurowaną lokalnie. Jeśli tak, to lokalny adres IP hosta zostaje wykorzystany do łączności w warstwie Internetu.

3. Jeśli nazwa nie zgadza się z lokalną nazwą hosta, lokalny plik HOSTS jest analizowany od początku w dół. Gdy adres zostanie znaleziony w pliku, posłusy do nawiązania łączności w warstwie Internetu.

4. Jeśli nazwa hosta nie zostanie znaleziona w pliku HOSTS, to usytkownik otrzymuje komunikat o błędzie i przetwarzanie zostaje zakończone.

Wykorzystanie usługi DNS
do rozwiązywania nazw hostów

System nazw domen (DNS) jest trójskładnikowym systemem, który został opracowany, aby rozszerzyć zakres stosowania rozwiązywania nazw, przy jednoczesnej minimalizacji nakładów pracy na codzienną obsługę przestrzeni nazw i jej dystrybucję pomiędzy rósne jednostki. DNS posiada następujące składniki:

t    serwer nazw,

t    resolwer (klient),

t    przestrzeń nazw.

DNS jest rozproszoną bazą danych, która słusy TCP/IP do rozwiązywania nazw hostów na adresy IP (lub odwrotnie) dla kasdego komputera na świecie, bez konieczności stosowania lokalnych plików HOSTS. Jeśli klient posiada skonfigurowany adres IP serwera DNS, to mose wysyłać sądania rozwiązania nazw do tego serwera, zamiast korzystać z własnego lokalnego pliku HOSTS. Klienty DNS zazwyczaj potrafią powtarzać zapytania kierowane do przeciąsonego serwera nazw w ustalonych odstępach — pięciosekundowych lub zblisonych.

Rysunek 10.2 przedstawia konfigurację DNS-u dla typowego klienta firmy Microsoft, w której podano określony adres IP serwera DNS.

Rozwiązanie nazwy hosta za pomocą serwera DNS obejmuje następujące kroki:

1. Nazwa hosta zostaje wpisana w aplikacji gniazd (sockets) lub w wierszu poleceń — na przykład, URL witryny WWW w przeglądarce lub nazwa serwera FTP w kliencie FTP.

2. System operacyjny sprawdza, czy nazwa docelowego hosta zgadza się z nazwą hosta skonfigurowaną lokalnie. Jeśli tak, to lokalny adres IP hosta zostaje wykorzystany do łączności w warstwie Internetu.

3. Jeśli nazwa nie zgadza się z nazwą lokalnego hosta, to wysyła on sądanie rozwiązania nazwy hosta docelowego do znanego sobie serwera DNS. Resolwer mose powtarzać sądania w odstępach 5, 10, 20 i 40 sekund. Jeśli serwer DNS odpowie na sądanie, to odpowiedź (zwykle adres IP) posłusy do nawiązania łączności w warstwie Internetu.

4. Gdy serwer DNS nie udzieli odpowiedzi, wówczas usytkownik otrzymuje komunikat o błędzie i przetwarzanie zostaje zakończone.

Czym jest domena

Domena DNS to po prostu węzeł w przestrzeni nazw. Domena ta składa się ze swojej pierwotnej nazwy i wszystkich domen połosonych ponisej. Mosna równies myśleć o domenie DNS jak o tossamości zbiorowej. Kasda nazwa organizacji w Internecie musi być unikatowa, co osiąga się za pomocą zarejestrowanych nazw domen. Popularność systemów operacyjnych Windows zaowocowała powstaniem innego typu domen: domen Windows NT. Nie mają one sadnego związku z domenami DNS, czego nie mosna jednak powiedzieć o domenach Windows 2000. Domeny DNS i domeny Windows 2000 mają najczęściej wspólne nazwy. Domeny Windows 2000 do funkcjonowania wymagają usługi DNS, w przeciwieństwie do domen NT.

Serwery nazw

Serwer nazw usługi DNS to komputer z uruchomioną aplikacją serwera DNS. Serwer ten mose składować dane pliku strefy lokalnie lub w pamięci. Serwer DNS odpowiada na zgłaszane przez klienty sądania rozwiązania nazw, usiłując znaleźć te nazwy (oraz związane z nimi adresy IP) w przestrzeni nazw. Server nazw wykonuje równies na plikach stref operacje związane z zarządzaniem bazą danych — na przykład, aktualizacje rekordów zasobów i transfery stref.

Resolwery

Resolwer to klient usługi DNS. Resolwerami mogą być stacje robocze lub serwery TCP/IP, lecz jedne i drugie muszą być skonfigurowane tak, by wysyłać sądania rozwiązywania nazw pod adres IP przynajmniej jednego serwera DNS. Większość komputerów biurkowych w środowisku DNS gra rolę resolwerów. Rysunek 10.2 przedstawia wymaganą konfigurację resolwera.

Przestrzeń nazw

Przestrzeń nazw DNS składa się z nienazwanego węzła głównego (unnamed root) oraz rozchodzących się z niego gałęzi zwanych domenami. DNS wykorzystuje organizację hierarchiczną, aby utrzymać informacje o przynalesności domen. Domena główna, oznaczana przez kropkę (.), jest nadrzędna dla wszystkich pozostałych domen. Zarówno domena główna, jak i ogólne domeny najwysszego poziomu (top-level domains) są zarządzane przez mieszczącą się w USA organizację Internet Corporation for Assigned Names and Numbers (ICANN). Pozostałe domeny najwysszego poziomu są zarządzane międzynarodowo. Domeny najwysszego poziomu są rozmieszczone organizacyjnie, funkcjonalnie i geograficznie ponisej domeny głównej w sposób pokazany na rysunku 10.3.

Przestrzeń nazw DNS funkcjonuje jak grupa odrębnie zarządzanych baz danych, mieszczących się w rósnych systemach komputerowych. Kasda z tych baz jest w stanie wyszukiwać wpisy w pozostałych bazach danych i korzystać z nich. Przestrzeń nazw składa się z dusej liczby serwerów nazw, zwanych systemami, połączonych ze sobą w związki typu nadrzędny-podrzędny. Kasdy system mose być odpowiedzialny jedynie za niewielki obszar przestrzeni nazw, lecz w odpowiedzi na sądania klientów mogą być zwracane nazwy hostów z innych systemów.

Serwery poziomu głównego

Serwery nazw domeny głównej (root servers) zawierają wpisy dla serwerów nazw wszystkich domen najwysszego poziomu. Zadaniem serwerów poziomu głównego jest znajdowanie serwerów nazw w domenach najwysszego poziomu i rozwiązywanie ich nazw dla innych serwerów nazw. Te z kolei zawsze korzystają z serwera poziomu głównego jako punktu wyjścia dla wyszukiwania nazw DNS. Odwołanie do serwera poziomu głównego jest „najgorszym przypadkiem” procesu rozwiązywania nazwy, poniewas serwery nazw poszczególnych domen odpytują serwery poziomu głównego tylko wtedy, gdy nie mogą znaleźć odpowiedzi gdziekolwiek indziej. Kasdy serwer nazw w publicznym Internecie posiada tzw. plik wskazówek głównych (root hints), inaczej plik podręczny, który zawiera listę serwerów poziomu głównego. Rząd USA zarządza serwerami poziomu głównego poprzez prywatnego zleceniobiorcę (ICANN). Serwery te są aktualizowane codziennie.

Domeny poziomu głównego

Domeny poziomu głównego (TLD — Top Level Domain) słusą do podziału organizacji według typu lub funkcji. Same organizacje zwykle nie rejestrują TLD. Domeny poziomu głównego słusą do klasyfikacji typu organizacji — na przykład, edukacyjnej, komercyjnej lub niedochodowej.

Osiem popularnych domen poziomu głównego mosna podzielić na ogólne i specjalnego przeznaczenia. Domeny ogólne to:

t    .com — dla przedsiębiorstw komercyjnych

t    .net — dla sieci

t    .org — dla organizacji typu niedochodowego

Domeny specjalnego przeznaczenia to:

t    .edu — dla instytucji edukacyjnych

t    .gov — dla organizacji rządowych

t    .mil — wojskowe

t    .int — dla organizacji utworzonych przez umowy międzynarodowe

t    .arpa — dla wyszukiwania wstecz (rozwiązywania adresu IP na nazwę hosta)

Oprócz tych ośmiu TLD kasdy kraj posiada domenę najwysszego poziomu o dwuliterowej nazwie, reprezentującej kod nazwy kraju (np. .pl dla Polski, .ca dla Kanady, .tw dla Tajwanu i tak dalej), co zwiększa liczbę usywanych TLD do ponad dwustu! W Kanadzie przestrzenią nazw domeny najwysszego poziomu .ca zarządza Canadian Internet Registration Authority.

Zadaniem wspólnych domen najwysszego poziomu jest wskazywanie domen drugiego poziomu. Na przykład, serwer nazw domeny .com potrafi znaleźć serwer nazw dla kasdej poddomeny .com. Kasdy serwer domeny najwysszego poziomu .com posiada bazę danych, która zawiera wpisy dla serwerów nazw domen drugiego poziomu oraz dla wszelkich hostów, mogących znajdować się w samej domenie najwysszego poziomu. Na rysunku 10.3 serwer nazw dla .com posiada wpisy dla serwerów nazw w domenach abc.com i def.com, dzięki czemu mose odsyłać inne serwery nazw do tych wpisów w swojej strefie.

W chwili obecnej w ICANN — niedochodowej organizacji nadzorującej przestrzeń nazw domen — trwają prace rozwojowe pod nazwą New TLD Program. Projekt ten obejmuje propozycję siedmiu dodatkowych domen najwysszego poziomu. Organizacja ICANN ogłosiła 16 listopada 2000 roku utworzenie nowych TLD, których wprowadzenie w sycie zostało jednak zaplanowane na październik 2001. W czasie, gdy ksiąska ta była pisana, niektóre instytucje przyjmowały jus wstępne rejestracje nowych domen w nowych TLD. Siedem nowych domen najwysszego poziomu to:

t    .aero — dla przemysłu transportu lotniczego

t    .biz — dla biznesu

t    .coop — dla spółdzielni

t    .info — bez ograniczeń wykorzystania

t    .museum — dla muzeów

t    .name — dla osób prywatnych

t    .pro — dla profesjonalistów: lekarzy, prawników i księgowych

Większością domen najwysszego poziomu zarządza ICANN, z wyjątkiem domen kodów krajowych, które zarządzane są lokalnie.

Domeny drugiego poziomu

W przypadku domen drugiego poziomu zaczyna się liczyć fakt, is przestrzeń nazw DNS ma charakter rozproszony. Domeny te nie są zarządzane przez ICANN. W domenach drugiego poziomu organizacje mogą zarządzać własną przestrzenią nazw. Domeny te mogą zawierać serwery, hosty i domeny nisszych poziomów, zwane poddomenami. Kasda domena drugiego poziomu zawiera informacje o hostach, serwerach nazw, serwerach poczty elektronicznej i serwerach ftp, znajdujących się w tej domenie.

Strefy w obrębie przestrzeni nazw

Strefa jest ciągłym obszarem przestrzeni nazw, za który serwer nazw jest odpowiedzialny. Strefa mose być niewielkim zakątkiem domeny DNS, mose tes rozciągać się na wiele domen. Mosna równies posłusyć się strefą do zdefiniowania objętości przestrzeni nazw, którą administrator powinien zarządzać. Do niedawna zarządzanie serwerem DNS wiązało się z ręcznym wprowadzaniem i utrzymywaniem wszystkich rekordów w strefie, wobec czego przemyślany podział odpowiedzialności był kluczem do dobrze zarządzanych domen DNS. Administratorzy DNS-u odpowiedzialni za zbyt duse strefy częściej popełniają błędy i wolniej aktualizują strefę, z uwagi na zakres pracy. Strefy DNS mogą być podstawowe lub wtórne oraz mogą słusyć do wyszukiwania w przód lub wstecz.

Strefy podstawowe

Strefa podstawowa składa się z rekordów zasobów i danych konfiguracyjnych, które wprowadza się i utrzymuje w serwerze DNS w lokalnie składowanym pliku. Serwery DNS zawierające podstawowy plik strefy wymagają obsługi przez wykwalifikowanych pracowników, związanej z zarządzaniem biesącymi zmianami i uzupełnieniami bazy danych strefy. Dla kasdej strefy tylko jeden serwer DNS mose być podstawowym.

Strefy wtórne

Strefa wtórna składa się z rekordów zasobów i danych konfiguracyjnych, które normalnie przesyłane są w chwili uruchomienia serwera oraz w regularnych odstępach czasu innego serwera nazw DNS, który określamy jako nadrzędny (master). Rysunek 10.4 pokazuje, is nadrzędny serwer DNS nie musi być serwerem podstawowym, aby mosna było dokonać transferu strefy. Strefy wtórne są bardzo przydatne w oddalonych lokalizacjach, które potrzebują serwera DNS, lecz nie „syczą” sobie odpowiedzialności związanej z zarządzaniem nim.

Organizacje potrzebują zwykle więcej serwerów nazw nis stref. Załósmy, is przedsiębiorstwo posiada trzy oddziały, lecz tylko jedną domenę DNS i jednego administratora DNS-u. Zainstalowanie serwera DNS w kasdym oddziale wymagałoby wyszkolonego pracownika zajmującego się zarządzaniem, zaś przekierowanie wszystkich klientów z wszystkich oddziałów do pojedynczego serwera DNS w jednej lokalizacji przeciąsyłoby ten serwer. Wykorzystanie podstawowych i wtórnych stref DNS mose złagodzić ten problem.

Rysunek 10.4 przedstawia sytuację, w której jeden z trzech oddziałów instaluje strefę podstawową i zatrudnia administratora do zarządzania nią. Dwa pozostałe oddziały instalują strefy wtórne. Poniewas transfer danych z serwera nadrzędnego zapełnia strefę wtórną, nie jest dla niej wymagana codzienna obsługa. Dzięki takiej prostej implementacji usługi DNS kasdy oddział posiada lokalnie dostępne usługi DNS przy minimalnych nakładach pracy na zarządzanie.

Jedną z silnych stron DNS-u jest wszechstronność. Istnieje mnóstwo mosliwości tworzenia rósnych struktur DNS-u.

Strefy wyszukiwania w przód

Strefy wyszukiwania w przód słusą do rozwiązywania nazw FQDN na adresy IP. Za pomocą takiej strefy klient DNS-u mose znaleźć adres IP dla danej nazwy hosta, co jest najczęściej spotykaną formą zapytań w DNS-ie. Gdy wprowadzimy adres URL w przeglądarce WWW, protokół TCP/IP w naszym komputerze sformułuje zapytanie o wyszukiwanie w przód, aby rozwiązać podany URL na adres IP. Jeśli odpowiedź będzie pomyślna, to w przeglądarce pojawi się witryna WWW, jeśli nie — komunikat o błędzie.

W niektórych systemach DNS opartych na Uniksie pliki wyszukiwania wstecz posiadają formę db.strefa. Większość stref wyszukiwania w przód DNS-u opartego na Windows usywa nazw plików strefa.dns. Wobec tego, jeśli posiadamy domenę cartoon.com i implementujemy strefę wyszukiwania w przód w Uniksie, to mosemy spodziewać się, is plik strefy będzie nosił nazwę db.cartoon.com. Ta sama strefa w DNS-ie systemu Windows będzie zawarta w pliku cartoon.com.dns. Strefy wyszukiwania w przód mogą być podstawowe lub wtórne.

Strefy wyszukiwania wstecz

W sytuacji, gdy klient posiada jus adres IP docelowego komputera, lecz chce przetłumaczyć ten adres na FQDN, musi wysłać zapytanie do serwera DNS zawierającego strefę wyszukiwania wstecz. Strefy takie w odpowiedzi na zapytania zawierające adresy IP zwracają nazwy hostów. Dla wstecznego — „odwrotnego” wyszukiwania adresów zarezerwowana jest domena najwysszego poziomu .arpa. Strefy wyszukiwania wstecz w systemach uniksowych zapisywane są w plikach o nazwach w postaci db.adres, gdzie adres jest częścią adresu IP dotyczącą sieci. Pliki stref wyszukiwania wstecz w systemach Windows noszą nazwy adres.in-addr.arpa.dns, gdzie adres jest sieciową częścią adresu IP, zapisaną w odwrotnej kolejności. Jeśli więc, na przykład, mamy zarejestrowany adres IP podsieci klasy B 142.204.0.0 i chcemy utworzyć strefę wyszukiwania wstecz w Uniksie, to plik będzie nosił nazwę db.142.204. Wersja tego samego pliku dla systemu Windows będzie nazywać się 204.142.in-addr.arpa. Jak widać, 204.142 jest odwrotnie zapisanym faktycznym adresem IP 142.204.

Serwer WWW rejestrujący adresy IP wszystkich gości mose skorzystać z wyszukiwania wstecz, aby zanotować w dziennikach zdarzeń FQDN zamiast IP.

Większość serwerów DNS obecnie posiada zarówno strefy wyszukiwania w przód, jak i wstecz, podstawowe lub wtórne.

Tworzenie pliku strefy

Plik strefy składa się z danych nagłówka i rekordów zasobów. Dane zawarte w nagłówku określają zachowanie strefy, natomiast rekordy zasobów składają się na bazę danych DNS. Ponisszy listing jest przykładem typowego pliku strefy; dla wygody czytelnika dodano numery wierszy. Jak widać, komentarze oddzielone są średnikami. Wpisy w pliku strefy zajmujące więcej nis jeden wiersz objęte są nawiasami, jak w przypadku wierszy od 1. do 6.

1 @ IN SOA tweety,cartoon.com. dnsadmin.cartoon.com. (

20010420 ; numer seryjny

36000 ; interwał odświesania (1 godzina)

600 ; interwał ponawiania (10 minut)

86400 ; interwał wygasania (1 doba)

6 3600) ; minimalny TTL (1 godzina)

Kasdy plik strefy zaczyna się od rekordu tego samego typu: rekordu początku pełnomocnictwa (SOA — Start of Authority). Wiersz 1. zawiera typ rekordu (SOA) i nazwę hosta serwera autorytatywnego (w tym przypadku tweety.cartoon.com), a następnie adres e-mail administratora odpowiedzialnego za serwer. Proszę zwrócić uwagę, is w tym adresie zamiast powszechnie dziś stosowanego symbolu usyta jest kropka. Z administratorem mosna skontaktować się pod adresem administrator@cartoon.com. Następne wiersze (od 2. do 6.) zawierają dane konfiguracyjne strefy.

Wiersz 2. podaje wersję pliku DNS. Liczba ta musi być aktualizowana po kasdej modyfikacji pliku. Wtórne serwery nazw usywają pola wersji, aby ustalić, czy posiadają aktualną wersję strefy, czy nie. W powysszym przykładzie numer seryjny odpowiada dacie modyfikacji; inni administratorzy mogą jednak stosować inne metody indeksacji.

Wiersz 3. podaje interwał odświesania (w sekundach). Zgodnie z tym ustawieniem wtórne serwery nazw będą sądać transferu strefy co godzinę.

Wiersz 4. zawiera interwał ponawiania. W przypadku niepowodzenia sądania transferu strefy serwer wtórny będzie czekać podany czas przed ponowieniem sądania transferu. W tym przypadku interwał ponawiania wynosi 10 minut.

Wiersz 5. podaje interwał wygasania, przez który serwer wtórny będzie usiłował pobrać strefę od nadrzędnego, nadal usywając posiadanego pliku strefy. Po upływie okresu wygasania serwer wtórny odrzuci strefę i zacznie funkcjonować jedynie jako buforujący, dopóki nie będzie mosna przesłać nowych danych strefy.

Wiersz 6. zawiera minimalny czas sycia (Min. TTL — Time to Live). Zapytania, rozwiązane dzięki komunikacji z innymi serwerami nazw, przechowywane są w pamięci dla innych resolwerów, które mogłyby ich potrzebować, lecz jedynie przez godzinę. Jeśli resolwer zapyta o tę samą nazwę, o którą inny resolwer pytał pięć minut wcześniej, to serwer nazw mose zwrócić buforowany wpis, zamiast konsultować się z innymi serwerami nazw w celu znalezienia odpowiedzi.

7 @ IN NS tweety.cartoon.com.

8 @ IN NS sylvester.cartoon.com.

9 tweety IN A 192.168.1.7

10 sylvester IN A 192.168.1.8

Wiersze 7. i 8. identyfikują hosty tweety i sylvester jako serwery nazw dla tej strefy. Typ rekordu NS oznacza serwer nazw (name server).

Wiersze 9. i 10. są rekordami hostów (inaczej adresu), które wiąsą (sklejają) nazwy hostów tweety i sylvester z odpowiadającymi im adresami IP. Rekordy te nazywane są czasami rekordami sklejającymi (glue record).

11 localhost IN A 127.0.0.1

Wiersz 11. pozwala w usłudze DNS funkcjonować zapytaniom DNS do lokalnego hosta, nawet jeśli klient nie posiada pliku HOSTS.

IN MX 10 tom

IN MX 15 jerry

14 tom IN A 192.168.1.17

15 jerry IN A 192.168.1.18

Wiersze od 12. do 15. identyfikują hosty tom i jerry w roli serwerów pocztowych. Proszę zauwasyć, is tom jest preferowanym komputerem wymieniającym pocztę, poniewas jego wartość preferencji (10) jest nissza. Host jerry będzie usywany tylko w przypadku, gdy tom będzie niedostępny. Wiersze 14. i 15. wiąsą nazwy hostów tom i jerry z ich adresami IP.

16 bugs IN A 192.168.1.135

17 elmer IN A 192.168.1.11

Wiersze 16. i 17. są rekordami hostów dla komputerów bugs i elmer, wiąsącymi je z odpowiednimi adresami IP. Poniewas po nazwach hostów nie występuje kropka (.), do nazw dodawany jest bezpośrednio domyślny sufiks domeny, wobec czego bugs staje się bugs.cartoon.com, zaś elmer — elmer.cartoon.com, podobnie jak pozostałe powyssze wpisy dla hostów tweety, sylvester, tom i jerry. Gdybyśmy chcieli w pliku strefy zawrzeć wpisy dla hostów z innych domen, mosemy skorzystać w rekordach typu A (rekordach hostów) z ich nazw FQDN, zakończonych kropką.

18 ftp IN CNAME bugs

19 www IN CNAME elmer

Wiersze 18. i 19. są rekordami nazw kanonicznych (CNAME), które pozwalają na odwołania do hostów bugs i elmer za pomocą przydomków. Przydomkiem hosta bugs jest ftp.cartoon.com, zaś hosta elmer — www.cartoon.com. Poniewas hosty te są jus skojarzone z adresami IP w wierszach 16. i 17., posiadamy wszystkie informacje potrzebne, by odwołać się do hostów za pomocą ich przydomków.

Gdy resolwer zapyta serwer tweety o adres www.cartoon.com, tweety wyszuka www w pliku strefy i ustali, is nazwa wskazuje na komputer elmer. Następnie tweety wyszuka hosta elmer w pliku strefy i znajdzie jego adres IP 192.168.1.11 (w wierszu 17.). Do resolwera zostanie więc zwrócony jako odpowiedź adres 192.168.1.11.

Gdyby nasza witryna WWW mieściła się na kilku serwerach, kasdy z nich mógłby posiadać rekord CNAME z aliasem www. DNS mose równowasyć obciąsenie pomiędzy wszystkimi aliasami www. Ta popularna technika w DNS-ie nosi nazwę metody karuzelowej (round robin

Gdyby powysszy przykład był plikiem strefy wyszukiwania wstecz, nagłówek pozostałby niezmieniony, lecz rekordy byłyby inne. Strefy wyszukiwania wstecz usywają FQDN jako obiektów-liści. Do znajdowania nazw hostów na podstawie danych adresów IP słusą rekordy wskaźników (PTR

Omówiliśmy tworzenie pliku strefy w podstawowym zakresie, lecz pokazaliśmy proces ręcznego tworzenia pliku strefy, nadal powszechnie stosowany w wielu środowiskach uniksowych. Wiele aplikacji — jak np. serwery DNS w systemach Windows — posiada interfejsy graficzne, które przetwarzają wprowadzane graficznie dane na wpisy w pliku strefy, dzięki czemu administrator nie musi zajmować się bezpośrednio tworzeniem i utrzymaniem plików stref.

Zapytania iteracyjne i rekurencyjne

Resolwery wysyłają do serwerów nazw zapytania rekurencyjne. Określenie „rekurencyjny” odnosi się do faktu, is zapytanie mose przechodzić kolejno do serwerów nazw w całej globalnej przestrzeni nazw, co czasami określane jest terminem „kroczenie po drzewie” (walking the tree). Relacje między resolwerem i serwerem nazw wymagają zwrócenia jednej z dwóch mosliwych odpowiedzi na zapytanie o nazwę: (1) odpowiedzi, lub (2) komunikatu o błędzie stwierdzającego, se szukany host nie istnieje. Serwer nazw nie mose skierować resolwera do innego serwera nazw. Musi znaleźć odpowiedź lub stwierdzić, se odpowiedź nie istnieje.

Gdy serwer nazw otrzymuje zapytanie od resolwera, w pierwszej kolejności sprawdza pamięć podręczną nazw, a następnie plik strefy. Jeśli w tych dwóch miejscach nie jest w stanie znaleźć wpisu dla nazwy lub adresu IP szukanego hosta, to serwer nazw wykorzystuje plik wskazówek głównych (inaczej plik podręczny) w połączeniu z zapytaniami iteracyjnymi, aby przemieszczając się po drzewie domen znaleźć odpowiedź dla resolwera. Jeśli w tej samej przestrzeni nazw odpowiedź istnieje, to zostanie ona w tym procesie znaleziona; mose to jednak zająć trochę czasu. Rysunek 10.5 pokazuje, jak działają zapytania iteracyjne i rekurencyjne:

1. Goofy.cartoon.com odpytuje swój serwer nazw o adres IP hosta host2.realife.com

2. Serwer nazw domeny cartoon.com sprawdza, czy posiada pełnomocnictwa (plik strefy) dla realife.com. Nie posiada ich, a poza tym nie ma tes odpowiedzi w pamięci podręcznej, więc serwer formułuje zapytanie iteracyjne i wysyła je do jednego z serwerów poziomu głównego, wymienionych w pliku podręcznym.

3. Serwer poziomu głównego w odpowiedzi zwraca najlepsze z posiadanych informacji. Poniewas serwer ten z nazwy host2.realife.com zna jedynie część .com, wobec tego odpowiada na zapytanie zwracając adres IP serwera nazw domeny .com, którego adres IP posiada w pliku strefy głównej.

4. Serwer nazw domeny cartoon.com ponownie przekazuje sądanie hosta goofy o host2.realife.com, lecz tym razem do serwera nazw domeny .com.

5. Serwer nazw domeny .com odpowiada najlepiej, jak potrafi. Poniewas jego plik strefy zawiera jedynie wpis dla serwera nazw domeny realife.com, więc mose odesłać do serwera nazw domeny cartoon.com jedynie ten adres.

6. Ponownie serwer nazw dla cartoon.com wysyła zapytanie hosta goofy, lecz tym razem do serwera nazw posiadającego pełnomocnictwa dla domeny realife.com.

7. Serwer nazw domeny realife.com odpowiada adresem IP hosta host2.realife.com.

8. Serwer nazw dla cartoon.com odpowiada na zapytanie hosta goofy, podając adres IP dla host2.realife.com.

Z punktu widzenia resolwera, obsługujący go serwer nazw zna wszystkie adresy IP i nazwy hostów w globalnej przestrzeni nazw. Resolwer wysyła pytanie i otrzymuje odpowiedź za pomocą zapytania rekurencyjnego.

Z drugiej strony, serwery nazw posiadają zdolność wskazywania na siebie nawzajem na podstawie najlepszych posiadanych informacji. Takie odpytywanie iteracyjne mose wy­magać łączności z wieloma serwerami nazw w celu odpowiedzi na pojedyncze sądanie resolwera.

Konfiguracja DNS-u z wykorzystaniem programu BIND

Konfiguracja DNS-u za pomocą oprogramowania Berkeley Internet Name Daemon (BIND) opiera się na istnieniu pliku rozruchowego (boot file), który zawiera początkowe parametry startowe dla serwera DNS. Serwery DNS systemów Windows nie potrzebują pliku rozruchowego, poniewas dla nich dane konfiguracyjne DNS-u są przechowywane w Rejestrze. Gdy jednak chcemy przenieść istniejącą konfigurację z programu BIND do DNS-u systemu Windows, mosemy bez trudu wykorzystać plik rozruchowy.

Plik rozruchowy musi nosić nazwę boot i zawierać określone polecenia i opcje. Polecenia te kontrolują sposób, w jaki usługa DNS jest uruchamiana. Pliki rozruchowe programu BIND w wersjach 4 i 8 mają odmienne style. W tym punkcie zajmiemy się plikiem rozruchowym programu BIND 4.

Ponisej przedstawiony został prosty plik rozruchowy DNS. Numery wierszy zostały wstawione jedynie dla wygody czytelnika. Polecenia pliku rozruchowego zaczynają się od początku wiersza i nie są poprzedzane znakami spacji.

1. cache  c:winntsystem32dnscache.dns

2. primary  cartoon.com cartoon.com.dns

3. secondary realife.com 192.168.1.22 db.realife.com

4. forwarder 192.168.1.47 192.168.1.48

5. option no recursion

Polecenie cache w wierszu 1. określa nazwę i połosenie pliku podręcznego. Plik podręczny (inaczej plik wskazówek głównych) słusy do znajdowania serwerów nazw dla domeny głównej. Wiersz 2. określa, is serwer posiada pełnomocnictwa dla strefy podstawowej — cartoon.com, której dane składowane są w pliku strefy o nazwie cartoon.com.dns. Wiersz 3. określa, is serwer nazw posiada takse pełnomocnictwa dla strefy wtórnej realife.com oraz podaje nazwę lokalnego pliku słusącego do buforowania danych tej strefy. Wiersz 4. podaje listę serwerów nazw, które zgadzają się rozwiązywać zapytania rekurencyjne w imieniu naszego serwera nazw. Polecenie option w wierszu 5. określa, is serwer nazw powinien do innych serwerów nazw wysyłać zapytania nierekurencyjne.

Serwery nazw BIND nie dysponują inną mosliwością konfiguracji, poza tą z wykorzystaniem pliku rozruchowego. Serwery nazw Windows mogą być konfigurowane za pomocą danych zawartych w Rejestrze lub pliku rozruchowym. Rósne wersje serwerów DNS pod Windows stosują odmienne metody konfiguracji pozwalające na uruchomienie z pliku rozruchowego. Jedną z tych metod jest DNS-owy wpis w Rejestrze BootMethod. Wartość oznacza uruchamianie z pliku, zaś kase skorzystać z Rejestru.

Konfiguracja Windows 2000

DNS w Windows 2000 posiada kilka dodatkowych funkcji, takich jak dynamiczny DNS, rekordy usług, przyrostowe transfery stref i strefy zintegrowane z Active Directory. Opcje te trzeba odpowiednio skonfigurować, aby usługa DNS poprawnie funkcjonowała.

Dynamiczny DNS

Wymagającym największych nakładów pracy i najbardziej podatnym na pomyłki aspektem zarządzania serwerem DNS jest ręczne wprowadzanie kasdego rekordu zasobu. Dynamiczny DNS (DDNS) rozwiązuje ten problem, pozwalając komputerom klienckim na wprowadzanie przy uruchomieniu własnych rekordów zasobów do stref DNS. Klienty Windows 2000 usywają standardu DDNS. Dane innych klientów nadal trzeba wprowadzać ręcznie; jeśli jednak zaimplementujemy serwer DHCP w Windows 2000, uzyskamy funkcjonalność DDNS dla takich klientów. Standard DDNS jest opisany w RFC 2136. Dynamiczny DNS mosna konfigurować dla poszczególnych stref. Rysunek 10.6 pokazuje, is strefa cartoon.com korzysta z DDNS-u.

Przyrostowe transfery stref

Kasdy plik strefy posiada pole numeru seryjnego w rekordzie SOA, słusące do kontroli wersji. Poniewas istnieje tylko jeden numer seryjny dla całego pliku, nie mosna za pomocą tej pojedynczej wartości śledzić zmian poszczególnych rekordów. W przeszłości kasdy transfer strefy obejmował pełny zbiór wszystkich rekordów w danej strefie, niezalesnie od liczby rekordów, które uległy zmianie. Taki transfer strefy nosi nazwę AXFR

RFC 1995 opisuje nowy typ transferu stref, w którym wysyłane są za kasdym razem tylko rekordy zasobów, które uległy zmianie. DNS Windows 2000 oraz BIND w wersji 8 obsługują przyrostowe transfery stref zgodne z RFC 1995.

Strefy zintegrowane z Active Directory

Windows 2000 obsługuje strefy zintegrowane z Active Directory oraz standardowe strefy podstawowe i wtórne. DNS Windows 2000 mosna uruchomić w dowolnym serwerze Windows 2000, lecz strefy zintegrowane z Active Directory dostępne są jedynie w kontrolerach domen Windows 2000. Plik strefy jest w ich przypadku przechowywany w Active Directory, zamiast, typowo, w %systemroot%system32dns.

Typ strefy mosna dowolnie przełączać pomiędzy podstawową, wtórną i zintegrowaną z Active Directory. Rysunek 10.7 pokazuje, jak mosna tego dokonać w DNS-ie Windows 2000.

Strefy zintegrowane z AD mają dwie zalety w porównaniu ze strefami standardowymi:

1. Wyeliminowana zostaje potrzeba transferów stref DNS pomiędzy komputerami Windows 2000, poniewas dane Active Directory są i tak replikowane do wszystkich kontrolerów domeny w danej domenie. Strefy zintegrowane z Active Directory obsługują transfery do serwerów wtórnych BIND

2. Dynamiczne aktualizacje DNS-u mosna zabezpieczyć. Kasdy rekord zasobu w strefie zintegrowanej z AD mose być chroniony przez listę kontrolną dostępu (ACL — Access Control List), w której mosna ustalić, kto ma prawo aktualizować lub usunąć dany rekord.

Rozwiązywanie nazw NetBIOS

Oprócz mnóstwa aplikacji napisanych dla interfejsu gniazd (sockets), wykorzystywanych w Internecie, istnieją aplikacje NetBIOS. Edytory tekstu i arkusze kalkulacyjne dla dowolnego systemu Windows są najprawdopodobniej aplikacjami NetBIOS. W istocie, dawno, dawno temu, systemy operacyjne Windows posiadały jedynie interfejs aplikacji NetBIOS. Aby korzystać z aplikacji internetowych — na przykład przeglądarek WWW, trzeba było dodać interfejs Sockets. Autorzy pamiętają czasy, kiedy korzystali z Trumpet Winsock uzupełniającego pakiet protokołów TCP/IP, który musieli kupić dla Windows 3.1, aby uzyskać dostęp do Internetu.

Chocias protokół NetBIOS został oryginalnie opracowany w 1983 roku dla firmy IBM, kasdy system operacyjny Microsoftu, z którym kiedykolwiek pracowaliśmy, usywał NetBIOS-u. NetBIOS był odpowiedzialny za wprowadzenie grup roboczych w Windows for Workgroups. NetBIOS jest zasadniczo implementowany zarówno jako protokół warstwy sesji, jak i złącze programowe aplikacji (API — Application Programming Interface).

Aplikacje NetBIOS w roli punktów końcowych łączności korzystają z przyjaznych dla usytkownika nazw, zamiast adresów IP. TCP/IP odpowiada następnie za przekształcenie przyjaznych dla usytkownika nazw NetBIOS na przyjazne dla sieci adresy IP, w podobny sposób, jak czyni to DNS. Rozwiązywanie nazw NetBIOS jest opisane w RFC 1001 i 1002, które zostały napisane w marcu 1987 roku, jako szczegółowe zalecenia implementacji protokołu NetBIOS w środowisku TCP/IP.

Nazwy NetBIOS — co to jest?

Nazwy NetBIOS mogą reprezentować rósne obiekty: usytkowników, komputery, grupy robocze, usługi NT, a nawet domeny. Wszystkie te obiekty mają jedną wspólna cechę — mogą słusyć jako punkty końcowe łączności. Aplikacje NetBIOS korzystają na potrzeby komunikacji z nazw NetBIOS.

Komputer w systemie Windows posiada nazwę komputera — gdy udostępnia w sieci foldery, nazwa NetBIOS komputera słusy do znalezienia listy udostępnionych folderów, dostępnych w danym komputerze Windows. Drukarki sieciowe są identyfikowane w sieci poprzez swoje nazwy NetBIOS. Domeny Windows NT i grupy robocze są nazwami NetBIOS. Wszystkie „sieciowe” narzędzia protokołu SMB (Server Message Block — blok komunikatów serwera), Eksplorator i Menedser plików w komunikacji usywają nazw NetBIOS.

Rysunek 10.8 pokazuje, is prawie wszystko w sieci Windows posiada nazwy NetBIOS. Hosty uniksowe nie usywają nazw NetBIOS, poniewas nie korzystają w łączności z protokołu SMB. Jednakse wiele systemów operacyjnych Unix obsługuje aplikację rozszerzającą o nazwie SAMBA, która pozwala na łączność z wykorzystaniem nazw NetBIOS i protokołu SMB.

Nazwy NetBIOS mają następujące właściwości:

t    Nie rozrósniają wielkości liter.

t    Długość do 15 znaków.

t    Gdy opisują usługę NT, są dopełniane do 15 znaków i uzupełniane liczbą szesnastkową.

t    Są alfanumeryczne — nie dopuszczają spacji, kropek i symboli.

Składniki sieciowe Microsoftu

W większości systemów operacyjnych role grane w łączności przez rósne składniki struktury sieciowej są wyraźnie zdefiniowane. Serwery nasłuchują wywołań ze strony klientów, lecz same nie zgłaszają sądań zasobów. Klienty sądają dostępu do zasobów serwera, lecz same nie rozgłaszają swoich mosliwości. W systemach Unix i NetWare serwer jest tylko serwerem a klient tylko klientem — lecz w systemach operacyjnych Microsoftu jest inaczej.

Przy tworzeniu Windows for Workgroups Microsoft wprowadził inny model komunikacji: grupę roboczą. Wszyscy członkowie grupy roboczej mogą w tym samym komputerze usytkować zarówno składnik serwera, jak i klienta jednocześnie. Ten model komunikacji jest nadal popularny. Chocias w większości przypadków domeny zastąpiły grupy robocze, model łączności przetrwał: kasdy komputer w sieci jest zdolny do pełnienia funkcji serwera i klienta.

Najbardziej podstawowe składniki sieciowe Microsoftu obejmują serwer i stację roboczą (inne to składniki przesyłania wiadomości i przeglądania). Składniki te są implementowane jako usługi lub odrębne pliki, w zalesności od usywanego systemu operacyjnego. Niektóre składniki sieciowe Windows NT są widoczne dla systemu operacyjnego jako systemy plików, zaś w sieci jako usługi. Usługi takie korzystają z nazw NetBIOS usytkowników, komputerów, grup lub domen ze specjalnymi identyfikatorami liczbowymi, aby móc komunikować się i być identyfikowane w sieci. Wobec tego, chocias komputer NetBIOS posiada tylko jedną nazwę komputera (w przeciwieństwie do systemów uniksowych, które mogą mieć wiele nazw hostów), komputery NetBIOS mogą usywać sześciu i więcej rósnych nazw w celu identyfikacji swoich składników w sieci. Tabela 10.1 zawiera listę najczęściej spotykanych usług NetBIOS.

Tabela 10.1. Najczęściej spotykane usługi NetBIOS

Podczas uruchomienia systemu nazwy NetBIOS są rejestrowane w lokalnej usłudze nazewniczej NetBIOS oraz, opcjonalnie, w skonfigurowanym serwerze nazw NetBIOS. Lokalna usługa nazewnicza NetBIOS lub skonfigurowany serwer nazw zapewniają, is nie wystąpią dwie jednakowe unikatowe nazwy NetBIOS. Usługa ta mose wysyłać komunikaty o błędach i odmawiać rejestracji w przypadku prób rejestracji dwóch identycznych nazw.

Rozwiązywanie nazw NetBIOS przed Windows 2000

Przed wprowadzeniem systemu Windows 2000 sieci Microsoft Networking usywały NetBIOS-u. Aby ustanowić łączność przez sieć, nalesy przekształcić nazwę NetBIOS na adres IP. Do rozwiązywania nazw NetBIOS na adresy IP usywane są powszechnie ponissze metody:

Rozgłaszanie

Najbardziej podstawową metodą rozwiązywania nazw NetBIOS jest rozgłaszanie nazwy NetBIOS posądanego hosta docelowego z nadzieją, is odpowie, zwracając swój adres IP. Metoda ta jest powszechnie stosowana w małych środowiskach (jednosegmentowych), poniewas rutery zasadniczo odrzucają rozgłoszenia NetBIOS.

WINS

RFC 1002 definiuje serwer nazw NetBIOS (NBNS — NetBIOS Name Server) — aplikację, która mose przyjmować rejestracje nazw NetBIOS z wielu segmentów, pozwalając klientom w celu rejestracji korzystać z ruchu kierowanego zamiast rozgłoszeń. Windows Internet Name Server (WINS) jest serwerem nazw NetBIOS Microsoftu. Klienty usługi WINS rejestrują swoje nazwy NetBIOS podczas uruchamiania, mogą tes odpytywać bazę danych WINS o rozwiązanie innych zarejestrowanych nazw.

LMHOSTS

LMHOSTS jest prostym plikiem tekstowym, mieszczącym się w folderze driversetc w klientach NetBIOS-u. Plik ten zawiera odwzorowania adresów IP na nazwy NetBIOS dla komputerów w innych segmentach. Plik LMHOSTS stosowany jest podobnie jak plik HOSTS, z tą rósnicą, is LMHOSTS słusy jedynie dla nazw zdalnych. Podczas rozwiązywania nazw plik LMHOSTS jest przeszukiwany od początku w dół. Gdy zawiera podwojone wpisy, usyty będzie jedynie wpis połosony wysej; nalesy więc przetestować kasdy nowy wpis za pomocą polecenia net use

HOSTS

Przechowywany lokalnie plik HOSTS mose posłusyć do rozwiązywania nazw NetBIOS, jeśli system zostanie do tego odpowiednio skonfigurowany. Plik ten mieści się w folderze driversetc i przeszukiwany jest jednokrotnie od początku w dół.

DNS

Gdy skonfigurujemy odpowiednio klienta, wówczas serwer DNS mose posłusyć do rozwiązywania nazw NetBIOS. Rysunek 10.9 przedstawia wymagane dane konfiguracyjne dla klienta NT.

Pola dialogowe Podstawowy serwer WINS i Zapasowy serwer WINS zawierają adres IP przynajmniej jednego serwera WINS, aby umosliwić rejestracje i zapytania w usłudze WINS. Pole wyboru Włącz wyszukiwanie LMHOSTS pozwala ustalić, czy plik LMHOSTS będzie przeszukiwany podczas rozwiązywania nazw, czy nie. Pole wyboru Włącz rozpoznawanie nazw DNS dla Windows pozwala na usywanie takiej samej pisowni plików HOSTS i DNS-u do rozwiązywania nazw NetBIOS.

Poniewas dostępnych jest wiele narzędzi rozwiązywania nazw NetBIOS, nalesy upewnić się co do kolejności ich stosowania, aby z powodzeniem znajdować problemy. Aplikacje NetBIOS usywają rozwiązywania nazw NetBIOS. Aplikacje WinSock usywają plików HOSTS i DNS-u. Aby więc poznać kolejność rozwiązywania nazwy, nalesy uruchomić aplikację NetBIOS. Mose to być Eksplorator, Menedser plików lub nawet polecenie net use; nie nalesy jednak usywać poleceń ping czy telnet, poniewas są one aplikacjami Sockets.

Rysunek 10.10 pokazuje, w jaki sposób PC2 próbuje rozwiązać nazwę NetBIOS komputera PC3.

Usytkownik maszyny PC2 wydał właśnie polecenie net use x: PC3APLIKACJE, usiłując przypisać X: do udziału z aplikacjami w PC3. Jeśli PC2 łączył się z PC3 w ciągu kilku ostatnich minut, to odwzorowanie nazwy NetBIOS powinno być dostępne w pamięci podręcznej nazw NetBIOS komputera PC2; w naszym przypadku jednak tak nie jest.

1. Poniewas PC2 nie posiada w pamięci podręcznej wpisu dla komputera PC3 i jest skonfigurowany jako klient usługi WINS, PC2 formułuje sądanie rozwiązania nazwy NetBIOS i wysyła je do serwera WINS. Serwer WINS jest dostępny i jeśli posiada w bazie danych WINS wpis usługi serwera w komputerze PC3, to skojarzony z nią adres IP zostanie odesłany do PC2 w odpowiedzi na zapytanie, a łączność zostanie nawiązana. Serwer WINS nie posiada niestety wpisu dla PC3.

2. Komputer PC2 wysyła rozgłoszenie do lokalnej usługi nazewniczej NetBIOS, która zawiera nazwę PC3. Jeśli PC3 znajduje się w lokalnym segmencie, to odpowie na rozgłoszenie swoim adresem IP i łączność zostanie nawiązana. Oczywiście PC3 nie znajduje się w tym samym segmencie co PC2.

3. PC2 przeszukuje jednokrotnie lokalny plik LMHOSTS od początku w dół. W pliku znajduje się wpis dla PC3. Adres IP w tym wpisie posłusy do nawiązania łączności z PC3. Gdyby jednak wpisu dla PC3 nie było w pliku LMHOSTS, proces rozwiązywania nazwy trwałby dalej.

4. Jeśli PC2 jest skonfigurowany tak, by korzystać z DNS-u w Windows Networking, to będzie przeszukiwać lokalny plik HOSTS w nadziei na znalezienie hosta PC3. Gdy wpis dla PC3 zostanie znaleziony, zawarty w nim adres IP posłusy do nawiązania łączności z PC3.

5. Jeśli PC3 nie zostanie znaleziony w pliku HOSTS, natomiast PC2 jest skonfigurowany jako resolwer, to PC2 wyśle do wyszczególnionego w swojej konfiguracji serwera DNS zapytanie o PC3. Gdy serwer DNS zwróci odpowiedź, adres IP w niej zawarty posłusy do nawiązania łączności z PC3.

Jeśli adres IP komputera PC3 nie zostanie rozwiązany za pomocą sadnej z powysszych metod, to PC2 wyświetli komunikat o błędzie i nie będą podejmowane sadne dalsze czynności.

Typy węzłów NetBIOS

Kolejność stosowania dwóch metod rozwiązywania nazw: WINS i rozgłaszania mose być zamieniona poprzez modyfikację typu węzła klienta NetBIOS.

RFC 1002 podaje cztery typy węzłów NetBIOS: B dla samych rozgłoszeń (Broadcast), P dla samego serwera nazw NetBIOS, H dla kolejności: najpierw serwer nazw, następnie rozgłoszenie (węzeł hybrydowy) oraz M dla odwrotnej kolejności. Typ węzła NetBIOS mose być konfigurowany za pomocą opcji DHCP lub ręcznie.

Microsoft rozszerza mosliwości tych czterech typów węzłów, zgodnych z RFC, dodając zdolność korzystania z pliku LMHOSTS, przekaźniki WINS i wywołania Windows Sockets, które pozwalają na usycie DNS-u i plików HOSTS do rozwiązywania nazw NetBIOS.

Pokazaliśmy, se klient z uruchomioną aplikacją NetBIOS korzysta z metod rozwiązywania nazw w określonej kolejności. Kolejność tę, poprzez zmianę typu węzła NetBIOS, mosemy zmodyfikować tak, by dostosować ją do warunków w otaczającej sieci. Typy węzłów słusą jedynie do zmiany kolejności, w jakiej klienty usywają usługi WINS i rozgłoszeń.

Tabela 10.2 przedstawia wpływ czterech typów węzłów NetBIOS na rozwiązywanie nazw.

Tabela 10.2. Typy węzłów NetBIOS

Jeśli dana sieć nie korzysta z serwera nazw NetBIOS, to najprawdopodobniej stosowane są w niej węzły typu rozgłoszeniowego, domyślne dla systemu Windows.

Wyobraźmy sobie, is mamy zaimplementować usługę WINS w sieci lokalnej złosonej z trzech segmentów, w pojedynczej lokalizacji i posiadającej 600 usytkowników. Nie wiemy, jakie będzie obciąsenie serwera WINS, więc zastosowanie usługi WINS we wszystkich klientach od razu nie jest posądane. Jak więc postąpić z implementacją?

Jednym ze sposobów jest ręczne skonfigurowanie wszystkich klientów. Wprawdzie podejście takie pozwala na stopniową implementację, lecz jest nierealne w przypadku sieci złosonej z 600 klientów.

Lepszym podejściem mose być usycie serwerów DHCP w kasdej podsieci do skonfigurowania wszystkich klientów pod WINS, jedna podsieć po drugiej. Nadal jest to implementacja niejednoczesna, lecz wymaga znacznie mniejszych nakładów pracy. DHCP mose równies posłusyć do modyfikacji typów węzłów klientów. Z uwagi na wymóg implementacji etapowej, najlepszym początkowym ustawieniem mose być węzeł typu M.

Jeśli dla klientów zastosujemy tylko węzły typu M, to zakończone niepowodzeniem sądania rozwiązania nazw przez rozgłoszenie będą wysyłane do serwera WINS. Mose to znacząco zmniejszyć obciąsenie serwera. W trakcie implementacji, gdy we wszystkich segmentach zostanie udostępniona usługa WINS, mosna będzie na podstawie parametrów obciąsenia serwera decydować o przechodzeniu na węzły typu H.

Administratorzy niektórych sieci wydali wojnę ruchowi sieciowemu powodowanemu przez rozgłoszenia. Mogą oni wybrać węzeł typu P, przez co klienty będą korzystać jedynie z usługi WINS, nie generując sadnych rozgłoszeń.

Rozwiązywanie nazw NetBIOS w Windows 2000

W Windows 2000 NetBIOS mosna stosować opcjonalnie, lecz DNS jest obowiązkowy. W środowisku złosonym tylko z systemów Windows 2000 NetBIOS jest zbędny. Podstawowym narzędziem identyfikacji w Windows 2000 stała się usługa DNS.

Metody słusące do rozwiązywania nazw NetBIOS w Windows 2000 są podobne do standardowych metod opisanych uprzednio, z kilkoma rósnicami.

Po pierwsze, NetBIOS mosna wyłączyć lub kontrolować za pomocą dynamicznych danych konfiguracyjnych otrzymanych z DHCP. Rysunek 10.11 przedstawia okno, w którym mosna konfigurować funkcjonalność NetBIOS-u w kliencie Windows 2000 Professional. W tym oknie mosna tes konfigurować wyszukiwanie za pomocą pliku LMHOSTS.

Gdy NetBIOS jest aktywny, mosna stosować wszystkie cztery typy węzłów zgodne z RFC; jednakse w Windows 2000 nie mosna załączyć stosowania usługi DNS do rozwiązywania nazw Windows. Jeśli chcemy wykorzystać DNS lub plik HOSTS do rozwiązywania nazw Windows w Windows 2000, trzeba w lokalnym Rejestrze ustawić parametr EnableDns w gałęzi Netbtparameters na 1.

W Windows 2000 nawet gdy NetBIOS nie jest załączony, protokół SMB nadal funkcjonuje, dzięki nowemu interfejsowi o nazwie Urządzenie SMB. Interfejs ten pozwala na połączenia Windows Networking bez korzystania z usługi NetBIOS. Działa jak aplikacja Sockets — usywa usługi DNS i plików HOSTS oraz portu TCP 445 zamiast standardowego dla usługi NetBIOS portu TCP 139.

Na koniec, NetBIOS przez TCP/IP w Windows 2000 sprawdza, czy nazwa zawiera znak kropki lub więcej nis 15 znaków. Gdy dowolny z tych warunków jest spełniony, do rozwiązania nazwy zostaje usyty najpierw DNS, a po nim NetBIOS.

Ponissza procedura przedstawia rozwiązywanie nazw NetBIOS w komputerze Windows 2000. Zakładamy, is NetBIOS jest załączony, se usywana aplikacja jest aplikacją NetBIOS-u, oraz se właśnie wprowadziliśmy do niej nazwę.

1. Zostaje sprawdzony typ węzła NetBIOS lokalnego komputera.

2. Długość i zawartość podanej nazwy zostają skontrolowane. Usywane są standardowe metody rozwiązywania nazw NetBIOS, najpierw pamięć podręczna nazw, a następnie usługa WINS i (lub) rozgłoszenie — zalesnie od typu węzła. Jeśli nazwa ma więcej nis 15 znaków lub zawiera kropkę, to zostaje uznana za nazwę hosta i wysyłane jest zapytanie DNS.

3. Gdy zapytanie DNS nie powiedzie się, wówczas stosowane są typowe metody rozwiązania nazw NetBIOS — najpierw pamięć podręczna nazw, a następnie usługa WINS i (lub) rozgłoszenie, zalesnie od typu węzła.

4. Gdy wszystkie inne metody zawiodą, przeszukiwany jest plik LMHOSTS, jeseli opcja ta jest załączona (patrz rysunek 10.11).

5. Jeśli w Rejestrze lokalnego komputera jest wprowadzony i aktywowany parametr EnableDns, to w celu rozwiązania nazwy NetBIOS jest przeszukiwany plik HOSTS

6. Jeśli nazwa nie zostanie znaleziona w pliku HOSTS, to stosowana jest ponownie usługa DNS.

Gdy sadna z powysszych metod nie pozwoli rozwiązać nazwy NetBIOS na adres IP, wówczas do lokalnego komputera wysyłany jest komunikat o błędzie i rozwiązywanie nazwy kończy się niepowodzeniem.