Składnia nazw domen

Oceń tę pracę

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

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

Jak wygląda nazwa domeny (Domain Name) w praktyce? Otóż składa się z nazwy komputera oraz nazw jednostek organizacyjnych, które jednostki nazywa się popularnie domenami (domains). Należy dodać, iż domeny i poddomeny mogą być pogrupowane w strefy (zones).

Uproszczony schemat tworzenia Domain Name dla pewnego komputera:

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

Przykład:

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

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

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

<digit> ::= [0-9]

image_pdf

DNS w systemie Windows NT 4.0 Serwer. Cel pracy

Oceń tę pracę

DNS w systemie Windows NT 4.0 Server był jednym z kluczowych komponentów odpowiedzialnych za rozwiązywanie nazw w sieci. System ten obsługiwał zarówno serwery DNS, jak i klienty, umożliwiając rozwiązywanie nazw domenowych w lokalnych sieciach oraz Internecie. Pomimo że Windows NT 4.0 Server nie był tak zaawansowany jak współczesne wersje systemów operacyjnych, oferował podstawowe funkcje niezbędne do zarządzania DNS w organizacji.

Instalacja DNS na serwerze Windows NT 4.0 odbywała się za pomocą dodatku Microsoft DNS Server, który był dostępny w ramach usługi TCP/IP. Podstawową funkcją DNS w tym systemie było mapowanie nazw hostów na adresy IP i odwrotnie. Możliwość ta była kluczowa dla działania usług takich jak poczta elektroniczna czy dostęp do zasobów sieciowych w oparciu o nazwy hostów zamiast adresów IP. Konfiguracja DNS w Windows NT 4.0 Server obejmowała dodanie serwera DNS do systemu oraz określenie odpowiednich stref, które były zarządzane przez ten serwer.

Strefy DNS były centralnym punktem konfiguracji w systemie Windows NT 4.0 Server. Administratorzy mogli ustawić różne typy stref, takie jak strefy forward lookup (do mapowania nazw na adresy IP) oraz reverse lookup (do mapowania adresów IP na nazwy). Strefy mogły być zarządzane lokalnie lub replikowane pomiędzy różnymi serwerami DNS w sieci. Możliwość tworzenia stref umożliwiała łatwe zarządzanie nazwami i zapewniała integralność danych w organizacji.

Replikacja DNS była istotnym elementem w większych środowiskach, gdzie było wymagane, aby wiele serwerów DNS działało w sposób zsynchronizowany. Windows NT 4.0 wspierał replikację stref między serwerami DNS, co umożliwiało dostęp do danych o nazwach w różnych częściach sieci. Replikacja ta odbywała się głównie na zasadzie strefy pełnej replikacji, co oznaczało, że cała zawartość strefy była kopiowana między serwerami.

Bezpieczeństwo i monitorowanie DNS w systemie Windows NT 4.0 Server było podstawowe w porównaniu do dzisiejszych standardów, ale umożliwiało administratorom monitorowanie stanu serwera DNS i przeprowadzanie podstawowych czynności związanych z diagnostyką, takich jak sprawdzanie logów czy testowanie połączeń. Były również opcje dotyczące zabezpieczeń w zakresie autentykacji zapytań DNS, jednak nie były one tak zaawansowane, jak w późniejszych wersjach systemów operacyjnych Windows Server.

DNS w systemie Windows NT 4.0 Server oferował podstawowe narzędzia do zarządzania nazwami domenowymi w sieci. Choć jego możliwości były ograniczone w porównaniu do współczesnych rozwiązań, stanowił fundament dla pracy wielu firm i organizacji, które wykorzystywały sieć TCP/IP do komunikacji i wymiany danych.

Celem pracy

jest omówienie najistotniejszych zagadnień związanych z rozwiązywaniem nazw w systemie DNS, a także pokazanie praktycznego zastosowania tej usługi w systemie Windows NT 4.0 Server
W kolejnych rozdziałach pracy omówiono m.in. następujące zagadnienia:

  • struktury systemu DNS
  • składnię i budowę rekordów
  • zapytania w systemie DNS
  • rozwiązywanie nazw w systemie Windows NT 4.0 Server

Z uwagi na to, iż system rozwiązywania nazw jest zagadnieniem złożonym i rozbudowanym praca zawiera omówienie, prezentacje i przykłady kluczowych dla działania tego systemu elementów.

image_pdf

Zapory sieciowe Firewall. Cel pracy

Oceń tę pracę

Niewielu internautów zdaje sobie sprawę, że beztroskie przeglądanie stron WWW niekiedy niesie ze sobą wiele niespodziewanych niebezpieczeństw. W gąszczu światowej pajęczyny można trafić na kogoś, kto dla pieniędzy, zaspokojenia swojej ciekawości albo po prostu dla sportu będzie próbować złamać najbardziej wyrafinowane systemy zabezpieczeń i zagrozić naszemu komputerowi, który podświadomie uważamy za twierdzę nie do zdobycia.

Podłączenie do sieci publicznej jest dwukierunkowe: pozwala użytkownikowi nie tylko odbierać, ale i dostarczać informacje, co może odbywać się bez jego wiedzy i pozwolenia. Pracując w sieci należy liczyć się chociażby z tak zwanymi atakami Denial of Service, których celem nie jest zdobycie jakichkolwiek informacji, lecz unieruchomienie lub chwilowe zablokowanie serwera bądź stacji.

Podstawową zasadą działania wszelkich systemów ochronnych jest: „To co nie jest jawnie dozwolone – jest zakazane”. Firewall (zapory ogniowe) są instalowane między sieciami w celu wymuszenia kontroli dostępu między nimi. Generalnie rzecz ujmując, firewalle zabezpieczają przed nieautoryzowanym dostępem z zewnątrz do sieci lokalnej. Niektóre nawet mogą całkowicie blokować ruch pakietów z zewnątrz – dopuszczając ewentualnie pakiety poczty elektronicznej – zezwalając jednakże na swobodne komunikowanie się użytkowników sieci ze światem zewnętrznym. Inną pożyteczną cechą firewalli jest możliwość wykorzystania ich do rejestrowania i śledzenia wszelkich przychodzących pakietów (auditing).

Stacje umieszczane w pierwszej linii obrony, określane również jako bastion host, są punktami przez które przechodzą wszystkie informacje do sieci lokalnej i na zewnątrz. Dzięki takiemu scentralizowaniu dróg dostępu do sieci w jednym komputerze można łatwo zarządzać systemem ochrony.

2. Cel pracy.

Celem pracy jest przedstawienie i omówienie wybranych zagadnień związanych z bezpieczeństwem sieci komputerowych i zastosowaniem w nich zapór firewall. W pracy zostały opisane szczegółowo sposoby konfiguracji systemu Linux tak, by spełniał podstawowe zadania i funkcje stawiane przed skuteczną zaporą ogniową a także poruszono najważniejsze zagadnienia związane z podłączeniem i instalacją w sieci Internet komputera pracującego pod kontrolą systemu Windows.

W sierpniu 1996 r. miało miejsce jedno z najbardziej znanych i upokarzających włamań dotyczące Departamentu Sprawiedliwości USA. Hakerom udało się podmienić stronę Web na elektroniczne graffiti składające się portretów Hitlera i golizny. We wrześniu tego roku, na liście „zdobytych” znalazły się strony Web Brytyjskiej Partii Konserwatywnej, Nation of Islam, Amerykańskiego Stowarzyszenia Psychoanalityków, Sił Powietrznych USA oraz Centralnej Agencji Wywiadowczej, której nazwę zmieniono na Central Stupidity Agency (Centralna Agencja Głupoty/Bezsensu)[1].

Ten przykład pokazuje jak bardzo na niebezpieczeństwo narażone są serwery, dane  i strony www publikowane w sieci internet . Ochrona systemów komputerowych, budowa i konfiguracja zapór sieciowych oraz innych systemów zabezpieczeń są tematami niezwykle złożonymi (aktualnymi), których nie sposób wyczerpać w jednej publikacji czy książce.

 

[1] rekonstrukcje włamań do Departamentu Obrony, CIA oraz U.S. Air Force: http:/www.260.com

image_pdf

Canonical Name Entry

5/5 - (1 vote)

Canonical Name (CNAME) to jeden z rekordów DNS, który pozwala przypisać alias do istniejącej domeny. Jego głównym zadaniem jest skierowanie zapytań o jedną nazwę domeny do innej, która jest uznawana za „kanoniczną”, czyli główną nazwę. Zamiast tworzyć osobny rekord dla każdego subdomeny, można użyć rekordu CNAME, aby wskazać, że dana subdomena ma wskazywać na inną, już istniejącą nazwę.

Rekord CNAME jest często wykorzystywany do tworzenia aliasów dla subdomen, co ułatwia zarządzanie nimi. Na przykład, jeśli masz główną stronę internetową dostępną pod domeną example.com, możesz utworzyć subdomenę www.example.com, która będzie aliasem wskazującym na tę samą stronę, bez potrzeby powielania danych w konfiguracji DNS. W takim przypadku rekord CNAME w pliku strefy DNS będzie wyglądał następująco:

www    IN CNAME example.com.

Dzięki temu każde zapytanie skierowane do www.example.com zostanie przekierowane do example.com.

Rekordy CNAME mogą być również używane do wskazywania na usługi zewnętrzne, takie jak serwery pocztowe czy usługi chmurowe. Na przykład, jeśli korzystasz z usługi hostingu poczty elektronicznej, możesz ustawić rekord CNAME, który będzie wskazywał na adres serwera pocztowego dostawcy usług. Dzięki temu możesz używać swojej domeny, np. mail.example.com, zamiast adresu serwera dostawcy.

Chociaż rekordy CNAME są bardzo przydatne, mają pewne ograniczenia. Przede wszystkim, nie mogą być używane dla samej domeny najwyższego poziomu (TLD), czyli nie możesz stworzyć rekordu CNAME dla example.com, wskazując na inną domenę. Ponadto, rekord CNAME nie może współistnieć z innymi rekordami dla tej samej subdomeny, co oznacza, że nie można jednocześnie mieć rekordu A i CNAME dla tej samej nazwy.

Rekordy CNAME są kluczowym narzędziem w zarządzaniu domenami, ponieważ upraszczają konfigurację DNS, umożliwiając łatwe przekierowywanie zapytań o jedną nazwę domeny na inną. Dzięki nim, zarządzanie aliasami i subdomenami staje się bardziej elastyczne i efektywne.

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

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

image_pdf

Start of Authority Entry (SOA)

Oceń tę pracę

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

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

Poszczególne pola oznaczają:

name

Tutaj umieszczana jest nazwa host’a, na którym umieszczone są dane bazy. Zwykle jest nim główny serwer.

person

To pole definiuje login name i adres mail’owy osoby odpowiedzialnej za prowadzenie BIND’a/Hesiod’a w domenie lokalnej.

serial#

Pole przeznaczone jest na numer wersji pliku bazowego. Osoba edytująca pliki konfiguracyjne (master files) dla całej strefy powinna zwiększać o jeden wartość tego pola za każdym razem, kiedy dokonywane są zmiany w plikach. Zmiana numeru seryjnego informuje serwery drugorzędne (secondary servers) o konieczności dokonania zmian w plikach (skopiowania nowej informacji z głównego serwera). Maksymalna wartość wynosi 232-1 „po przecinku” (kropce oddzielającej wartości całkowite od dziesiętnych).

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

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

refresh

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

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

retry

To pole specyfikuje jak długo (w sekundach) drugorzędny server (secondary BIND/Hesiod server) będzie próbował odświeżyć dane, po tym jak podczas sprawdzania nastąpił błąd odświeżania. (Jeżeli server próbuje odświeżyć zawartość plików i kończy się to błędem, próbuje znowu, tyle sekund później, ile zostało zdefiniowane w tym polu).

expire

To pole określa dolny limit (w sekundach) czasu, w którym serwer drugorzędny może utrzymywać dane w cach’u bez potrzeby ich uaktualniania, lub do czasu, w którym serwer główny stwierdzi potrzebę uaktualnienia.

min

Pole specyfikuje domyślny minimalny czas ttl w przypadku, gdy pole ttl pozostawiono pustym.

Przykład:

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

; name ttl addr-class entry-type origin                 person 
@                     IN         SOA     utah.states.dec.com hes.utah.states.dec.com
                                                 ( 1                    ; sesrial
                                                 3600                 ; refresh - co godzinę
                                                 300                   ; retry co 5 minut
                                                 3600000            ; expire co 1000 godzin
                                                 86400 ) ; min - ttl wynosi 24 godziny

W powyższym przykładzie widać, że wartość ttl nie została zdefiniowana w polu ttl, co wskazuje na wyspecyfikowanie tej wartości w polu min.

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

image_pdf