Rozdział 7

Ustalenie struktury DNS

Po zgromadzeniu informacji o przedsiębiorstwie, opisanych w rozdziale 6, można już zagłębić się w podstawowe zadania projektowe. Pierwszą częścią fazy projektowej jest kwestia nazw — czyli ustalenie, jak powinien wyglądać schemat nazewniczy DNS domen Active Directory. Oprócz wyboru właściwych nazw oraz, być może, zarysowania konwencji nazewniczych, proces przydzielania nazw obejmuje podjęcie decyzji, czy nazwy w Internecie i intranecie przedsiębiorstwa powinny być takie same, jak zapewnić redundancję dającą wytrzymałość i rozkład obciążenia przy rozwiązywaniu nazw, jaką utworzyć strukturę replikacji nazw, oraz jak uporać się z kilkoma zagadnieniami współoperatywności. Podjęcie wszystkich tych decyzji wymaga zrozumienia zawiłości standardu systemu nazw domen (DNS – Domain Name System), którego Active Directory używa w roli usługi lokalizacyjnej.

W trakcie pracy z tym rozdziałem Czytelnik przekona się, iż wybór właściwych nazw jest najmniejszym problemem w procesie nadawania nazw. Przy określaniu standardów nazewniczych zrozumienie usługi DNS jest chyba największym wyzwaniem dla osób, których doświadczenie zawodowe ogranicza się do komputerów osobistych. Szacując według naszej wiedzy, większość czytelników dysponuje właśnie takim doświadczeniem, dlatego też bieżący rozdział zaczyna się od sporego działu poświęconego podstawom usługi DNS. Czytelnik znający już DNS może przekartkować tę sekcję, służącą jako wprowadzenie do DNS-u.

Uwaga

Wprowadzenie do DNS-u zawiera informacje o dynamicznym DNS-ie (DDNS) i innych nowych standardach, z których korzysta Active Directory — wobec czego odradzam całkowite pominięcie tego podrozdziału, niezależnie od posiadanego już doświadczenia z usługami DNS.

Jednakże usilnie zalecam dokładną ocenę własnych umiejętności w dziedzinie DNS-u przed podjęciem decyzji o całkowitym pominięciu wprowadzenia do tej usługi, ponieważ DNS stanowi nader subtelną sztukę, która nie jest zbyt dobrze rozumiana nawet przez najbardziej rezolutnych użytkowników Uniksa. W istocie jeden z głównych powodów, dla których trudno jest opanować DNS jest tym samym, który czyni wyzwanie z Active Directory: DNS stanowi hierarchiczną przestrzeń nazw. Chociaż DNS jest sztuką trudną do opanowania, nie jest to absolutnie niemożliwe.

Uwaga

Warto zwrócić uwagę, iż bieżący rozdział zawiera również omówienie podstawowych właściwości usługi WINS, ponieważ doświadczenie autora w rzeczywistych scenariuszach pokazało, że uniknięcie obecności w infrastrukturze sieci jakiejkolwiek funkcjonalności rozwiązywania nazw NetBIOS jest niemożliwe. Wobec tego czytelnik będzie najprawdopodobniej zmuszony zaimplementować ten okropny wynalazek, chyba że woli spróbować szczęścia z dystrybucją wśród hostów plików LMHOSTS.

Przykład ustawień usługi DNS w Active Directory

Microsoft zdecydował aby zaprząc DNS do pracy w roli usługi lokalizacyjnej Active Directory. W systemie Windows 2000 Server nazwami domen Active Directory są nazwy DNS. Wynika stąd, że te same proste konwencje nazewnicze, co używane w Internecie, stosują się do Active Directory. Jeśli, na przykład, astonitgroup.com jest nazwą domeny Active Directory, będzie też nazwą domeny DNS (takie są ustawienia domyślne; nazwa domeny i nazwa DNS nie muszą jednak być takie same). Odpowiednio, JamesSmith@astonitgroup.com może być zarówno internetowym adresem poczty elektronicznej, jak nazwą użytkownika w domenie astonitgroup.com.

DNS jest narzędziem pozwalającym na rozwiązywanie nazw domen Active Directory i hostów w domenie na ich adresy TCP/IP, które tworzą „język ojczysty” podstawowej infrastruktury sieci, wobec czego niezbędne są do nawiązywania połączeń sieciowych z Active Directory. Chociaż można by wobec tego znacząco zaoszczędzić na złożoności, używając od samego początku adresów TCP/IP, takie rozwiązanie prowadziłoby donikąd pod względem użyteczności. Przeciętni użytkownicy sieci zazwyczaj nie rozumieją — i co jeszcze ważniejsze, nie są w stanie zapamiętać — adresów TCP/IP potrzebnych im usług, podczas gdy najprawdopodobniej zapamiętają nazwę, zależnie od złożoności i znajomości schematu nazewniczego.

Najważniejszym pojedynczym zastosowaniem usługi DNS (patrz rysunek 7.1) jest rozwiązanie nazwy domeny Active Directory i idąca za tym identyfikacja serwera usługi katalogowej, obsługującego daną domenę. Przykładem może być logowanie się przez sieć do Active Directory klienta zgodnego z Active Directory (proces NetLogon), które przebiega następująco:

1. Sieciowa część procesu NetLogon zaczyna od odpytania usługi DNS o rekordy SRV (wskazujące na kontrolery domen które obsługują żądany katalog) dla określonej domeny Active Directory, w tej samej lokacji co klient. Jeśli klient chce zarejestrować się w domenie astonitgroup.com w lokacji London, zapytanie zażąda rekordów SRV dla _ldap._tcp._london._sites.dc._msdcs.astonitgroup.com, przechowywanych w serwerze DNS.
2. Po otrzymaniu listy serwerów DC obsługujących domenę astonitgroup.com w lokacji London, klient wybiera z listy serwer i usiłuje skontaktować się z nim, pobierając adres IP z rekordu A (adresu) usługi DNS dla docelowego serwera.
3. Kontroler domeny z którym nawiązano kontakt korzysta z dostarczonych przez klienta informacji o podsieci, aby znaleźć DC najbliżej stacji roboczej (co jest definiowane za pomocą pojęcia lokacji Active Directory). Jeśli bieżący DC nie znajduje się w tej lokacji, serwer powiadamia klienta o lepszym DC, z którego można skorzystać.

Rysunek 7.1

Wyszukiwanie DNS stanowi część wielu różnorodnych procesów, jak np. NetLogon

Od tego momentu proces przebiega rutynowo (to znaczy, niemal identycznie jak dla NetLogon w Windows NT Workstation 4), finalizując uwierzytelnienie klienta w domenie. Jednak można tu znaleźć różnice. Na przykład, klient loguje się korzystając z protokołu Kerberos a nie NTLM, klient synchronizuje swój zegar z serwerem, zaś usługa Active Directory jest odpytywana o GPO za pomocą mechanizmów LDAP (w rozdziale 20 różne etapy procesu rejestracji omówione są bardziej szczegółowo).

Jak widać, funkcjonalność wymagana przez proces NetLogon (oraz wiele innych procesów, które podobnie potrzebują dostępu do DC obsługującego określoną domenę Active Directory) polega na rejestracji — przez kontrolery domen (DC) Windows 2000 Server — w usłudze DNS jednego lub więcej rekordów SRV razem z typowym rekordem A i PTR (więcej informacji o tych rekordach w podrozdziale „Format standardowego rekordu zasobu”)

Rejestracja taka dokonywana jest automatycznie, jeśli dany serwer DNS obsługuje nowy standard dynamicznego DNS-u. W przeciwnym razie administrator serwera DNS musi ręcznie dodawać i aktualizować rekordy. Co gorsza, dotyczy to wszystkich klientów w sieci, korzystających z Active Directory. Każdy klient musi być obecny w tablicy DNS w postaci rekordu typu A oraz typu PTR (to znaczy, do wyszukiwania w przód i wstecz), specyfikuj

ącego odwzorowanie nazwy DNS klienta na adres IP i vice versa. Sam ten fakt powinien stanowić nader wymowny argument za stosowaniem we współpracy z Active Directory jedynie serwerów DNS obsługujących DDNS. Wszelkie bieżące zmiany adresów IP zasobów sieciowych wymienionych w tablicy DNS będą aktualizowane automatycznie, jeśli zastosujemy serwer DHCP Microsoftu, korzystając równocześnie z serwerów DDNS.

Od usługi WINS do DDNS

Chociaż sieć wygląda dziś całkiem inaczej niż 10 lat temu, podejście Microsoftu do systemów sieciowych od wprowadzenia pierwszego swojego sieciowego systemu operacyjnego (LAN Manager) w roku 1987 zmieniło się w zaskakująco niewielkim stopniu — aż do wprowadzenia systemu Windows 2000 Server.

Gdy LAN Manager był wprowadzany do użytku, NetBIOS i NetBEUI stanowiły najnowszy krzyk mody. O ile NetBEUI w latach 90-tych spotykał się z rosnącą opozycją, co zostało uwieńczone przejściem na TCP/IP w ustawieniach domyślnych NT 4, NetBIOS trzymał się mocno — jak dotąd.

W Windows 2000 Server Microsoft obrócił NetBIOS w rozwiązanie wycofywane, na korzyść czystego rozwiązania TCP/IP, opartego na znanych standardach DHCP i DNS — co w wyniku wyeliminowało potrzebę stosowania własnego rozwiązania Microsoftu, Windows Internet Naming Service (WINS), ponieważ WINS jest usługą nazewniczą zaprojektowaną dla komputerów łączących się za pomocą NetBIOS-u przez TCP/IP. Wobec tego, jeśli czytelnik posiada doświadczenie z systemem NT 4 Server, znajomość usługi WINS stanie się przestarzała w chwili przejścia na Active Directory (ironicznie, Windows 2000 Server zawiera nową i znacznie udoskonaloną wersję usługi WINS, z której można korzystać dla celów kompatybilności wstecz). Jednakże nie są to chyba złe nowiny, ponieważ WINS posiada kilka wad — przez co czas spędzony na poznanie DNS-u będzie dobrze wykorzystany:

·       WINS jest prywatną technologią Microsoftu, DNS — nie.

·       WINS zarobił sobie na ustaloną opinię usługi raczej zawodnej w dużych środowiskach, gdzie też nie jest łatwy do zarządzania i trudno w nim wykrywać problemy, co bierze się głównie z tego, iż został pierwotnie zaprojektowany w celu implementacji przyjaznych dla użytkowników nazw w małych sieciach lokalnych.

·       Narzędzia replikacji usługi WINS nie zawierają nawet żadnych prawdziwych mechanizmów zabezpieczających (na przykład chroniących przed nieautoryzowanymi serwerami WINS).

·       Z nadejściem Internetu większość administratorów i tak wprowadziła usługi nazewnicze DNS w swoich sieciach lokalnych.

Wskazówka

Doświadczenia polowe wykazały, iż NetBIOS jednak nie umarł ze szczętem. Przyczyna jest równie prosta co irytująca: Microsoft najwyraźniej zapomniał w kilku miejscach usunąć zależności Windows 2000 od usługi NetBIOS. Wobec tego należy pozostawić architekturę WINS na swoim miejscu, aby uniknąć wszelkich nieszczęśliwych niespodzianek.

DNS został od początku zaprojektowany z myślą o wysokiej wydajności i stabilnym działaniu w dużych sieciach. Na przykład, hierarchiczna przestrzeń nazw DNS zapewnia najlepszy możliwy punkt wyjścia dla wyszukiwania i zapewnia, iż nazwy są unikalne w skali globalnej, mimo jedynie lokalnej kontroli. Hierarchiczna przestrzeń nazw daje ponadto do wyboru o wiele bardziej różnorodny świat nazw, niż czyni to usługa WINS, ograniczająca nazwę do 15 znaków w całkowicie płaskiej przestrzeni nazw — niezależnie od ilości hostów.

DNS zawiera cechy funkcjonalne pozwalające na implementację zdecydowanie większej odporności na uszkodzenia niż jest to możliwe w przypadku WINS. Co więcej, DNS zawiera większy wybór bardziej zaawansowanych i elastycznych opcji konfiguracji, co umożliwia o wiele bardziej precyzyjne dostosowanie zarządzania, funkcjonowania i bezpieczeństwa do potrzeb organizacji.

DNS posiada ogólnie rzecz biorąc tylko cztery cechy niekorzystne — oraz szeroki zakres znaczących zalet, szczególnie na potrzeby dużych środowisk sieciowych, w porównaniu z usługą WINS i NetBIOS-em:

§         Nazwy DNS mogą być nieco trudniejsze do zrozumienia dla przeciętnego użytkownika, ponieważ składają się z kilku części i wykorzystują znaki oddzielające (kropki). Gwałtowny rozwój Internetu zdecydowanie zmniejszył jednak ten problem, ponieważ użytkownicy regularnie stykają się z nazwami DNS.

§         DNS nie posiada znormalizowanych zdolności rejestrowania w tablicy nazw usług sieciowych, poza serwerami pocztowymi. Jednakże ten niedostatek został rozwiązany za pomocą proponowanego rozszerzenia DNS (opisanego w RFC 2052), wyszczególniającego nowy typ rekordu zasobu (RR).

§         DNS nie posiada zdolności przekazywania aktualizacji z serwerów podstawowych DNS do wtórnych w przypadku zmian w tablicy nazw. DNS zezwala jedynie na zdefiniowanie serwerów wtórnych pobierających z własnej inicjatywy dane składowane w serwerze podstawowym, w określonych odstępach czasu. Niedociągnięcie to zostało usunięte za pomocą proponowanego rozszerzenia, DNS NOTIFY (powiadamianie), opisanego w RFC 1996.

§         DNS jest ograniczony do nazw statycznych, co oznacza że nazwy wszystkich zasobów sieciowych (serwery itp.) muszą zostać ręcznie wprowadzone przez administratora. Idea taka jest realna jedynie w sytuacjach, gdy najwyżej od czasu do czasu występuje niewielka ilość zmian. Tym niedociągnięciem również zajmuje się proponowane rozszerzenie — dynamiczny DNS (udokumentowany w RFC 2136 i 2137)

Wprowadzenie do Systemu Nazw Domen

System nazewniczy DNS można zazwyczaj znaleźć funkcjonujący w każdej „czystej” sieci TCP/IP (na przykład w sieciach, w których stosowane są systemy uniksowe). Nazwy DNS zasadniczo działają tak samo, jak nazwy NetBIOS. Podobnie jak nazwy NetBIOS, nazwy DNS służą do identyfikacji zasobów dostępnych w sieci w sposób bardziej przyjazny dla użytkownika niż adresy IP (które mają zawsze format x1.x2.x3.x4

O ile wiem, IP może być zapisany dowolnie.

, gdzie x1 do x2 to liczby całkowite w zakresie od 0 do 255 określające adres, np. 10.1.4.1). Żądanie dostępu do serwera z użyciem nazwy zamiast numerycznego adresu sieciowego jest o wiele łatwiejsze, ponieważ użytkownicy zwykle nie rozumieją i nie są w ogóle zaznajomieni z adresem sieciowym. Czytelnik prawdopodobnie zna już nazwy DNS, ponieważ używane są w sieci stron WWW — na przykład, www.microsoft.com czy www.coriolis.com

www.helion.com.pl?

.

DNS jest powszechnie znanym i akceptowanym standardem internetowym w dziedzinie nazywania i rejestracji zasobów, którego można również używać w prywatnych sieciach opartych na TCP/IP. Nazwy DNS są tworzone w sposób nieco odmienny od nazw NetBIOS, ponieważ świat NetBIOS jest płaski jak naleśnik

Idiomatycznie: „płaski jak stół” ale naleśnik lepiej brzmi...

, podczas gdy DNS jest hierarchiczną przestrzenią nazw. Nazwy komputerów w DNS-ie składają się z kilku części (inaczej poziomów), oddzielonych od siebie kropkami.

Na przykład, przy nazywaniu komputerów nazwy NetBIOS są ograniczone do faktycznej nazwy komputera (lub nawet jej skrótu, ponieważ w NetBIOS-ie długość nazwy jest ograniczona do 15 znaków), podczas gdy nazwy DNS składają się z dwóch części: nazwy komputera (zwanej nazwą hosta, host name) oraz nazwy domeny. W połączeniu te dwie części nazwy DNS tworzą pełną złożoną nazwę domeny (FQDN – fully qualified domain name). Przykładem FQDN jest ntbeta.microsoft.com, gdzie ntbeta to nazwa komputera a domena nosi nazwę microsoft.com.

Jak wspomniano, sieć witryn WWW (między innymi) jest oparta o nazwy DNS. Oznacza to na przykład, iż jeśli wpiszemy w przeglądarce WWW adres URL http://www.astonitgroup.com, przeglądarka potraktuje URL jako zapytanie o nazwę DNS. Zapytanie to szukać będzie komputera o nazwie www, położonego w domenie astonitgroup.com. Po znalezieniu serwera DNS w którym komputer jest zarejestrowany, serwer ten zwraca adres IP do przeglądarki, która może go wówczas użyć aby połączyć się z serwerem WWW Aston IT Group (tak każe specyfikacja protokołu „http:”).

Jak działa DNS

Z bardziej abstrakcyjnego punktu widzenia DNS stanowi system rozproszonej bazy danych, udostępniający hierarchiczną przestrzeń nazw w celu identyfikacji komputerów w Internecie — w dokładnie taki sam sposób, jak w przypadku Active Directory, która to usługa również została zbudowana na hierarchicznych założeniach. Dlatego właśnie DNS tak dobrze pasuje do Active Directory.

DNS został zaprojektowany aby rozwiązać problemy, które pojawiły się gdy ilość komputerów w Internecie rosła drastycznie na początku lat 80-tych. Podstawowe założenia DNS-u zostały zdefiniowane w RFC 1034 i 1035, które zostały w 1987 roku przyjęte jako standardy Internet Engineering Task Force (IETF) i pozostają w mocy aż do dziś. Specyfikacje DNS-u były oczywiście kilkakrotnie aktualizowane od 1987 roku, co zaowocowało nowymi dokumentami RFC. Dla czytelników zainteresowanych dogłębnym poznaniem DNS-u minimalnym zestawem wymaganych lektur są dokumenty RFC wymienione w tabeli 7.1.

Tabela 7.1

Dokumenty RFC związane z DNS-em

Uwaga

Kilka dokumentów RFC z tabeli 7.1 nie jest częścią oficjalnego standardu DNS, lecz zawiera bezcenne rady związane z DNS-em. Na przykład, wskazówki dotyczące powszechnie spotykanych pomyłek oraz strategii wyszukiwania i usuwania usterek często dają kształcące i oświecające spojrzenie, które przewyższa bardziej abstrakcyjne opisy samego standardu DNS.

Pojęciowa przestrzeń nazw na której opiera się DNS jest hierarchiczną i logiczną strukturą drzewa, nazywaną przestrzenią nazw domen (domain namespace) — która to nazwa potocznie została DNS-em.

Najwyższy poziom w przestrzeni nazw stanowią najbardziej ogólne grupowania i te nazwy domen są znormalizowane. Obecnie istnieje 7 domen ogólnych (generic) i około 200 domen geograficznych najwyższego poziomu. Najwyższy poziom przestrzeni nazw jest obecnie zarządzany przez organizację Internet Authorized Numbers Authority (IANA), która odpowiada za delegowanie odpowiedzialności administracyjnej za części przestrzeni nazw i rejestrację nazw domen. Na przykład, IANA oddelegowała odpowiedzialność za cztery najważniejsze ogólne domeny najwyższego poziomu do Internet Network Information Center (InterNIC: www.internic.net).

Zarządzanie nazwami domen odbywa się za pomocą systemu rozproszonej bazy danych, w którym informacje o nazwach są przechowywane w serwerach nazw, rozmieszczonych w całym Internecie. Każdy serwer nazw posiada pliki bazy danych (znane jako pliki stref), zawierające zarejestrowane informacje dla wybranego obszaru w obrębie hierarchii drzewa domen.

Jak wspomniano, nazwy w bazie danych DNS tworzą logiczną strukturę drzewa, zwaną przestrzenią nazw domen. Rysunek 7.2 przedstawia najwyższy poziom internetowej hierarchii przestrzeni nazw dla USA (chociaż w istocie jest to przestrzeń nazw domen ogólnych, stanowi jednakże podstawowy „pojazd dostawczy” dla kierujących się do USA jednostek i organizacji obecnych w Internecie). Tabela 7.2 przedstawia typy organizacji reprezentowanych przez każde rozszerzenie domeny (chociaż początkowe przeznaczenie dla domen najwyższego poziomu .com, .net i .org nie jest już ściśle narzucane). Tablica 7.3 przedstawia domeny dla reszty świata.

Rysunek 7.2

Ponieważ DNS jest hierarchiczną przestrzenią nazw, ogólne domeny najwyższego poziomu w internetowej hierarchii DNS powinny być przedstawiane w ten sposób.

Tabela 7.2

Internetowe domeny najwyższego poziomu w tzw. ogólnej hierarchii DNS

Tabela 7.3

Domeny najwyższego poziomu poza ogólnymi zawierające skrót dla każdego państwa