System Nazw Domenowych (DNS)

DNS: nazwy domen i adresy IP

Internet łączy sieci i urządzenia, które rozpoznają się za pomocą unikalnych adresów. Podstawowym systemem adresowania jest , czyli ciąg liczb, na przykład $198.133.219.25$ dla IPv4 lub $2001:db8:85a3::8a2e:370:7334$ dla IPv6. Komputery przetwarzają te adresy bez dodatkowych informacji, lecz użytkownicy korzystają z nazw domen łatwiejszych do zapamiętania.

Nazwy domen, takie jak www.nask.pl i wikipedia.org, zastępują adresy liczbowe w interfejsach użytkownika. Powiązanie nazwy z adresem IP zapewnia , czyli hierarchiczny i rozproszony system nazw oraz danych zasobów.

DNS jest rozproszoną bazą danych mapującą nazwy domen na adresy IP i inne dane usług. Przeglądarka, serwer pocztowy oraz aplikacja mobilna korzystają z resolvera DNS, aby znaleźć host wskazany przez nazwę. Rekordy DNS mogą także opisywać serwery pocztowe, delegacje, usługi i zasady użycia domeny. Resolver zwraca typ danych zgodny z zapytaniem, na przykład rekord A albo AAAA. Awaria rozwiązywania nazw uniemożliwia klientowi uzyskanie adresu potrzebnego do nawiązania połączenia.

Hierarchia DNS: globalny, rozproszony system

Jeden serwer z pełną listą nazw nie obsłużyłby zmian i zapytań całego internetu. DNS dzieli dane między strefy zarządzane przez różne organizacje i łączy je w hierarchię. Serwery nazw przechowują własne strefy oraz odwołania do kolejnych serwerów, a resolvery utrzymują cache wyników. Delegacja wskazuje serwery odpowiedzialne za niższy fragment przestrzeni nazw, dlatego aktualizacje domeny pozostają w strefie prowadzonej przez jej operatora.

Poziomy hierarchii DNS

1. Główne serwery DNS (root DNS servers): Na szczycie hierarchii znajduje się strefa główna, reprezentowana przez pojedynczą kropkę („.”). System root ma 13 nazwanych tożsamości serwerów, obsługiwanych przez wiele instancji rozmieszczonych na świecie. Serwery te przechowują delegacje do domen najwyższego poziomu, lecz nie przechowują adresu każdej strony. Delegacja zawiera informacje o serwerach nazw TLD oraz dane pomocnicze potrzebne do dalszego zapytania. Resolver może zapytać serwer root, gdzie znaleźć serwery dla .pl.
2. Serwery domen najwyższego poziomu (TLD): Kolejny poziom tworzą Domeny Najwyższego Poziomu (Top-Level Domains), takie jak .com, .org, .net, a także krajowe TLD, takie jak .pl i .de. Operator każdego TLD utrzymuje zestaw serwerów dla swojej strefy, w Polsce robi to NASK. Serwer TLD dla .pl nie przechowuje adresu IP dla www.wp.pl. Zwraca delegację do autorytatywnych serwerów domeny wp.pl. Resolver wykorzystuje tę delegację, aby wysłać następne zapytanie do właściwej strefy.
3. Autorytatywne serwery DNS: Autorytatywny serwer nazw dla example.com przechowuje rekordy DNS tej strefy, w tym adres dla www.example.com i dane pocztowe dla mail.example.com. Dla przykładowego rekordu A może zwrócić adres $93.184.216.34$ . Te dane, znane jako , mają nazwę, klasę, typ i dane rekordu. Odpowiedź autorytatywna pochodzi ze strefy, za którą odpowiada ten serwer, więc zawiera dane źródłowe dla danego fragmentu hierarchii.

Proces rozwiązywania nazw DNS: od nazwy do numeru

Rozwiązywanie nazwy przebiega przez hierarchię DNS. Zwykle uczestniczy w nim czwarty typ serwera działający w imieniu użytkownika, czyli Rekursywny Resolver DNS.

Rola resolvera rekursywnego

Komputer klienta zazwyczaj nie komunikuje się bezpośrednio z serwerami root, TLD i autorytatywnymi. Korzysta z . Może to być serwer dostawcy usług internetowych (ISP) albo usługa publiczna, taka jak Google DNS ( $8.8.8.8$ ) czy Cloudflare DNS ( $1.1.1.1$ ). Resolver sprawdza własny cache i w razie potrzeby wysyła zapytania do kolejnych serwerów. Dla klienta wykonującego zapytanie rekursywne resolver zwraca końcową odpowiedź albo informację o błędzie.

Krok 1: użytkownik wysyła żądanie. Użytkownik wpisuje www.example.com w przeglądarce i zatwierdza żądanie. Stub resolver systemu operacyjnego najpierw sprawdza lokalny cache pod kątem adresu IP. Gdy nie ma ważnego wpisu, wysyła zapytanie do skonfigurowanego resolvera rekursywnego DNS.
Krok 2: resolver sprawdza swój cache. Resolver rekursywny otrzymuje zapytanie i sprawdza własny cache. Jeśli zawiera on ważną odpowiedź, resolver zwraca ją klientowi bez kolejnych zapytań. To buforowanie ogranicza liczbę transmisji dla często używanych nazw.
Krok 3: resolver pyta serwer główny. Jeśli odpowiedzi nie ma w cache, resolver rozpoczyna proces iteracyjnych zapytań. Wysyła zapytanie o www.example.com do jednego z głównych serwerów DNS.
Krok 4: serwer główny odpowiada. Serwer główny zwraca delegację do serwerów nazw domeny .com, lecz nie zwraca końcowego adresu dla www.example.com. Odpowiedź zawiera rekordy NS oraz, gdy są potrzebne, rekordy adresowe tych serwerów. Resolver może na ich podstawie kontynuować zapytanie iteracyjne.
Krok 5: resolver pyta serwer TLD. Resolver wysyła to samo zapytanie o www.example.com do jednego z serwerów TLD .com.
Krok 6: serwer TLD odpowiada. Serwer .com zwraca delegację do autorytatywnych serwerów nazw dla example.com, lecz nie zwraca końcowego adresu. Odpowiedź zawiera rekordy NS oraz wymagane rekordy adresowe tych serwerów. Resolver wykorzystuje je w kolejnym zapytaniu.
Krok 7: resolver pyta serwer autorytatywny. Resolver wysyła teraz swoje zapytanie do autorytatywnego serwera nazw dla example.com.
Krok 8: serwer autorytatywny dostarcza odpowiedź. Ten serwer w końcu ma odpowiedź. Sprawdza w swoim pliku strefy i znajduje rekord A dla www, który zawiera adres IP $93.184.216.34$ . Odsyła ten adres IP do resolvera wraz z parametrami odpowiedzi, między innymi wartością TTL.
Krok 9: resolver zwraca odpowiedź do klienta. Resolver otrzymuje adres IP. Zapisuje tę odpowiedź w swoim cache na określony czas (zdefiniowany przez wartość TTL, czyli Time-To-Live, w rekordzie DNS), a następnie zwraca adres IP do komputera klienta. Kolejne zapytania mogą korzystać z tej wartości do czasu jej wygaśnięcia.
Krok 10: przeglądarka nawiązuje połączenie. Przeglądarka ma teraz docelowy adres IP i może zainicjować połączenie HTTP(S) z serwerem pod tym adresem, aby pobrać stronę internetową.

Buforowanie DNS i TTL

Pełne rozwiązywanie bez użytecznej odpowiedzi w cache wymaga kilku zapytań i może trwać od milisekund do kilku sekund, zależnie od dostępności serwerów. Także odpowiedzi negatywne mogą być przechowywane zgodnie z regułami cache i czasem określonym dla domeny. Powtarzanie tego procesu dla każdego żądania zwiększałoby liczbę transmisji. Dlatego DNS używa buforowania na wielu poziomach.

Cache przeglądarki: Same przeglądarki internetowe utrzymują mały, krótkoterminowy cache DNS. Po jednokrotnym rozwiązaniu nazwy www.example.com, przeglądarka zapisze wynik. Gdy użytkownik otworzy kolejny link prowadzący do tej samej domeny, przeglądarka może natychmiast użyć zbuforowanego adresu IP bez wysyłania kolejnego zapytania DNS. Taki wpis obowiązuje tylko przez czas wynikający z polityki cache i TTL.
Cache systemu operacyjnego (stub resolver): System operacyjny również utrzymuje cache DNS. Ten cache jest współdzielony przez wszystkie aplikacje w systemie.
Cache resolvera rekursywnego: Resolver utrzymuje większy cache współdzielony przez klientów. Przy zapytaniu o często używaną nazwę, taką jak www.google.com, może zwrócić wynik zapisany po wcześniejszym zapytaniu.

Time-to-live (TTL)

Czas, przez który rekord DNS może być przechowywany w cache, jest kontrolowany przez jego wartość . Właściciel domeny ustawia TTL dla swoich rekordów na swoim autorytatywnym serwerze nazw. Dłuższy TTL (np. 24 godziny) zmniejsza obciążenie serwera autorytatywnego i przyspiesza zapytania dla użytkowników, ale oznacza również, że jeśli adres IP się zmieni, zmiana ta będzie dłużej propagować się przez internet, ponieważ cache będą czekać na wygaśnięcie starego wpisu. Krótszy TTL (np. 5 minut) pozwala na szybsze aktualizacje, ale zwiększa ruch DNS.

Narzędzie `nslookup`: Diagnostyka DNS

Administratorzy sieci i deweloperzy używają narzędzi wiersza poleceń do wysyłania zapytań DNS oraz oglądania odpowiedzi. Jednym z szeroko dostępnych narzędzi jest nslookup (Name Server Lookup).

Proste zapytanie może wyglądać tak w wierszu poleceń systemu Windows:

C:\>nslookup www.wp.pl
Server:  twoja.nazwa.serwera.dns
Address:  twoj.adres.ip.serwera.dns

Non-authoritative answer:
Name:    www.wp.pl
Addresses:  2a02:1820:1000::20
          212.77.98.9

Narzędzie najpierw pokazuje, którego serwera DNS używa do zapytania.
"Non-authoritative answer" oznacza, że odpowiedź nie pochodzi bezpośrednio z autorytatywnej strefy. Zwykle zwraca ją resolver rekursywny, który mógł użyć własnego cache.
Odpowiedź zawiera zarówno adres IPv6 (rekord AAAA), jak i adres IPv4 (rekord A) dla domeny.

nslookup i podobne narzędzia, takie jak dig na Linuksie i macOS, służą do weryfikacji rekordów, sprawdzania odpowiedzi serwerów i diagnozowania problemów z rozwiązywaniem nazw. Narzędzia te mogą kierować zapytania do wskazanego serwera oraz wybierać typ rekordu. Polecenie ipconfig /displaydnsw systemie Windows wyświetla zawartość lokalnego cache'u DNS systemu operacyjnego.