Protokół DNS (Domain Name System) – czyli co?
Protokół DNS jest jednym z najczęściej używanych protokołów sieciowych i chociaż cały czas z niego korzystamy, to jest on dla nas jak powietrze, przyzwyczailiśmy się do niego i nie zwracamy na niego uwagi…., chyba że go zabraknie. Bo czy zastanawiałeś się kiedyś, co się dzieje, kiedy w przeglądarce wpisujemy adres interesującej nas strony www? Wydaje nam się, że używamy wtedy protokołów http lub https, ale co dzieje się wcześniej? Skąd przeglądarka wie, z jakim serwerem się połączyć?
Protokół DNS został wprowadzony, aby ułatwić nam poruszanie się we wciąż rozrastających się sieciach. Używanie adresów IP jest dla nas nieintuicyjne, więc żeby ułatwić nam życie protokół DNS tłumaczy łatwe do zapamiętania nazwy na adresy IP zrozumiałe dla komputerów. Takie rozwiązanie nie tylko ułatwia nam dostęp do zasobów, ale również rozwiązuje problem migracji danych na inne systemy. Wystarczy, że po przeniesieniu danych na nowy serwer zmienimy w DNS adres IP powiązany z nazwą i od tego momentu każdy użytkownik trafi na nowy serwer. Odwzorowanie nazw na adres IP działa też w drugą stronę, a więc znając adres IP, możemy sprawdzić, z jaką domeną jest powiązany. Takie rozwiązanie jest przydatne np. w systemach antyspamowych, gdzie można odrzucać wiadomości wysłane przez serwer, który nie obsługuje domeny, z której pochodzi wiadomość, a więc najpewniej nie jest upoważniony do wysyłania z niej wiadomości.
Krótka historia DNS
W początkowej fazie tworzenia sieci odwzorowanie nazw na adresy IP było realizowane za pomocą statycznych plików hosts przechowywanych na lokalnym dysku komputera. Rozwiązanie takie było nieefektywne i zupełnie nieskalowalne. Chociaż pliki hosts były tworzone centralnie, to czas dodawania nowych wpisów był dość długi (zgłoszeń dodania nowego hosta do bazy dokonywało się telefonicznie) i użytkownicy musieli pamiętać, żeby regularnie aktualizować wersję pliku znajdującą się na ich komputerze.
Przy coraz szybciej rosnącej liczbie komputerów podłączonych do Internetu zauważono, że takie rozwiązanie na dłuższą metę nie ma szansy działać poprawnie. W roku 1983 powstała pierwsza wersja RFC dla protokołu DNS (RFC882 – DOMAIN NAMES – CONCEPTS and FACILITIES oraz RFC883 – IMPLEMENTATION and SPECIFICATION. Na ich podstawie w 1985 powstała pierwsza implementacja DNS dla systemów UNIX znana jako BIND (Berkeley Internet Name Domain), która działa i jest rozwijana do dzisiaj. W 1987 zostały wydane dwa kolejne bardzo ważne RFC aktualizujące i zastępujące te wydane w roku 1984. Były to RFC1034 oraz RFC1035.
Warto wspomnieć jeszcze o pojawieniu się polskich domen z końcówką .pl. Domena .pl została ustanowiona w 1990 roku, ale pierwsze działające domeny pojawiły się dopiero w 1991. Pierwszymi zarejestrowanymi domenami były domeny uniwersytetów i instytutów naukowych, a więc działały w domenie .edu.pl.
Struktura DNS
DNS ma strukturę rozproszoną i hierarchiczną. Oznacza to, że nie ma jednego, centralnego serwera, który ma informację o wszystkich domenach. Występuje za to podział na domeny i subdomeny a każdy z serwerów jest odpowiedzialny jedynie za swoją część tej struktury. Taka struktura nie tylko ułatwia zarządzanie, ale też podnosi niezawodność całej usługi.
Nazwa DNS składa się z nazwy domeny, subdomeny (opcjonalnie) i nazwy hosta. Domeną najwyższego poziomu jest root domena określana też jako „.” (dot – kropka). Jej subdomenami są domeny najwyższego poziomu, czyli takie jak com, org, gov czy pl. Kolejne subdomeny będziemy już zapisywali po lewej stronie i będą to subdomeny przypisane do konkretnych firm, organizacji albo osoby. Spójrz na domenę networkacademy.pl, networkacademy jest subdomeną domeny najwyższego czyli pl. W domenie są zarejestrowane nazwy hostów takie jak www albo mail. Możliwe jest również tworzenie subdomen np. sklep.networkacademy.pl albo szkolenia.networkacademy.pl i być może kiedyś takie powstaną 🙂
Jak widzisz, na samej górze schematu są serwery root DNS. Jest ich 13, a będąc bardziej precyzyjnym, jest to 13 węzłów, za którymi kryje się co najmniej kilka klastrów, a za każdym klastrem kryje się wiele serwerów. To powoduje, że usługa jest niezawodna i awaria części serwerów nie spowoduje problemów dla użytkowników. Root serwery są odpowiedzialne za znajomość domen najwyższego poziomu. Nie muszą one znać każdej domeny i każdego hosta w tej domenie. Wystarczy, że znają serwery domen najwyższego poziomu i w razie potrzeby przekierują zapytanie do odpowiedniego z nich.
Serwery najwyższego poziomu takie jak com albo pl są odpowiedzialne za swoje poddomeny. Tak jak w przypadku serwerów root nie muszą one znać pełnej struktury DNS swoich poddomen, wystarczy, że wiedzą, jaki serwer jest odpowiedzialny za taką poddomenę. Rozwiązywanie nazw może przebiegać wzdłuż struktury DNS, ale jest też inne, zwykle dużo szybsze rozwiązanie, czyli serwery DNS operatorów internetowych, które pośredniczą w zapytaniach DNS a dzięki temu, że zapamiętują odpowiedzi (pamięć cache), mogą odpowiadać znacznie szybciej, niż wykonując całą ścieżkę zapytań za każdym razem.
Zapytania rekurencyjne i iteracyjne
Kiedy komputer wysyła zapytanie DNS, spodziewa się otrzymać gotową odpowiedź. Takie zapytanie nazywamy rekurencyjnym. W odpowiedzi na takie pytanie możemy dostać jedną z dwóch odpowiedzi – adres IP odpowiedniego serwera lub informację, że host lub domena nie istnieje. Jeśli więc wpisujesz w swojej przeglądarce www.google.com, Twój komputer wysyła do serwera DNS zapytanie o host www w domenie google.com. W odpowiedzi serwer wyśle informacje o aktualnym adresie IP powiązanym z www.google.com. Ta część rozwiązywania nazw przez system DNS jest w miarę prosta. Dużo ciekawiej wygląda to, co robi serwer, żeby taką nazwę rozwiązać.
Załóżmy, że nasz serwer nie jest odpowiedzialny za tą domenę i nigdy wcześniej nie rozwiązywał tej nazwy (nie ma zapisanej odpowiedzi w swojej pamięci cache). W takiej sytuacji zapytanie zostanie wysłane w pierwszej kolejności do jednego z root serwerów DNS. W odpowiedzi uzyskamy adres serwera DNS odpowiedzialnego za domenę com. Kolejny krok to wysłanie zapytania do serwera serwera com, dzięki czemu uzyskamy adres serwera google.com. W ostatnim kroku wysyłając pytanie do serwera google.com, uzyskamy adres hosta www w tej domenie. Taki sposób rozwiązywania nazw nazywamy iteracyjnym.
Serwery autorytatywne i nieautorytatywne
Jak już się pewnie domyślasz poza dwoma rodzajami zapytań mamy również dwa rodzaje odpowiedzi. Jeśli serwer DNS jest serwerem odpowiedzialnym za domenę, nazywamy go serwerem autorytatywnym a uzyskaną odpowiedź autorytatywną, czyli pewną. Jeśli natomiast serwer nie jest odpowiedzialny za domenę, odpowiedź będzie nieautorytatywna.
W praktyce większość wysyłanych zapytań kierowanych jest do serwerów nieautorytatywnych. Serwery dostawców internetowych albo ogólnodostępne serwery DNS nie są serwerami żadnej domeny. Otrzymane zapytania przekierowują (dlatego nazywamy je Forwarderami) do właściwych serwerów autorytatywnych. Następnie uzyskane odpowiedzi przechowują w swojej pamięci, żeby w przypadku kolejnego zapytania o tą samą domenę móc szybciej odpowiedzieć. Oczywiście jeśli taka informacja będzie zapamiętana zbyt długo może dojść do tego, że odpowiedź wysyłana na kolejne zapytania będzie już nieaktualna. Żeby temu zapobiec, każdy zapamiętany rekord ma parametr TTL (Time To Live), który mówi o czasie ważności wpisy. Jeśli parametr TTL osiągnie 0, serwer musi ponownie wysłać zapytanie do serwera autorytatywnego lub swojego nadrzędnego forwardera.
Redundancja – klucz do niezawodności
Żeby zapewnić ciągłość działania, każda domena powinna być obsługiwana przez co najmniej dwa serwery DNS. W przypadku nawet chwilowej awarii jednego z nich drugi będzie w stanie cały czas udzielać autorytatywnych odpowiedzi i zapewni ciągłość działania usługi.
Pierwszy serwer DNS w domenie nazywany jest serwerem Master albo Primary (podstawowy). Drugi i każdy kolejny serwer nazywany jest Slave (ze względu na pejoratywne znaczenie tego słowa nazwa używana jest coraz rzadziej) albo Secondary (drugi, zapasowy). Wszystkie zmiany powinny być wprowadzane na serwerze Master, podczas gdy pozostałe serwery przechowują tylko kopię tych danych. Synchronizacja danych pomiędzy serwerem Master a pozostałymi serwerami domeny nazywana jest transferem stref (zone transfer).
Rekordy DNS
Rekord A – Podstawowym rekordem DNS jest rekord A. Służy on do zamiany nazwy na adres IP. Za każdym razem, kiedy w przeglądarce lub innym programie próbujemy połączyć się z jakąś domeną, nasz system pyta o rekord A dla tej domeny i w ten sposób ustala, z jakim adresem się połączyć.
Rekord AAAA – jest tym samym co rekord A ale dla adresacji IPv6.
Rekord SOA (Start of Authority) – Jest rekordem wskazującym na główny serwer DNS obsługujący domenę. Poza nazwą serwera rekord SOA zawiera również informacje o czasie ważności rekordów w domenie.
Rekord NS (Name Servers) – zawiera listę wszystkich serwerów DNS odpowiedzialnych za domenę, w tym również podstawowy serwer, czyli SOA.
CNAME – rekord nazwy kanonicznej (canonical name), czyli alias nazwy. Jeżeli pod jednym adresem IP działają dwie usługi np. serwer www i ftp to rekord CNAME może kierować z nazwy ftp na nazwę www, która finalnie poprzez rekord A powiąże obie nazwy z adresem IP.
MX (Mail eXchange) – pozwala na znalezienie serwera pocztowego dla domeny.
Rekord SRV – jest rekordem usługi (Service). Za pomocą tego rekordu możliwe jest lokalizowanie usług takich jak LDAP, Kerberos czy SIP.
TXT – jest rekordem tekstowym używanym do przechowywania dodatkowych informacji dotyczących domeny i rekordów. TXT służy do weryfikacji własności domen albo zapewnienia bezpieczeństwa poczty.
Rekord PTR – zamienia adres IP na nazwę, a więc zachowuje się odwrotnie do rekordu A. PTR jest używany głównie przez aplikacje i systemy do określenia, jaka nazwa jest powiązana ze znanym adresem IP.
Informacje o tym jak odpytać serwer DNS o poszczególne rekordy znajdziesz w artykule na temat nslookup. Natomiast więcej o komunikacji DNS napisałem w kolejnym artykule Komunikacja DNS w praktyce.