Jak działa serwer DNS — od wpisania adresu do wczytania strony

Serwer DNS tłumaczy nazwy domen, które łatwo zapamiętać, na adresy IP, których komputery potrzebują do nawiązania połączenia. Gdy wpisujesz xad.pl, Twoje urządzenie nie wie, gdzie fizycznie leży ten serwis — zna tylko nazwę. DNS (Domain Name System) zamienia ją na adres w rodzaju 192.0.2.10, po którym ruch trafia do właściwej maszyny. Działa to jak książka adresowa internetu.

Cały proces trwa zwykle kilka–kilkadziesiąt milisekund i jest dla Ciebie niewidoczny, ale pod spodem rozgrywa się uporządkowana wymiana zapytań między kilkoma rodzajami serwerów. Poniżej rozkładam ją na części: kto kogo pyta, w jakiej kolejności i dlaczego zwykle wszystko idzie błyskawicznie.

Po co w ogóle jest DNS

Komputery komunikują się po adresach IP, a nie po nazwach. Człowiek z kolei nie zapamięta zestawu liczb dla każdej strony, którą odwiedza. DNS rozwiązuje ten konflikt: pozwala używać nazw, a za kulisami dba o ich zamianę na adresy.

Dodatkowa zaleta to elastyczność. Właściciel serwisu może zmienić serwer i jego adres IP, a nazwa domeny zostaje ta sama — wystarczy zaktualizować wpis w DNS. Dzięki temu możliwe są też rozwiązania takie jak sieci CDN, gdzie jedna nazwa prowadzi do różnych serwerów w zależności od tego, skąd łączy się użytkownik.

Droga zapytania krok po kroku

Prześledźmy, co się dzieje od momentu wpisania adresu do wczytania strony. Zakładamy, że szukanej nazwy nie ma jeszcze w żadnej pamięci podręcznej (czyli przypadek najbardziej „pracowity”).

1. Przeglądarka i system sprawdzają własny cache. Zanim cokolwiek poleci w sieć, komputer sprawdza, czy już niedawno nie pytał o tę nazwę. Jeśli tak — używa zapamiętanego adresu i kończy.
2. Zapytanie trafia do resolvera. Jeśli cache jest pusty, komputer wysyła zapytanie do resolvera rekurencyjnego — zwykle serwera DNS Twojego operatora albo publicznego, jak 1.1.1.1. To on wykona całą „czarną robotę” i zwróci gotową odpowiedź.
3. Resolver pyta serwer root. Nie znając adresu, resolver zwraca się do serwera głównego (root). Root nie zna konkretnej strony, ale wie, kto zarządza daną końcówką — np. .pl. Odsyła więc do serwerów TLD domeny .pl.
4. Resolver pyta serwer TLD. Serwer domeny najwyższego poziomu (.pl, .com itd.) nie zna adresu IP strony, ale wie, które serwery są autorytatywne dla konkretnej domeny xad.pl. Przekazuje tę wskazówkę.
5. Resolver pyta serwer autorytatywny. To serwer, który faktycznie przechowuje rekordy danej domeny. Zwraca właściwy adres IP.
6. Resolver oddaje odpowiedź. Resolver przekazuje adres IP Twojemu komputerowi (i zapisuje go u siebie w cache), a przeglądarka łączy się z tym adresem i pobiera stronę.

To hierarchiczna sztafeta: root wskazuje TLD, TLD wskazuje serwer autorytatywny, a ten dopiero zna odpowiedź. Żaden pojedynczy serwer nie zna całego internetu — i o to chodzi, bo taka struktura jest skalowalna i odporna na awarie.

Wskazówka: Serwerów root jest 13 „logicznych” (oznaczonych literami od A do M), ale nie są to pojedyncze maszyny. Każdy z nich to w rzeczywistości setki serwerów rozsianych po świecie i współdzielących jeden adres dzięki technice anycast. Dlatego mit o „13 komputerach trzymających internet” jest nieprawdziwy — więcej w tekście o DNS Anycast.

Rekurencja, iteracja i pamięć podręczna

Warto rozróżnić dwa style zadawania pytań, bo często się je myli.

Twój komputer zadaje resolverowi pytanie rekurencyjne: „daj mi gotowy adres IP i sam się tym zajmij”. Resolver bierze na siebie odpowiedzialność za dostarczenie finalnej odpowiedzi. Natomiast wobec serwerów root, TLD i autorytatywnych ten sam resolver zadaje pytania iteracyjne: każdy z tych serwerów odpowiada tylko tyle, ile wie, i odsyła go o krok dalej.

Kluczem do szybkości jest pamięć podręczna i parametr TTL (Time To Live). Każda odpowiedź ma przypisany czas życia, przez który wolno ją przechowywać. Resolver zapisuje więc wyniki i przy kolejnym pytaniu o tę samą nazwę odpowiada z pamięci, nie ruszając całej sztafety. To dlatego pierwsze wejście na nową stronę bywa minimalnie wolniejsze, a następne są natychmiastowe. TTL ustawia administrator domeny: niski (np. kilka minut) przyspiesza wprowadzanie zmian, wysoki (godziny, doba) odciąża serwery i przyspiesza odpowiedzi.

Z TTL wiąże się też pojęcie propagacji DNS. Gdy zmieniasz adres IP domeny, zmiana „rozchodzi się” tak szybko, jak wygasają stare wpisy w cache na całym świecie — stąd typowe oczekiwanie do kilkudziesięciu godzin, zanim wszyscy zobaczą nowy adres.

Rodzaje rekordów DNS

DNS nie przechowuje wyłącznie adresów IP. W strefie domeny leży zestaw rekordów różnych typów, z których każdy pełni inną funkcję.

Gdy więc wysyłasz e-mail na adres w danej domenie, Twój serwer poczty odpytuje DNS o rekord MX, a nie A. Jeden system obsługuje całą tę różnorodność. Jeśli chcesz zajrzeć głębiej w pojęcia hostingowe, pomocny bywa słowniczek hostingowy.

Jak sprawdzić i zmienić serwer DNS

Domyślnie korzystasz z resolvera swojego operatora, ale możesz to zmienić.

Aby sprawdzić, jaki adres IP zwraca DNS dla danej nazwy, użyj w wierszu poleceń (Windows) narzędzia nslookup:

nslookup xad.pl

W systemach Linux i macOS podobnie działa dig, pokazując więcej szczegółów, w tym TTL:

dig xad.pl

Jeśli po zmianach w DNS wciąż widzisz stary adres, wyczyść lokalną pamięć podręczną. W Windows:

ipconfig /flushdns

Serwer DNS zmienisz w ustawieniach karty sieciowej lub w routerze. Popularne publiczne resolvery to 1.1.1.1 (Cloudflare) i 8.8.8.8 (Google). Bywają szybsze od DNS operatora i oferują dodatkowe funkcje, choć realna różnica w prędkości zależy od Twojej lokalizacji. Przy okazji zmiany ustawień sieci przyda się poradnik o tym, jak zmienić IP w Windows.

Porównanie popularnych publicznych serwerów DNS pod kątem szybkości, prywatności i filtrowania znajdziesz w zestawieniu serwerów DNS.

Bezpieczeństwo DNS — o czym warto pamiętać

Klasyczny DNS powstał bez myśli o bezpieczeństwie: zapytania idą zwykłym tekstem, więc da się je podsłuchać, a przy braku zabezpieczeń także podmienić. Na tym polega atak DNS spoofing — napastnik podsuwa fałszywy adres IP, by przekierować Cię na podrobioną stronę.

Odpowiedzią są nowsze mechanizmy. DNSSEC podpisuje odpowiedzi kryptograficznie, więc resolver wykryje podmianę. Z kolei DNS over HTTPS (DoH) i DNS over TLS (DoT) szyfrują samo zapytanie, chroniąc je przed podsłuchem — czy to wystarcza, rozważamy w tekście o tym, czy DNS over HTTPS jest w pełni bezpieczny. Jeśli zarządzasz własną infrastrukturą, warto też poznać dobre praktyki zabezpieczania DNS na przykładzie Cloudflare.

Najważniejsze w skrócie

DNS to warstwa tłumacząca ludzkie nazwy na maszynowe adresy, zbudowana hierarchicznie: resolver pyta kolejno serwery root, TLD i autorytatywny, a wyniki buforuje na czas wyznaczony przez TTL. Dzięki pamięci podręcznej większość zapytań nigdy nie przechodzi całej drogi i dlatego strony otwierają się natychmiast. Jeśli kiedykolwiek strony przestaną się ładować mimo działającego internetu, DNS jest pierwszym miejscem, które warto sprawdzić — zacznij od nslookup i wyczyszczenia lokalnego cache.