Prace z informatyki

Prace dyplomowe z informatyki

Funkcje rozwiązywania nazw

5/5 - (1 vote)

Funkcje rozwiązywania nazw są kluczowym elementem w zarządzaniu sieciami komputerowymi, ponieważ umożliwiają przekładanie nazw zasobów, takich jak nazwy domenowe, na odpowiadające im adresy IP, które są używane do komunikacji w sieci. Rozwiązywanie nazw jest niezbędne do efektywnego funkcjonowania systemów informacyjnych, ponieważ pozwala użytkownikom i aplikacjom na korzystanie z przyjaznych dla człowieka nazw zamiast trudnych do zapamiętania adresów numerycznych.

Pierwszą funkcją rozwiązywania nazw jest konwersja nazw na adresy IP. W przypadku systemów, takich jak DNS (Domain Name System), rozwiązanie to polega na zamianie przyjaznych nazw domenowych, jak „example.com”, na adresy IP, które są zrozumiałe dla komputerów i innych urządzeń w sieci. W DNS proces ten odbywa się poprzez zapytanie do serwerów DNS, które zawierają informacje o nazwach i odpowiadających im adresach IP.

Kolejną funkcją jest wspieranie komunikacji w sieci. W sieciach lokalnych i globalnych, urządzenia komunikują się między sobą na podstawie adresów IP, ale w praktyce dla użytkowników czy aplikacji znacznie wygodniejsze jest używanie nazw. Funkcja rozwiązywania nazw pozwala na przekładanie tych nazw na adresy IP, umożliwiając przesyłanie danych w sieci. Na przykład, podczas przeglądania strony internetowej, przeglądarka najpierw rozwiązuje nazwę domeny na odpowiedni adres IP serwera, a następnie nawiązuje z nim połączenie.

Bezpieczeństwo jest kolejną funkcją rozwiązywania nazw. W systemach rozwiązywania nazw, takich jak DNS, istnieją mechanizmy, które pozwalają na weryfikację autentyczności odpowiedzi. Przykładem jest DNSSEC (DNS Security Extensions), które zapobiegają atakom, takim jak DNS spoofing, zapewniając integralność danych i autentyczność odpowiedzi DNS. Dzięki takim mechanizmom, użytkownicy i aplikacje mogą mieć pewność, że otrzymane informacje o adresach IP są prawdziwe i pochodzą z wiarygodnego źródła.

Kolejną funkcją jest dostosowywanie wyników rozwiązywania nazw do lokalnych warunków sieciowych. Dzięki mechanizmom takim jak load balancing czy geolokalizacja, systemy rozwiązywania nazw mogą zwracać różne odpowiedzi zależnie od miejsca, z którego pochodzi zapytanie. Na przykład, w przypadku dużych serwisów internetowych, serwer DNS może zwrócić adres IP serwera, który jest najbliżej użytkownika, aby zoptymalizować czas odpowiedzi i zminimalizować opóźnienia w transmisji danych.

Ostatnią ważną funkcją rozwiązywania nazw jest przechowywanie informacji o nazwach. W systemach DNS, każda domena i powiązane z nią zasoby są zorganizowane w postaci rekordów. Dzięki tym rekordom, serwery DNS przechowują informacje o nazwach hostów, serwerach pocztowych, usługach i innych zasobach sieciowych. Rekordy te umożliwiają szybkie i skuteczne rozwiązywanie nazw, co jest istotne w dużych, rozproszonych sieciach, gdzie liczba zasobów jest ogromna.

Funkcje rozwiązywania nazw są niezbędne do zapewnienia prawidłowego działania sieci komputerowych. Obejmują one konwersję nazw na adresy IP, wspieranie komunikacji, zapewnienie bezpieczeństwa, dostosowywanie wyników rozwiązywania nazw oraz przechowywanie i organizowanie informacji o zasobach sieciowych. Dzięki tym funkcjom, użytkownicy mogą łatwo i bezpiecznie korzystać z sieci, a systemy rozwiązywania nazw zapewniają wydajność i elastyczność, która jest niezbędna w globalnym środowisku internetowym.

Dla wygody polecenia wyższego rzędu użytkownika wykorzystują nazwy hostów do podawania lokalizacji zdalnych maszyn w sieci. Z tego powodu oprogramowanie sieciowe wymaga adresu sieciowego systemu używającego tej nazwy hosta, by wykonać żądaną operację. W ten sposób, gdy użytkownik wprowadzi polecenie takie jak finger chavez@hamlet, pierwszą rzeczą, jaką trzeba zrobić, to zamienić nazwę hosta hamlet na jego adres IP (10.1.2.6). TCP/IP daje dwa sposoby wykonywania translacji adresu z nazwy hosta na IP (proces ten jest także nazywany rozwiązywaniem nazw):

  • Adres IP można znaleźć szukając nazwy hosta w pliku konfiguracyjnym Hosts. W systemach Windows NT plik ten jest umieszczony w katalogu %SystcniRoot%\System32\Drivers\Etc
  • System może poprosić o translacje serwer pracujący jako DNS (Domain Name Service), by od niego dostać adres IP

Ta sama kwestia często pojawia się wtedy, gdy użytkownik wprowadzi polecenie takie jak net view tirzach lub dir\\pele\homes\chavez. Polecenia te są oparte na protokołach SMB i NetBIOS. Operacje NetBIOS mogą uzyskać adres IP dla zadanej nazwy hosta z pliku konfiguracyjnego LHHosts (zapisanego w tym samym katalogu, co plik Hosts TCP/IP) lub przez WINS (Windows Internet Name Service), który zapewnia rejestrację nazwy hosta i usługi rozwiązywania nazw dla NetBIOS. W systemach Windows NT WINS może pracować wraz z DNS, a oba systemy są zintegrowane.

Dodatkowa konfiguracja sieci

Oceń tę pracę

W zależności od przeznaczenia nowego systemu, może zajść potrzeba zainstalowania dodatkowych usług TCP/IP W tabeli pokazałem dostępne usługi sieciowe oferowane przez system operacyjny Windows NT. Elementy oznaczone gwiazdką są instalowane domyślnie. Dowolne z nich można zainstalować za pomocą zakładki Services (Usługi) apletu Network panelu sterowania.

Usługa Opis
BOOTP Relay Agent Pozwala systemowi na przekazywanie pakietów rozgłoszeniowych BOOTP pomiędzy podsieciami (jest to poprzednik DHCP obsługujący zdalne inicjowanie bezdyskowych stacji roboczych)
Computer Browser Obsługa przeglądania sieci w stylu Explorera Windows
DHCP Relay Agent Przekazywanie pakietów rozgłoszeniowych DHCP do zdalnego serwera DHCP w innej podsieci (np. jeżeli router łączy sieci, nie będzie tego robił)
Gateway (and Client) Services for NetWare Dostęp do sieci NetWare
Microsoft DHCP Server Przypisanie adresu IP do żądającego go komputera
Microsoft DNS Server Podanie adresu IP odpowiadającego nazwie hosta (zawiera integrację z WINS)
Microsoft Internet Information Server Udostępnianie różnych usług WWW (zawiera serwer FTP oddzielony w wersji Windows NT 3.5x)
Microsoft TCP/IP Printing Obsługa drukowania do i z obcych hostów TCP/IP przez funkcję LPD
NetBIOS Interface Podstawowa obsługa NetBIOS (wymagane przez niektóre usługi)
Network Monitor Agent Zbieranie danych o wydajności sieci
Network Monitor Tools and Agent Zbieranie danych o wydajności sieci oraz narzędzia do ich oglądania
Remote Access Service Włączenie sieci typu dial-up (w oparciu o PPP lub SLIP)
Remoteboot Service RIP for Internet Protocol Zapewnienie usługi startowania stacji bezdyskowych Włączenie routingu TCP/IP pomiędzy podsieciami Usługi rutingu dla NetWare (IPX)
RIP for NWLink IPX/SPX Compatible Transport Obsługa możliwości RPC (Remote Procedure Call)
RPC Configuration RPC Support for Banyan Obsługa wywołań RPC do komputerów w sieciach Banyan Vines
SAP Agent Wsparcie dla protokółu NetWare SAP (Service Advertising Protocol)
Server System działa jako serwer NT (wykorzystuje protokół SMB)
Services for Macintosh Zapewnienie możliwości podłączenia klientom Macintosh
Simple TCP/IP Services Dodanie usług testowych związanych z TCP/IP:

Chargen, Daytime, Discard, Echo i Quote (mimo nazwy, element ten nie jest potrzebny w większości systemów)
SNMP Service Implementacja protokołu SNMP (Simple Network Monitoring Protocol), używanego przez wiele narzędzi do administrowania siecią
Windows Internet Name Service Usługa rozwiązywania nazw w Microsoft LAN. Tłumaczenie nazw hostów na adresy MAC
Workstation Usługi wymagane przez system pracujący jako stacja robocza (klient SMB)

Zarządzanie siecią i domenami w Windows NT 4.0 Server

Oceń tę pracę

Windows NT obsługuje inne standardowe protokoły sieciowe poza TCP/IP: IPX/SPX (NetWare), AppleTalk i SNA (przez oddzielny produkt BackOffice).

Jeden z tych protokołów wymaga krótkiego zastanowienia: NetBIOS. W systemach DOS podstawowy system we/wy (BIOS – Basic Input/Output System) stanowi interfejs we/wy systemu operacyjnego. NetBIOS został stworzony, by rozszerzyć go na operacje we/wy w sieci lokalnej. Interfejs NetBIOS wymaga odpowiedniego protokołu transportowego. Pierwszy został stworzony protokół o nazwie NetBIOS Frames Protocol (NBFP). Aktualnie w środowiskach bez TCP/IP ruch NetBIOS wykorzystuje NetBIOS Extended User Interface (NetBEUI) Frame Protocol (NBF) – jest to protokół transportowy wykorzystywany w tradycyjnych sieciach Microsoft. NetBIOS może pracować również przez TCP/IP (NetBIOS over TCP/IP). Usługi wyższego poziomu w standardowej sieci Microsoft działają w oparciu o protokół Server Message Block (SMB).

NetBIOS i NetBEUI niezbyt dobrze skalują się w większych sieciach z kilku powodów technicznych: są one oparte na rozgłoszeniowym schemacie nazw, ich pakiety nie mogą być rutowane, brak jest kompatybilności sieciowej z innymi rodzajami komputerów i z kilku innych powodów. W związku z tym stworzono sposoby i standardy używania NetBIOS w oparciu o inne rodziny protokołów, takich jak TCP/IP W Windows NT możną używać obu sposobów. Jeżeli protokół NetBEUI jest zainstalowany, lokalny ruch NetBIOS będzie go wykorzystywał, natomiast standardowe funkcje TCP/IP będą wykorzystywać TCP/IP – w przeciwnym razie funkcje oparte na NetBIOS będą wykorzystywać TCP/IP do komunikacji z innymi hostami.

Zarządzanie siecią i domenami w Windows NT 4.0 Server było kluczowym elementem dla organizacji korzystających z tego systemu operacyjnego w latach 90. XX wieku. Windows NT 4.0 Server wprowadził zaawansowane mechanizmy zarządzania siecią, które umożliwiły administratorom sieci pełną kontrolę nad zasobami oraz użytkownikami w dużych środowiskach komputerowych.

Pierwszym krokiem w zarządzaniu siecią w Windows NT 4.0 Server jest konfiguracja usług sieciowych, w tym protokołu TCP/IP, który stał się standardem w komunikacji sieciowej. System ten pozwalał administratorom na konfigurację statycznych adresów IP lub wykorzystanie dynamicznego przypisywania adresów przez serwer DHCP. WNT 4.0 umożliwiał również konfigurację DNS, co pozwalało na efektywne rozwiązywanie nazw komputerów w sieci. Dodatkowo, w systemie dostępne były usługi WINS (Windows Internet Name Service), które umożliwiały rozwiązywanie nazw NetBIOS w sieci Windows.

Zarządzanie domenami w Windows NT 4.0 Server opierało się na architekturze Windows NT Domain, gdzie użytkownicy i komputery były zarządzane przez kontroler domeny. W tym systemie administratorzy mogli tworzyć konta użytkowników, przypisywać im odpowiednie uprawnienia oraz konfigurować zasady bezpieczeństwa, takie jak hasła czy kontrole dostępu do zasobów. Active Directory, które zostało wprowadzone dopiero w Windows 2000, nie było obecne w NT 4.0, co oznaczało, że system ten wykorzystywał klasyczne podejście oparte na grupach roboczych i domenach. Użytkownicy, którzy chcieli korzystać z zasobów sieciowych, musieli zostać zapisani w odpowiedniej domenie, a dostęp do zasobów był autoryzowany na podstawie tych kont.

Rola kontrolera domeny była niezwykle ważna w systemie Windows NT 4.0 Server. Kontroler domeny przechowywał bazę danych o użytkownikach, komputerach i uprawnieniach, a także odpowiadał za uwierzytelnianie użytkowników przy logowaniu do sieci. W tej architekturze możliwe było skonfigurowanie hierarchii domen, gdzie jedna domena mogła pełnić rolę domeny głównej, a inne mogły być domenami podrzędnymi, tworząc w ten sposób strukturę rozproszoną.

W przypadku większych organizacji, replikacja domeny była istotnym elementem zarządzania. Windows NT 4.0 Server umożliwiał replikację bazy danych między kontrolerami domeny, co zapewniało spójność informacji o użytkownikach i komputerach w różnych lokalizacjach sieciowych. Replikacja była realizowana zarówno w obrębie jednej domeny, jak i między różnymi domenami, co pozwalało na centralne zarządzanie i jednoczesny dostęp do zasobów sieciowych z wielu miejsc.

Zarządzanie politykami grupowymi w Windows NT 4.0 Server było ograniczone w porównaniu do późniejszych wersji systemu, jednak system ten umożliwiał konfigurację podstawowych zasad bezpieczeństwa za pomocą Group Policy. Administratorzy mogli definiować zasady logowania, ustawienia haseł, ograniczenia dostępu do zasobów i aplikacji, a także kontrolować ustawienia komputerów w domenie. Mimo że mechanizmy te były mniej elastyczne niż te dostępne w nowszych wersjach systemu Windows Server, wciąż stanowiły podstawowe narzędzie zarządzania politykami w organizacjach korzystających z NT 4.0 Server.

Zarządzanie siecią i domenami w Windows NT 4.0 Server obejmowało konfigurowanie usług sieciowych takich jak TCP/IP, WINS i DNS, zarządzanie użytkownikami i komputerami w ramach domen, a także replikację kontrolerów domeny i definiowanie polityk bezpieczeństwa. System ten, mimo swoich ograniczeń, stanowił fundament dla późniejszych, bardziej zaawansowanych rozwiązań w systemach Windows Server, oferując szeroką kontrolę nad zasobami i użytkownikami w sieci.

Queries (zapytania)

Oceń tę pracę

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

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

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

Rodzaje zapytań

Podstawowe dwa rodzaje zapytań stosowane podczas uzyskiwania informacji:

  • STANDARD QUERIES Standardowy typ zapytania specyfikuje nazwę domeny docelowej (QNAME), rodzaj zapytania oraz klasę (QCLASS) oraz pytanie o rekordy RR, które sięzgadzają.

Używając nazwy domeny odpytywanej, oraz pól QTYPE, QCLASS name server szuka pasujących do siebie rekordów RR. W przypadku rekordów powiązanych name server może jako wynik zwrócić rekord będący wskazaniem na inny name server, posiadający informację o interesujących nas rekordach lub wyjaśniających powiązania rekordów.

Na przykład, name server, który sam nie posiada żądanej informacji, zna inne name server’y, name server zwracający nazwę domeny w postaci powiązanych rekordach może również zwrócić jako efekt rekord przypisujący nazwie domeny jej adres.

INVERSE QUERIES

Możliwe jest wykonywanie przez name server’y zapytań odwróconych, które przypisują (map) pewien konkretny zasób do domeny lub nazw domen, będących w posiadaniu takich zasobów.

Na przykład, jeżeli zwykłe zapytanie może przypisać nazwę domeny do wpisu SOA w RR, to odwrócone zapytanie może z powrotem przypisać temu wpisowi rekordu nazwę domeny.

Implementacja jest opcjonalna dla serwerów DNS, jednak wymagane jest, by każdy name server był w stanie odczytać i zrozumieć komunikat odwróconego zapytania i zwrócić odpowiedź nie będącą błędem.

Tego typu zapytania są wykorzystywane głównie do celów debugging’u jak i zarządzania bazą danych serwera DNS.

Absolutnie nie wolno stosować odwróconych zapytań do przypisywania adresów host’ów ich nazwom. Do tego celu służy specjalna domena .in-addr.arp. W zależności od zaawansowania serwera, może on odpowiadać na dwa różne sposoby – nierekursywny i rekursywny.

  • nierekursywny Najprostszy sposób, w którym name server może odpowiadać używając tylko lokalnych informacji: odpowiedź zawiera komunikat obłędzie, odpowiedź, lub odnośnik do innego serwera bliższego udzielenia odpowiedzi. Wszystkie serwery muszą mieć obowiązkowo zaimplementowany ten sposób.
  • rekursywny Pozwala name server’owi „przejąć” rolę resolver’a, i zwrócić jako rezultat błąd, albo odpowiedź, nigdy natomiast nie może zwrócić dalszego odnośnika. Jest to opcja implementacyjna, nawet name server, który ma ją zaimplementowaną może ograniczyć jej działanie do wybranych klientów a innym odmówić.

Serwis rekursywny bywa pomocny w sytuacji, gdy:

  • klientem jest prymitywny zgłoszeniodawca, którego możliwości sprowadzają się wyłącznie do użycia bezpośredniej odpowiedzi
  • żądanie obsługi musi przekroczyć barierę protokołu, lub inne granice – w takim przypadku zgłoszenie jest wysyłane do serwera, który może pośredniczyć w komunikacji
  • organizuje się sieć w której chcemy zastąpić oddzielne cache’e dla każdego z klientów na rzecz jednego

Przykłady zapytań

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

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

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

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

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

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

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

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

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

Well Known Services Entry

Oceń tę pracę

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

Well Known Services Entry w kontekście DNS i sieci komputerowych odnosi się do powszechnie rozpoznawanych i standardowych usług, które mają przypisane określone numery portów i są uznawane za część standardowego zestawu protokołów internetowych. Te usługi są zwykle obsługiwane przez serwery w Internecie i mają przypisane numery portów z zakresu od 0 do 1023. Są one używane do obsługi różnych typów połączeń sieciowych i aplikacji, takich jak serwery WWW, poczta elektroniczna, transfer plików i wiele innych.

W systemie DNS, rekordy związane z Well Known Services są często implementowane jako część systemu SRV (Service Record), który umożliwia rozpoznawanie serwisów w sieci. Rekordy te wskazują na serwery, które oferują określoną usługę, a także wskazują numery portów, na których dana usługa jest dostępna. Dla takich dobrze znanych usług, jak HTTP (port 80), HTTPS (port 443), FTP (port 21), SMTP (port 25) i inne, istnieje przypisany zestaw standardowych portów, który jest wykorzystywany w różnych aplikacjach sieciowych.

Na przykład, dla usługi HTTP, serwer WWW, który obsługuje tę usługę, najczęściej jest dostępny na porcie 80. W DNS, może to być reprezentowane za pomocą rekordów A lub CNAME, wskazujących na serwery WWW:

www    IN A 192.0.2.1

Chociaż ta konfiguracja nie używa bezpośrednio rekordów SRV, sama usługa HTTP jest częścią zestawu Well Known Services. Dla bardziej złożonych usług, jak SIP (Session Initiation Protocol) czy LDAP (Lightweight Directory Access Protocol), które wymagają bardziej zaawansowanego mapowania serwisów w sieci, wykorzystuje się rekordy SRV:

_sip._tcp.example.com. IN SRV 10 60 5060 sipserver.example.com.

W tym przypadku rekord SRV wskazuje, że usługa SIP dostępna jest na porcie 5060 na serwerze sipserver.example.com z priorytetem 10 i wagą 60.

Rekordy związane z Well Known Services w DNS są kluczowe dla odpowiedniego kierowania zapytań do odpowiednich serwerów obsługujących popularne usługi w Internecie. Poprzez użycie odpowiednich portów i odpowiednią konfigurację DNS, użytkownicy i aplikacje mogą bezproblemowo łączyć się z serwisami internetowymi, takimi jak strony WWW, serwery poczty czy inne usługi oparte na TCP/IP.

Format WKS:

name ttl addr-class entry-type address protocol services

W praktyce przestało się tego używać, ponieważ mało serwerów używa tego wpisu, ponieważ nie ma takiego obowiązku. Poszczególne pola mają wartości zdefiniowane podobnie jak dla BIND File Entries, z wyjątkiem pól:

address

To pole specyfikuje adres IP dla każdego systemu. Dozwolone jest tylko jedno WKS dla każdego adresu IP.

hardware

Pole zawiera informację u stosowanym protokole, jaki będzie użyty dla usługi (np. UDP lub TCP)

Przykład: Wpis pola HINFO posiadającego dwie pozycje.

; name ttl addr-class entry-type address             protocol services                        IN HINFO         128.32.0.4        UDP who route                        IN HINFO         128.32.0.78      TCP (echo talk                                                                         discard sftp                                                                         netstat host                                                                         time link pop                                                                         finger domain auth)Usługi ujęte w nawiasy () są traktowane jako jedna usługa i mogą zajmować więcej niż jedną linijkę.