DNS (ang. Domain Name System, system nazw domenowych) - system serwerów, protokół komunikacyjny oraz usługa zapewniająca zamianę adresów znanych użytkownikomInternetu na adresy zrozumiałe dla urządzeń tworzących sieć komputerową. Dzięki wykorzystaniu DNS nazwa mnemoniczna, np. pl.wikipedia.org, może zostać zamieniona na odpowiadający jej adres IP, czyli 91.198.174.232 Usługa DNS warstwy aplikacji modelu TCP/IP, jest związana z portem 53 TCP/UDP.
Adresy DNS składają się z domen internetowych rozdzielonych kropkami. Dla przykładu w adresie Wikipedii org oznacza domenę funkcjonalną organizacji, wikipedia domenę należącą do fundacji Wikimedia, a pl polską domenę w sieci tej instytucji. W ten sposób możliwe jest budowanie hierarchii nazw, które porządkują Internet.
DNS to złożony system komputerowy oraz prawny. Zapewnia z jednej strony rejestrację nazw domen internetowych i ich powiązanie z numerami IP. Z drugiej strony realizuje bieżącą obsługę komputerów odnajdujących adresy IP odpowiadające poszczególnym nazwom.
System DNS posiada następujące cechy:
Nie ma jednej centralnej bazy danych adresów IP i nazw. Najważniejszych jest 13 głównych serwerów rozrzuconych na różnych kontynentach.
Serwery DNS przechowują dane tylko wybranych domen.
Każda domena powinna mieć co najmniej 2 serwery DNS obsługujące ją, jeśli więc nawet któryś z nich będzie nieczynny, to drugi może przejąć jego zadanie.
Każda domena posiada jeden główny dla niej serwer DNS (tzw. master), na którym to wprowadza się konfigurację tej domeny, wszystkie inne serwery obsługujące tę domenę są typuslave i dane dotyczące tej domeny pobierają automatycznie z jej serwera głównego po każdej zmianie zawartości domeny.
Serwery DNS mogą przechowywać przez pewien czas odpowiedzi z innych serwerów (ang. caching), a więc proces zamiany nazw na adresy IP jest często krótszy niż w podanym przykładzie.
Na dany adres IP może wskazywać wiele różnych nazw. Na przykład na adres IP 207.142.131.245 mogą wskazywać nazwy pl.wikipedia.org oraz de.wikipedia.org
Czasami pod jedną nazwą może kryć się więcej niż 1 adres IP po to, aby jeśli jeden z nich zawiedzie, inny mógł spełnić jego rolę.
Przy zmianie adresu IP komputera pełniącego funkcję serwera WWW, nie ma konieczności zmiany adresu internetowego strony, a jedynie poprawy wpisu w serwerze DNS obsługującym domenę.
Przykład działania systemu DNS
Oto przykład działania systemu DNS. Użytkownik komputera wpisuje w swojej przeglądarce stron WWW adres internetowy pl.wikipedia.org. Przeglądarka musi poznać adres IP komputera będącego serwerem WWW dla tej strony. Cały proces przebiega zgodnie z tabelą.
Pobieranie adresu DNS |
|||
Wysyła |
Odbiera |
Komunikat |
Uwagi |
Przeglądarka |
Serwer DNS providera (194.204.152.34) |
Czy znasz adres IP komputerapl.wikipedia.org? |
Przeglądarka wysyła pakiet UDP z pytaniem do serwera DNS zdefiniowanego w konfiguracji systemu operacyjnego - najczęściej jest to serwer DNS providera Internetu, (dla TPSA jest to np. 194.204.152.34). |
Serwer DNS providera (194.204.152.34) |
Główny serwer DNS (198.41.0.4) |
Czy znasz adres IP komputerapl.wikipedia.org? |
Serwer DNS providera (194.204.152.34) wysyła zapytanie do jednego z 13 serwerów głównych (np. tego o adresie IP 198.41.0.4). |
Główny serwer DNS (198.41.0.4) |
Serwer DNS providera (194.204.152.34) |
Nie znam, ale dla domeny orgserwerami są 204.74.112.1 i204.74.113.1. |
Zapytany serwer główny (198.41.0.4) odpowiada na zapytanie serwera providera. |
Serwer DNS providera (194.204.152.34) |
Serwer DNS domeny "org" (204.74.112.1) |
Czy znasz adres IP komputerapl.wikipedia.org? |
Serwer DNS wysyła do jednego z tych 2 serwerów (np. tego o adresie IP 204.74.112.1) zapytanie. |
Serwer DNS domeny "org" (204.74.112.1) |
Serwer DNS providera (194.204.152.34) |
Nie znam, ale dla domenywikipedia.org serwerami są216.21.226.87 i 216.21.234.87. |
Serwer domeny "org" odpowiada. |
Serwer DNS providera (194.204.152.34) |
Serwer domeny "wikipedia.org" (216.21.226.87) |
Czy znasz adres IP komputerapl.wikipedia.org? |
Serwer DNS wysyła do jednego z tych 2 serwerów, np. tego o adresie IP 216.21.226.87 zapytanie. |
Serwer DNS domeny "wikipedia.org" (216.21.226.87) |
Serwer DNS providera (194.204.152.34) |
pl.wikipedia.org ma adres IP 207.142.131.245. |
Serwer domeny "wikipedia.org" (216.21.226.87) odpowiada. |
Serwer DNS providera (194.204.152.34) |
Przeglądarka |
pl.wikipedia.org ma adres IP 207.142.131.245. |
Serwer DNS TPSA (194.204.152.34) odpowiada przeglądarce. |
Przeglądarka |
Serwer "pl.wikipedia.org" (207.142.131.245) |
Transakcja pobrania strony WWW. |
Przeglądarka łączy się z serwerem "pl.wikipedia.org" (o adresie IP 207.142.131.245) i wyświetla otrzymaną stronę. |
Protokół DNS
Zapytania i odpowiedzi DNS są najczęściej transportowane w pakietach UDP. Każdy komunikat musi się zawrzeć w jednym pakiecie UDP (standardowo 512 oktetów, ale wielkość tę można zmieniać pamiętając również o ustawieniu takiej samej wielkości w MTU - Maximum Transmission Unit). W innym przypadku przesyłany jest protokołem TCP i poprzedzony dwubajtową wartością określającą długość zapytania i długość odpowiedzi (bez wliczania tych dwóch bajtów). Format komunikatu DNS został zdefiniowany w RFC 1035.
Format komunikatu DNS:
NAGŁÓWEK - (Header) |
ZAPYTANIE - (Question) do serwera nazw |
ODPOWIEDŹ - (Answer) zawiera rekordy będące odpowiedzią |
ZWIERZCHNOŚĆ - (Authority) wskazuje serwery zwierzchnie dla domeny |
DODATKOWA - (Additional) sekcja informacji dodatkowych |
Forma nagłówka, który określa rolę całego komunikatu:
Sekcja nagłówka występuje zawsze. W sekcji zapytania zawsze znajduje się jedno zapytanie zawierające nazwę domenową, żądany typ danych i klasę (IN). Sekcja odpowiedzi zawiera rekordy zasobów stanowiące odpowiedź na pytanie.
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
ID |
|||||||||||||||
QR |
OPCODE |
AA |
TC |
RD |
RA |
Z |
RCODE |
||||||||
QDCOUNT |
|||||||||||||||
ANCOUNT |
|||||||||||||||
NSCOUNT |
|||||||||||||||
ARCOUNT |
|||||||||||||||
ID [16 bitów] - (IDentifier) - identyfikator tworzony przez program wysyłający zapytanie; serwer przepisuje ten identyfikator do swojej odpowiedzi, dzięki czemu możliwe jest jednoznaczne powiązanie zapytania i odpowiedzi
QR [1 bit] - (Query or Response) - określa, czy komunikat jest zapytaniem (0) czy odpowiedzią (1)
OPCODE [4 bity] - określa rodzaj zapytania wysyłanego od klienta, jest przypisywany przez serwer do odpowiedzi. Wartości:
0 - QUERY - standardowe zapytanie,
1 - IQUERY - zapytanie zwrotne,
2 - STATUS - pytanie o stan serwera,
3-15 - zarezerwowane do przyszłego użytku
AA [1 bit] - (Authoritative Answer) - oznacza, że odpowiedź jest autorytatywna.
TC [1 bit] - (TrunCation) - oznacza, że odpowiedź nie zmieściła się w jednym pakiecie UDP i została obcięta.
RD [1 bit] - (Recursion Desired) - oznacza, że klient żąda rekurencji - pole to jest kopiowane do odpowiedzi
RA [1 bit] - (Recursion Available) - bit oznaczający, że serwer obsługuje zapytania rekurencyjne
Z [3 bity] - zarezerwowane do przyszłego wykorzystania. Pole powinno być wyzerowane.
RCODE [4 bity] - (Response CODE) kod odpowiedzi. Przyjmuje wartości:
0 - brak błędu
1 - błąd formatu - serwer nie potrafił zinterpretować zapytania
2 - błąd serwera - wewnętrzny błąd serwera
3 - błąd nazwy - nazwa domenowa podana w zapytaniu nie istnieje
4 - nie zaimplementowano - serwer nie obsługuje typu otrzymanego zapytania
5 - odrzucono - serwer odmawia wykonania określonej operacji, np. transferu strefy
6-15 - zarezerwowane do przyszłego użytku
QDCOUNT [16 bitów] - określa liczbę wpisów w sekcji zapytania
ANCOUNT [16 bitów] - określa liczbę rekordów zasobów w sekcji odpowiedzi
NSCOUNT [16 bitów] - określa liczbę rekordów serwera w sekcji zwierzchności
ARCOUNT [16 bitów] - określa liczbę rekordów zasobów w sekcji dodatkowej
TCP (ang. Transmission Control Protocol) - połączeniowy, niezawodny, strumieniowy protokół komunikacyjny wykorzystywany do przesyłania danych pomiędzy procesami uruchomionymi na różnych maszynach, będący częścią szeroko wykorzystywanego obecnie stosu TCP/IP -korzysta z usług protokołu IP do wysyłania i odbierania danych oraz ichfragmentacji wtedy, gdy jest to konieczne[1]. Protokół TCP operuje w warstwie transportowej modelu OSI. Został opracowany bazując na badaniach Vintona Cerfa oraz Roberta Kahna[1][2]i jest opisany w dokumencie RFC793.
W protokole TCP do nawiązania połączenia pomiędzy dwoma hostami wykorzystywana jest procedura nazwana three-way handshake. W sytuacji normalnej jest ona rozpoczynana, gdy host A chce nawiązać połączenie z hostem B, procedura wygląda następująco[1]:
host A wysyła do hosta B segment SYN wraz z informacją o dolnej wartości numerów sekwencyjnych używanych do numerowania segmentów wysyłanych przez host A (np. 100) a następnie przechodzi w stan SYN-SENT,
host B, po otrzymaniu segmentu SYN, przechodzi w stan SYN-RECEIVED i, jeżeli również chce nawiązać połączenie, wysyła hostowi A segment SYN z informacją o dolnej wartości numerów sekwencyjnych używanych do numerowania segmentów wysyłanych przez host B (np. 300) oraz segment ACK z polem numeru sekwencji ustawionym na wartość o jeden większą niż wartość pola sekwencji pierwszego segmentu SYN hosta A, czyli 101.
host A, po odebraniu segmentów SYN i ACK od hosta B przechodzi w stan ESTABLISHED i wysyła do niego segment ACK potwierdzający odebranie segmentu SYN (numer sekwencji ustawiony na 301)
host B odbiera segment ACK i przechodzi w stan ESTABLISHED
host A może teraz rozpocząć przesyłanie danych
Jeśli host odbierający połączenie nie chce lub nie może odebrać połączenia, powinien odpowiedzieć pakietem z ustawioną flagą RST (reset).
W celu weryfikacji wysyłki i odbioru TCP wykorzystuje sumy kontrolne i numery sekwencyjne pakietów. Odbiorca potwierdza otrzymanie pakietów o określonych numerach sekwencyjnych ustawiając flagę ACK. Brakujące pakiety są retransmitowane. Host odbierający pakiety TCP defragmentuje je i porządkuje je według numerów sekwencyjnych tak, by przekazać wyższym warstwom modelu OSI pełen złożony segment.
Prawidłowe zakończenie połączenia może być zainicjowane przez dowolną stronę. Polega ono na wysłaniu pakietu z ustawioną flagą FIN (finished). Pakiet taki wymaga potwierdzenia flagą ACK. Najczęściej po otrzymaniu pakietu z flagą FIN, druga strona również kończy komunikację wysyłając pakiet z flagami FIN i ACK. Pakiet taki również wymaga potwierdzenia przez przesłanie ACK.
Dopuszcza się również awaryjne przerwanie połączenia poprzez przesłanie pakietu z flagą RST (reset). Pakiet taki nie wymaga potwierdzenia.
Połączenie TCP może znajdować się w jednym z następujących stanów:
LISTEN
Gotowość do przyjęcia połączenia na określonym porcie przez serwer.
SYN-SENT
Pierwsza faza nawiązywania połączenia przez klienta. Wysłano pakiet z flagą SYN. Oczekiwanie na pakiet SYN+ACK.
SYN-RECEIVED
Otrzymano pakiet SYN, wysłano SYN+ACK. Trwa oczekiwanie na ACK. Połączenie jest w połowie otwarte (ang. half-open).
ESTABLISHED
Połączenie zostało prawidłowo nawiązane. Prawdopodobnie trwa transmisja.
FIN-WAIT-1
Wysłano pakiet FIN. Dane wciąż mogą być odbierane ale wysyłanie jest już niemożliwe.
FIN-WAIT-2
Otrzymano potwierdzenie własnego pakietu FIN. Oczekuje na przesłanie FIN od serwera.
CLOSE-WAIT
Otrzymano pakiet FIN, wysłano ACK. Oczekiwanie na przesłanie własnego pakietu FIN (gdy aplikacja skończy nadawanie).
CLOSING
Połączenie jest zamykane.
LAST-ACK
Otrzymano i wysłano FIN. Trwa oczekiwanie na ostatni pakiet ACK.
TIME-WAIT
Oczekiwanie w celu upewnienia się, że druga strona otrzymała potwierdzenie rozłączenia. Zgodnie z RFC 793 połączenie może być w stanie TIME-WAIT najdłużej przez 4 minuty.
CLOSED
Połączenie jest zamknięte.
TCP Header |
|||||||||||||||||||||||||||||||||
Offsets |
0 |
1 |
2 |
3 |
|||||||||||||||||||||||||||||
Octet |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
|
0 |
0 |
Port nadawcy |
Port odbiorcy |
||||||||||||||||||||||||||||||
4 |
32 |
Numer sekwencyjny |
|||||||||||||||||||||||||||||||
8 |
64 |
Numer potwierdzenia (jeżeli flaga ACK jest ustawiona) |
|||||||||||||||||||||||||||||||
12 |
96 |
Długość nagłówka |
Zarezerwowane |
N |
C |
E |
U |
A |
P |
R |
S |
F |
Window Size |
||||||||||||||||||||
16 |
128 |
Checksum |
Wskaźnik priorytetu (jeżeli flaga URG jest ustawiona) |
||||||||||||||||||||||||||||||
20 |
160 |
Opcje (jeżeli długość nagłówka > 5, to pole jest uzupełniane "0") |
|||||||||||||||||||||||||||||||
Numer sekwencyjny - 32-bitowy identyfikator określający miejsce pakietu danych w pliku przed fragmentacją (dzięki niemu, można "poskładać" plik z poszczególnych pakietów).
Numer potwierdzenia - 32-bitowy numer będący potwierdzeniem otrzymania pakietu przez odbiorcę, co pozwala na synchronizację nadawanie-potwierdzenie.
Długość nagłówka - 4-bitowa liczba, która oznacza liczbę 32-bitowych wierszy nagłówka, co jest niezbędne przy określaniu miejsca rozpoczęcia danych. Dlatego też nagłówek może mieć tylko taką długość, która jest wielokrotnością 32 bitów.
Zarezerwowane - 4-bitowy ciąg zer, zarezerwowany dla ewentualnego przyszłego użytku.
Flagi 8-bitowa informacja/polecenie dotyczące bieżącego pakietu. Poszczególne flagi oznaczają:
CWR - (ang. Congestion Window Reduced) flaga potwierdzająca odebranie powiadomienia przez nadawcę, umożliwia odbiorcy zaprzestanie wysyłania echa.
ECE - (ang. ECN-Echo) flaga ustawiana przez odbiorcę w momencie otrzymania pakietu z ustawioną flagą CE
URG - informuje o istotności pola "Priorytet"
ACK - informuje o istotności pola "Numer potwierdzenia"
PSH - wymusza przesłanie pakietu
RST - resetuje połączenie (wymagane ponowne uzgodnienie sekwencji)
SYN - synchronizuje kolejne numery sekwencyjne
FIN - oznacza zakończenie przekazu danych
Szerokość okna - 16-bitowa informacja o tym, ile danych może aktualnie przyjąć odbiorca. Wartość 0 wskazuje na oczekiwanie na segment z innym numerem tego pola. Jest to mechanizm zabezpieczający komputer nadawcy przed zbyt dużym napływem danych.
Suma kontrolna - 16-bitowa liczba, będąca wynikiem działań na bitach całego pakietu, pozwalająca na sprawdzenie tego pakietu pod względem poprawności danych.
Wskaźnik priorytetu - jeżeli flaga URG jest włączona, informuje o ważności pakietu.
Opcje - czyli ewentualne dodatkowe informacje i polecenia:
0 - koniec listy opcji
1 - brak działania
2 - ustawia maksymalna długość segmentu
W przypadku opcji 2 to tzw. Uzupełnienie, które dopełnia zerami długość segmentu do wielokrotności 32 bitów (patrz: informacja o polu "Długość nagłówka")
UDP (ang. User Datagram Protocol - protokół pakietów użytkownika) - jeden z podstawowych protokołów internetowych. Umieszcza się go w warstwie czwartej (transportu) modelu OSI.
Jest to protokół bezpołączeniowy, więc nie ma narzutu na nawiązywanie połączenia i śledzenie sesji (w przeciwieństwie do TCP). Nie ma też mechanizmów kontroli przepływu i retransmisji. Korzyścią płynącą z takiego uproszczenia budowy jest większa szybkość transmisji danych i brak dodatkowych zadań, którymi musi zajmować się host posługujący się tym protokołem. Z tych względów UDP jest często używany w takich zastosowaniach jak wideokonferencje, strumienie dźwięku w Internecie i gry sieciowe, gdzie dane muszą być przesyłane możliwie szybko, a poprawianiem błędów zajmują się inne warstwy modelu OSI. Przykładem może być VoIP lub protokół DNS.
UDP udostępnia mechanizm identyfikacji różnych punktów końcowych (np. pracujących aplikacji, usług czy serwisów) na jednym hoście dzięki portom (porównaj: gniazdo). UDP zajmuje się dostarczaniem pojedynczych pakietów, udostępnionych przez IP, na którym się opiera. Kolejną cechą odróżniającą UDP od TCP jest możliwość transmisji do kilku adresów docelowych na raz (tzw. multicast).
Pakiety UDP, zwane też datagramami, zawierają oprócz nagłówków niższego poziomu nagłówek UDP. Składa się on z pól zawierających sumę kontrolną, długość pakietu oraz porty: źródłowy i docelowy.
Podobnie jak w TCP, porty UDP zapisywane są na dwóch bajtach (szesnastu bitach), więc każdy adres IP może mieć przypisanych 65536 różnych zakończeń. Z przyczyn historycznych, porty 0-1023 zarezerwowane są dla dobrze znanych usług sieciowych - dla aplikacji użytkownika przydziela się porty od 1024.
Struktura nagłówka UDP
+ |
Bity 0 - 15 |
16 - 31 |
0 |
Port nadawcy |
Port odbiorcy |
32 |
Długość |
Suma kontrolna |
64 |
|
|
Port nadawcy
identyfikuje port, z którego została wysłana wiadomość, kiedy znaczący to wskazuje port wysyłającego procesu i może zostać przyjęty jako port, do którego powinna zostać zwrócona wiadomość zwrotna w przypadku braku innej informacji. Port nadawcy jest polem opcjonalnym. Gdy pole to nie jest używane przyjmuje wartość zero.
Port odbiorcy
identyfikuje port odbiorcy i jest polem wymaganym.
Długość
16-bitowe pola specyfikują długość w bajtach całego datagramu: nagłówek i dane. Minimalna długość to 8 bajtów i jest to długość nagłówka. Wielkość pola ustala teoretyczny limit 65,527 bajtów, dla danych przenoszonych przez pojedynczy datagram UDP.
Suma kontrolna
16 bitowe pole, które jest użyte do sprawdzania poprawności nagłówka oraz danych. Pole jest opcjonalne. Ponieważ IP nie wylicza sumy kontrolnej dla danych, suma kontrolnaUDP jest jedyną gwarancją, że dane nie zostały uszkodzone.