Pełny proces rozwiązywania nazw DNS — ile kroków od przeglądarki do serwera głównego?

1. Pełny przebieg w 8 krokach

┌─────────────────────────────────────────────────────────────┐
│  Przeglądarka (Chrome / Firefox) — wpisujesz google.com     │
└────────────────┬────────────────────────────────────────────┘
                 │ ① Cache DNS przeglądarki (Chrome ~60 s)
                 ↓ brak (miss)
┌─────────────────────────────────────────────────────────────┐
│  Stub resolver systemu + systemowy cache DNS                │
└────────────────┬────────────────────────────────────────────┘
                 │ ② Brak w cache systemu → zapytanie UDP do routera
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Przekazywanie DNS w routerze domowym + cache routera       │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ Brak w cache routera → przekazanie do resolvera ISP
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Resolver rekurencyjny ISP / publiczny                      │
│  (1.1.1.1 / 8.8.8.8 / 223.5.5.5)                            │
│  Trafienie w cache: odpowiedź od razu, całość trwa 1–5 ms   │
│  Brak w cache: dalej „pełne wyszukiwanie” opisane niżej     │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ Pyta serwer główny NS: „gdzie jest google.com?”
                 ↓
        13 klastrów serwerów głównych (a~m.root-servers.net)
                 │ ⑤ Odpowiedź: „Nie wiem, zapytaj NS domeny .com: a.gtld-servers.net”
                 ↓
        Autorytatywne serwery TLD .com (Verisign)
                 │ ⑥ Odpowiedź: „Też nie mam wszystkiego, zapytaj NS google.com: ns1.google.com”
                 ↓
        Autorytatywne serwery google.com (obsługuje je samo Google)
                 │ ⑦ Odpowiedź: „rekord A google.com = 142.250.x.x”
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ Resolver rekurencyjny zapisuje odpowiedź w cache         │
│     (wg TTL) i zwraca ją klientowi — każda warstwa          │
│     po drodze też zapisuje własną kopię                     │
└─────────────────────────────────────────────────────────────┘

Kluczowa obserwacja: w rzeczywistości pełny przebieg w 8 krokach prawie nigdy nie występuje. Adresy IP dużych serwisów niemal zawsze są już w cache resolvera rekurencyjnego, więc zwykły użytkownik dostaje odpowiedź już na kroku ④. Pełny przebieg uruchamiają tylko mało znane domeny, rzadko odwiedzane strony, wygasłe TTL lub świeżo zarejestrowane domeny.

2. Pięć warstw pamięci podręcznej DNS

Już przy projektowaniu DNS w 1983 roku uwzględniono jeden fakt: zapytań jest 100 000 razy więcej niż zmian. Dlatego pamięć podręczna (cache) jest wszędzie, a każda warstwa przechowuje dane przez czas TTL (Time To Live).

3. Zapytania rekurencyjne a iteracyjne — kluczowe pojęcia

3.1 Rekurencyjne (recursive)

Klient (przeglądarka / stub systemu) mówi rekurencyjnemu resolverowi dostawcy internetu: „Znajdź mi IP google.com — nie interesuje mnie, jak to zrobisz”. Resolver rekurencyjny musi przeprowadzić całe wyszukiwanie i zwrócić ostateczny wynik.

3.2 Iteracyjne (iterative)

Gdy resolver rekurencyjny rozmawia z serwerami głównymi, TLD i autorytatywnymi, ta wymiana jest iteracyjna — pyta serwer główny, ten odpowiada „zapytaj .com”, resolver pyta .com, .com odpowiada „zapytaj google”, resolver pyta google. Każdy krok obejmuje tylko jeden poziom — to nie jest tak, że „pytam serwer główny, a on załatwia za mnie wszystko”.

4. Test w praktyce — dig +trace

dig +trace wymusza pełne wyszukiwanie iteracyjne i pokazuje każdy krok:

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

; ① Skok 1 — pytanie do serwera głównego (.)
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (13 rekordów NS serwerów głównych)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

; ② Skok 2 — pytanie do TLD .io
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (4 rekordy NS dla .io)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

; ③ Skok 3 — pytanie do serwerów autorytatywnych cleanip.io
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

; ④ Wreszcie odpowiedź
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

Omówienie:

• Cały proces zajął 5 + 121 + 53 + 12 = 191 ms — pierwsze „zimne” zapytanie naprawdę jest wolne
• Ale ponowne zapytanie o tę samą domenę sekundę później trwa tylko 1–2 ms, bo rekurencyjny cache dostawcy internetu już ją ma (TTL 300 sekund)
• 104.21.x.x / 172.67.x.x to adresy CDN Cloudflare — prawdziwe IP serwera źródłowego naszej witryny jest ukryte za CDN

5. TTL w szczegółach — jak długo naprawdę trwa cache

TTL (Time To Live) to pole, w którym serwer autorytatywny mówi każdemu resolverowi rekurencyjnemu: „możesz to przechowywać w cache najwyżej tyle”; wartość podaje się w sekundach.

Uwaga: TTL to „maksymalny czas przechowywania w cache” — poszczególne resolvery mogą wyczyścić cache wcześniej, ale nigdy nie mogą go wydłużyć. Dlatego nawet przy autorytatywnym TTL równym 1 godzinie niektóre resolvery mogą ponowić zapytanie już po 10 minutach.

Pułapka: przed zmianą adresu IP najpierw skróć TTL (1–5 minut) i poczekaj, aż stary TTL w pełni wygaśnie, zanim przełączysz — inaczej część użytkowników jeszcze przez ponad godzinę będzie trafiać na stary adres IP.

6. Ściąga: typy rekordów DNS

7. Optymalizacja DNS — jak przyspieszyć rozwiązywanie nazw

7.1 Wybierz pobliski resolver rekurencyjny

Chiny kontynentalne: 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod) najszybciej rozwiązują nazwy serwisów w Chinach. Poza Chinami: 1.1.1.1 (Cloudflare, najszersza sieć anycast) / 8.8.8.8 (Google). Zobaczkatalog publicznych resolverów DNS.

7.2 Włącz DoH (DNS-over-HTTPS)

Szyfrowanie zapytań DNS przez HTTPS sprawia, że dostawca internetu nie może ich podglądać ani modyfikować (chroni to przed przejmowaniem odpowiedzi NXDOMAIN). Obsługują to Chrome, Firefox i Edge — wystarczy włączyć w ustawieniach.

7.3 Rozgrzej z wyprzedzeniem (DNS Prefetch)

Dodaj <link rel="dns-prefetch" href="//api.example.com"> do sekcji <head> swojej strony, aby przeglądarka rozwiązała nazwę w wolnej chwili — gdy nastąpi właściwe żądanie, będzie to trafienie w cache.

7.4 Użyj CDN i serwerów NS w anycast

Umieść autorytatywne serwery NS w anycast (Cloudflare / Route 53), aby użytkownicy na całym świecie trafiali do najbliższej instancji — skraca to opóźnienie kroku ③ ze 100 ms do 10 ms.

7.5 Rozsądnie ustaw TTL

Dla rekordów, które rzadko się zmieniają (NS / MX), ustaw długi TTL (1–7 dni); dla rekordów A, które mogą wymagać przełączenia, ustaw krótki TTL (5–60 minut).

8. Najczęstsze pytania

8.1 Zmiana DNS nie działa — dlaczego?

Najpierw sprawdź bieżący TTL. Po zmianie DNS każdy resolver rekurencyjny będzie zwracał stary adres IP, dopóki stary TTL nie wygaśnie. „Globalna propagacja” trwa zwykle około 2× TTL (bo resolvery nie są ze sobą zsynchronizowane).

• Klient: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• Publiczny resolver rekurencyjny: trzeba poczekać, aż cache wygaśnie — 1.1.1.1 / 8.8.8.8 oferują własne narzędzia „purge” do ręcznego czyszczenia

8.2 Jedni użytkownicy mają dostęp, inni nie — zatruwanie DNS

Częste przy otwieraniu zagranicznych stron z Chin kontynentalnych — wstrzykiwanie fałszywych odpowiedzi DNS przez GFW / przejmowanie zapytań przez dostawców internetu. Przejście na DoH (szyfrowany DNS w przeglądarce) pozwala obejść większość przypadków zatruwania DNS.

8.3 Po jakim czasie od rejestracji domeny można jej używać?

Po rejestracji rejestr TLD publikuje Twoje rekordy NS na serwerach autorytatywnych najwyższego poziomu dla .com / .net itd. — zwykle trwa to od 15 minut do 24 godzin. Domeny .cn / .com.cn mogą wymagać wpisu ICP (ICP filing), zanim zaczną być rozwiązywane w Chinach kontynentalnych.